Пипец, больше всего среди программистов не люблю принципиальных противников библиотек. Они придумали кучу отмазок, лишь бы не подключать библиотеку, и написать вместо этого собственный велосипед. "Чужая библиотека – черный ящик", "это небезопасно", "я идиот и не смог сконфигурировать Hibernate".

Предположим, нужно разработать приложение для девочек, чтобы они записывались на ноготочки. Типичный велосипедостроитель для работы с датами записи не возьмет проверенную библиотеку, а начнет крафтить свою. В итоге уйдет месяц на костыляние дат и месяц на разработку самого приложения. Заказчик приятно удивится сорванным дедлайнам, но работу примет, хотя велосипедостроителей надо гнать поганой метлой еще до начала разработки.

Спустя некоторое время заказчик откроет новый салон на другом конце РФии и потребует доработку приложения. Костылятор заявит, что ему понадобится месяц, чтобы приделать к его датавелосипеду поддержку временных зон. Адекватный же разработчик за день добавит в базу данных поле "Город", и доработка будет завершена, потому что подключенная библиотека уже умеет во временные зоны и все работает из коробки.

Когда противник библиотек говорит "Мое решение лучше адаптировано к потребностям приложения", это нужно переводить как "Я реализовал только те фичи предметной области, которые были нужны в приложении, и если появятся новые потребности, придется потратить кучу времени на их реализацию".

Зачастую какое-то домашнее решение все равно приходит к тому же результату, что и популярные библиотеки. Например, приложение сохраняет некоторые объекты сущностей в базу данных. Значение каждого поля сущности должно быть передано в SQL-запрос сохранения. Когда вам надоест при добавлении новых полей указывать их еще и в нескольких SQL-запросах, вы можете решить разработать механизм, который позволит указывать над сохраняемыми полями классов аннотации, по которым SQL-запросы будут сгенерированы автоматически. Поздравляю, вы только что изобрели велосипед ORM! Осталось только сделать управление отношениями сущностей, кэши первого-второго уровня и ленивые коллекции, когда появится необходимость оптимизации, все остальные фичи элементарного ORM, и им можно будет пользоваться, когда поправите все баги. А можно было сразу взять Hibernate.

И это еще хороший вариант развития событий, когда собственный велосипед становится аналогом библиотеки, то есть обладает удобным API, изолирован от кода приложения, может быть использован в других приложениях и легко расширяется. Вам всего лишь придется его дорабатывать при появлении новых требований, поддерживать, рефакторить, исправлять баги (в дополнение к исправлению багов в бизнес-логике самого приложения).

Так вот, это утопический сценарий, так не бывает. Обычно велосипед, разработанный вместо библиотеки, представляет собой разрозненный набор несогласованных и дублирующих друг друга классов и методов по всему проекту. Для использования в другом месте методы копипастятся. Использование такого решения в другом проекте решительно невозможно. Взаимоотношения велосипеда и остального кода приложения можно было бы описать как "только смерть разлучит нас", если бы смерти это было под силу.

Все иначе, если просто подключить хорошую библиотеку. Вы беспокоитесь только о прикладной бизнес-логике вашего приложения, а побочные потребности доверяете умным людям, которые разбираются в предметной области. Все важные фичи предметной области уже реализованы – в библиотеке для работы с датами и временем это временные зоны, конвертация, сравнение, операции, поддержка разных календарей, различное форматирование для разных языков и так далее. За многие годы поддержки разработчики исправили кучу багов и оптимизировали код.

Не надо изобретать велосипед. Надо изобретать агрегатор проката электровелосипедов.

Поиск