Когда вы обсуждаете с поклонниками Framework, вот несколько аргументов, которые вы можете использовать, чтобы их опровергнуть (образно).
Многие разработчики используют фреймворки для создания своих приложений. Само по себе это не так уж и плохо.
Они дают вам возможность не выбирать. Парадигмы, языки, философия, стиль, паттерны. Все уже включено и исправлено.
Фреймворки позволяют осуществлять быструю разработку приложений или, как я люблю это говорить, разработку ориентированных на обучение прототипов (хотя RAD - определенно более крутая аббревиатура, чем TLFPD).
Но что происходит, когда все становится серьезным? Что произойдет, если ваш проект масштабируется с точки зрения кодовой базы, функций, стандартов и людей, работающих над ним?
Компромиссы, на которые вы пошли при создании приложения RAD, появятся в вашем бэклоге во всей красе своего технического долга.
Не только это.
К моменту принятия фреймворка вы уже делегировали ему самые важные решения по вашему проекту:
- стандарты качества;
- стиль кодирования;
- шаблоны приложений;
- форма логики предметной области;
- представление данных;
… и так далее.
Да, да, я знаю. Хорошие фреймворки полностью настраиваются. Но вначале об этом никто не заботится, потому что в этом весь смысл фреймворка: вы просто хотите начать кодировать.
А когда ты хочешь изменить свое нежелание принимать решение, уже слишком поздно.
Фреймворки позволяют осуществлять быструю разработку приложений или, как я люблю это говорить, разработку ориентированных на обучение прототипов Throwaway Learning (хотя RAD - определенно более крутая аббревиатура, чем TLFPD).
Однако среди всех аргументов в пользу отказа от фреймворка есть три, о которых я хочу особо поговорить:
- Когда вы переходите на Frameworkless, вы не изобретаете велосипед;
- Фреймворки создают огромную беспорядочную поверхность;
- Бреду о «Рамках», посвященном разработчикам программного обеспечения, нужно положить конец.
Эти три момента настолько важны, что, как вы понимаете, обычно игнорируются при обсуждении среднего фреймворка да фреймворка нет.
Когда вы переходите на Frameworkless, вы не изобретаете велосипед
Отказ от фреймворка не означает, что вам придется писать все с нуля.
Поклонники фреймворков часто забывают, что есть несколько красиво упакованных артефактов, называемых библиотеками.
И угадай что? Их любимые фреймворки тоже используют их!
О каком колесе мы вообще говорим?
Только вы, как владелец проекта, знаете, строите ли вы скутер, трактор или спортивную машину.
Вы заслуживаете ответственности за то, чтобы выбрать колесо, которое соответствует вашим потребностям. И, возможно, размер, материал шины и качество винтов.
Фреймворки создают огромную беспорядочную поверхность
Я нашел формулу, объясняющую это:
Вероятность беспорядка = (поверхность платформы x размер группы) / принудительные ограничения
Чем больше поверхность фреймворка (а именно, количество общедоступных компонентов), а также размер и неоднородность команды, тем сильнее будет изменение, связанное с увязкой вашего проекта с техническими особенностями фреймворка.
Вашему проекту нужен издатель мероприятий. Во фреймворке есть система обмена сообщениями. Давайте изменим ваши потребности, чтобы они вписались в функции фреймворка!
Зачем вам нужно оценивать другие библиотеки, если во фреймворке уже есть компонент, который делает что-то, даже отдаленно напоминающее то, что вам нужно?
Зачем идти и покупать штопор, если у вас уже есть туфля и стена?
И наоборот, выбор ваших библиотек по одной путем их оценки в контексте вашего варианта использования значительно снижает эту возможность.
Кроме того, внедрение библиотеки - это то, что легче контролировать в большой команде. Подойдет быстрая проверка вашего списка зависимостей.
Попробуйте сделать это во всей кодовой базе, когда любой может просто сослаться на класс и сразу же начать его использовать.
Другими словами, фреймворки требовательны и очень энтропийны. Даже не замечая, они перестают работать на вас, и вы начинаете работать на них, в основном, чтобы не допустить выхода ситуации из-под контроля.
Ерунде о ‹Framework› разработчиков программного обеспечения необходимо положить конец
Хорошо, серьезно.
Нет ничего хорошего в том, чтобы назвать себя разработчиком программного обеспечения ‹Framework›.
Гордости тоже нет.
Что вы будете делать через 3–5 лет (6 месяцев для Javascript)? Менять название должности, потому что рамки вышли из моды, и делать это снова и снова?
Извините, у меня для вас очень плохие новости.
Все знания, которые вы накапливаете о самой личной, внутренней части вашего фреймворка, очень скоро станут бесполезными. Вы забудете об этом, чтобы освободить место для следующего фреймворка.
Вы помните тот красивый сертификат на 500 долларов, которым вы так гордились, что повесили его на стену в офисе? В конце концов, вы выбросите его в мусорное ведро.
Подбор персонала - тоже большая, большая проблема в этом плане.
Мне постоянно приходят предложения о вакансиях Laravel / Angular / React Developer.
Что мне ответить?
«Извините, я всего лишь разработчик, который разбирается в бизнесе и пытается решать проблемы более агностически».
Рекрутеры (по крайней мере, многие из них) не понимают разницы. Они только проксируют запросы своих клиентов.
Давайте перестанем просить их нанять ‹Framework› разработчиков, и если вы являетесь одним из них, пожалуйста, не называйте себя таковыми.
Вы только напрасно тратите свои усилия на то, чтобы накапливать знания, которые не будут полезны в долгосрочной перспективе.
Заключение
Если вы поклонник фреймворка и добрались до этого места, примите наши поздравления. Я этого не ожидал.
В вашу честь, я признаю, что есть несколько случаев, когда фреймворк может быть предпочтительнее выбора библиотеки.
Но это меньшинство.
Моя личная эвристика такова: если проект не имеет стратегической значимости или очень прост по масштабу, структура может иметь смысл.
Во всем остальном просто используйте свое истинное мастерство.