Фреймворки, apache commons и велосипеды - единство борьбы противоположностей

Привет, тора гой дневничок. В очередной раз рука зависла над кнопочкой “Send Pull Request”, и вот тут пиздец подкрался незаметно. Короче, мне там надо переделать базу данных, но уже лень - потому ниже будет сага о Форсайтах фреймворках.

Об этих самых фреймворках не слышал только упоротый ембедщик в подвале (и то не факт, что у них нет своего хайбернейта для хранения битовых полей). В научно-популярной литературе этот самый фреймворк определяют как некую абстракцию, которая призвана счастья для всех и сразу сделать всем заебись вот прямо сейчас. Ну потому что бОльшая часть уже как бы украдена до нас, и надо все чуточку настроить. Это находит живейший отклик в душе всех без исключения адептов секты ООП, потому что красиво и правильно укладывается в картину мира WORA, code reuse и прочие Unix-way. Никому не хочется писать в стопиццотый раз парсер CSV например.

Диалектика - штука разнообразная, и в принципе универсальные решения, все эти шаблоны проектирования - не что иное, как способы передачи сакральных знаний от седых мудей, которые еще Cobol видели - к юным и неиспорченным ганглиям, которые со студенческой скамьи перебираются в необременительные дебри промышленного причинения пользы. Кроме того, разным прошаренным чувакам хочется продавать литературу типа “AJAX за 21 день” или “CSV in Action” - что тоже хлеб, все хотят таки кушать.

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

Для примера, рассмотрим среднестатистического программиста, который пришел на работу в контору Рога И Копыта, Inc. После прохождения кругов ада, именуемых в разговорной речи техническими интервью, интервью, интервью с заказчиками, интервью с любовницей-директора-по-совместительству-начальника-HR - наступают суровые трудо выебудни испытательного срока, в которых программисту например требуется заговнокодить некий сервис доступа к базе данных. В этот момент может наступить ветвление, состоящее из

  • возьмем, для примера, JDBC, нахерачим в него SQL запросов, сдадим и скажем что так и было
  • почитаем про Hibernate, проникнемся JPA и прочим CMP

и дальше все будет зависеть только от глубины фантазии программиста и степени осведомленности тимлида (ну или кто там ответственный за кусок проекта) о черни, происходящей внутри.

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

Возвращаясь к примеру, есть определенная корелляция между опытом программиста и принимаемым решением.

Так, личинка джуниора, не обремененная багажом знаний, скорее всего выберет JDBC - потому что именно про него пишут во всех книгах. В результате может (и скорее всего) получится закат солнца вручную, с открытием нового коннекта на каждый запрос, оставлением висящих соединений в базу и прочими ужасами пустых блоков catch, за которые принято отрезать по сантиметру МПХ за каждое нахождение оных в коде на peer-review.

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

Еще один пример - это подсчет MD5 от чего-то. В интернетах есть штуки, которые умеют это делать, как-то

Что сделает 99% жабодевелоперов? Конечно же добавит одну из этих штук в зависимости проекта, заимпортирует нужный класс - и все как бы станет заебись. В то же время можно было бы взять банальный MessageDigest - и проблема была бы решена - но это же не наш метод. К сожалению, в java нет возможности сделать strip для используемых библиотек, ввиду наличия RTTI и прочих generics. Это означает - присунув в проект модной библиотекой, и используя из нее два метода - вы добавляете в класслоадер туеву хучу классов. А если у вас нидайбох используется Maven-оподобная система, то есть ненулевая вероятность получения комплектом еще полгигабайта транзитивных зависимостей. Если вы используете GWT - мои поздравления, внутри GWT-Dev есть десятки библиотек типа того же Commons-IO, слегка протухших версий. И если вдруг у вас в classpath gwt-dev окажется перед вашей версией Commons-IO - то случайно можно отхватить прелестей типа ненайденных методов и конструкторов.

Противоположностью использования 1% функциональности сторонних библиотек конечно же будет являться изобретение велосипедов самостоятельно. Из знакомых мне примеров - закодирование частей SQL запросов в Enum-ы, чтобы потом их конкатенировать, вместо использования хотя бы и MyBatis, написание своих классов коллекций с весьма забавными эффектами на граничных условиях. Тема велосипедов вообще достаточно обширна для эссе на многие страницы - мантра “все уже украдено до нас” не находит широкого распространения. В частности, это приводит и к обилию фреймворков на все случаи жизни. Ведь нет ничего приятнее, чем высосанный из пальца набор фабрик синглтонов над обсерверами стратегий флайвейт прокси для итераторов строк - гордо обозвать Modern CSV Parser on steroids, покрошить сверху чуточку парсер-комбинаторов и аппликативов - и вуаля. Очередной недофреймворк, решающий задачи самореализации авторов через графоманство в исходном коде - готов к принятию в Apache Incubator.

Резюме

Нет ничего в использовании простых и понятных решений - это не больно. Шаблоны проектирования и прочий мусор от ФП как правило хорош для потрясания мудями в сетевых выяснениях у кого монады длиннее - в реальной же жизни чрезмерное усложнение системы чревато ее коллапсом. Лучше взять 2 простых библиотеки и дописать к ним своего кода - чем взять один толстый Spring Social - и потом ходить в форумы камлать подземные стуки в класслоадерах,

Keep Is Simple, Stupid.