Поводом для этой статьи стала другая публикация на Хабре. Называется она «Не учите фреймворки, учите архитектуру» и почитать ее можно здесь.
Сразу оговорюсь, что с автором я полностью согласен и всего лишь хотел бы добавить свои «три копейки». Сначала думал сделать это прямо в комментах под статьей, но быстро понял, что «копейки» получаются довольно объемные. Так и родился этот текст.
Сначала немного о себе
Веб разработкой я занимаюсь года так эдак с 98-го. Работал и на компании и фрилансером. Сам набирал команды. Как в реале так и в сети. Первым языком программирования был ныне благополучно почивший perl и о его безвременной кончине жалею до сих пор. Потом пришел php. Еще чуть позже ruby и началась эра фейерверков.
Большие обещания маленькие достижения
Встретил я ее с энтузиазмом. Действительно — вроде бы появился инструмент призванный существенно облегчить разработку, способный избавить от большого количества рутины. Однако энтузиазм быстро улетучился. И вот почему.
Не знаю кто как, но я, в первую очередь, ждал избавления от большого количества однообразных действий, которые приходилось выполнять при работе над каждым новым проектом. Проектировать «костяк» базы, писать вывод по сути одинаковых текстовых страниц и т.д и т.п. Кто написал достаточное количество сайтов без труда дополнит это список многими и многими пунктами. И большинство фейерверков действительно избавляют от кучи рутины. Но какой ценой!
И это раз… и это два…
Эраст Фандорин
Моя первая претензия и к RoR, и Yii, и Symfony, и почти всем иным, с которыми пришлось познакомиться — их монстрообразность и тонны совершенно лишнего кода, который неизменно оказывается в проекте. Привыкнув за много лет работы, что код должен быть максимально чистым и лаконичным, что приложение должно быть как можно более быстрым, я в не мог согласится с тем мусором (уж извините по-другому сказать не могу), что оказывался в проектах.
Вторая претензия — попытка всех без исключения авторов фейерверков изобрести, что-то вроде своего языка программирования. Поясню о чем это я. Возьмем к примеру самую распространенную js библиотеку jQuery. При этом сразу оговорюсь, что именно ее я считаю чуть ли не единственно полезной, грамотной и еще много-много лестных эпитетов, среди подобных. Привожу jq в качестве примера только потому, что наверняка всем будет понятно о чем я. И так получить доступ к элементу по ID на нативном js можно так document.getElementById(«id»), а на jQuery так $(«#id»). То что при этом было написано на десяток символов меньше, меня на сильно впечатляет. При этом jq имеет кучу других плюсов ради которых я готов освоить новый синтаксис. Кроме того она надежна и практически никогда не конфликтует с другими библиотеками. Чего не скажешь и куче ей подобных, которые прочат на замену.
Еще раз оговорюсь — я ни в коем случае не против учить что-то новое. Но только если это новое делает мой код лучше чище и быстрее. Если же мне нужно выучить что-то ради того что бы я потом как обезьянка мог клепать однотипные сайты и ни смел сделать шаг влево шаг вправо потому что просто не знал как — увольте.
Да самое плохое, что подобный подход к программирование просто отучает думать и когда этот новый супер крутой фейерверкер дает сбой, а это, поверьте случается сразу же как только клиент попросит от вас что-то хоть чуть выходящее за рамки, горе фейерверкер (недавно узнал, что есть теперь такая профессия) впадает в ступор и начинает задавать глупые вопросы на все доступных ему форумах. Закачивается же все тем, что кто-то из программистов (не фремверкеров) лепит для него костыль и дай Бог, чтобы заказчик не провел аудит кода.
И это три…
Он же
Все выше сказанное касается не только front, но и back. Как следствие возникает вопрос — в самом начале я признал, что в ходе любой разработки приходится выполнять множество ненужных телодвижений, которые хотелось бы оптимизировать, но можно ли это делать такой ценой? А кроме того есть еще один момент, который в большей части касается разработки на Ruby.
Для реализации самых элементарных функций web приложения вам необходимо подключать отдельные gem-ы. Чтобы подкормиться к базе — mysql2, чтобы отправить mail — mail или созданный на его основе poni. И так далее и тому подобное. На первый взгляд ничего страшного в этом нет — все gem-ы в Ruby, как правило, хорошо оттестированы и проблем с ними не возникает. Но из этого правила тоже есть исключения. Например один раз целую неделю пришлось просидеть с odf-report, который ни как не хотел корректно работать, а потом плюнуть и написать свой класс. Кроме того несколько напрягает, что с подключением каждого gem-a неизбежно возрастает время формирования страницы. На некоторых gem-aх совсем незначительно. А не некоторых…. Попробуйте поэкспериментировать на эту тему с уже упомянутым pony — сами убедитесь.
Извечный вопрос
И что же делать? C одной стороны разработка на «чистом» языке — однозначно не вариант, а с другой и существующие инструменты не устраивают по целому ряду причин? Выход видится в создании инструмента, который бы оптимизировал наиболее часто используемые функции и одновременно не стеснял программиста, и не навязывал ему стиль программирования который автор этого инструмента считает единственно правильным. На практике, это означает, что инструмент должен:
- содержать минимальный набор стандартных, максимально оптимизированных функций
- инструмент не должен заставлять программиста изучать что-то вроде нового «недоязыка» программирования полностью отключающего
- и все это, в идеале, должно быть оформлено в легкую библиотеку, не пытающуюся тягаться по объему кода с операционной системой.
Может я не прав, но пока, что в обратном меня переубедить ни кто не смог. Готов выслушать любые мнения.
Автор: Жрец
