Блог

Недавно я реализовал пару веб-приложений аналогичного размера, одно из которых использовало «фреймворк», а другое я закодировал сам, но использовал набор существующих (в основном с открытым исходным кодом) библиотек для обеспечения определенной общей функциональности, для которой я бы в противном случае использовал фреймворк.

Я заметил следующее:

• Приложение на основе фреймворка, безусловно, было быстрее в настройке — оно эффективно работало «из коробки». Однако со временем, по мере добавления дополнительных функциональных возможностей, его обслуживание стало становиться все более сложным. Как только мне понадобилось что-то, что не «подходило» под фреймворк, я оказался вынужден прибегнуть к некоторым уродливым обходным путям.
• Для приложения на основе библиотеки требовалось больше кода в начале, чтобы ввести и интегрировать необходимые библиотеки, т. Е. Вначале было необходимо написать разумное количество склеивающего кода. Но оказалось, что его легче расширять и изменять со временем, потому что не было никаких ограничений, связанных с необходимостью вписываться в дизайн фреймворка.

Из этого личного опыта у меня сложилось впечатление, что использование фреймворка можно рассматривать как антишаблон для обеспечения долговременной поддержки приложений.

Так ли это на самом деле?

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

Самая большая проблема, которую я вижу с фреймворками, заключается в том, что, используя фреймворк, вы отказываетесь от контроля. JB Nizet пишет «никто не заставляет вас использовать фреймворк для каждой части приложения», и это здорово, когда это так, но, к сожалению, обычно это не так. Обычно фреймворк обладает контролем, у вас есть свои обратные вызовы или производные классы, и когда вы хотите сделать что-то экстраординарное, вы не можете.

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

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

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

Каким бы ни был выбранный фреймворк, никто не заставляет вас использовать его для каждой части приложения. Если фреймворк облегчает разработку 90% приложения и делает его слишком сложным для оставшихся 10%, то просто не используйте фреймворк для этих 10%.

Я не думаю, что терминология шаблонов / антишаблонов очень полезна — она говорит примерно столько же, сколько прилагательные «хороший» и «плохой». Но я действительно думаю, что у большинства фреймворков есть серьезные недостатки.

Сначала давайте определим, что такое фреймворк:

• Фреймворк предоставляет обратные вызовы или аналогичный механизм, который вы можете подключить к своему собственному коду. Большая часть вашего собственного кода выполняется в рамках этих обратных вызовов.

Если фреймворк был человеком, его девизом могло бы быть «Не звоните нам, мы позвоним вам».

Тогда по определению вы вынуждены писать свой код в стиле, который соответствует фреймворку, а не в стиле, который соответствует приложению. Если эти два стиля не совпадают, уже существует очевидная проблема.

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

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

И тогда вам лучше с библиотекой, которая делает что-то одно, и делает это хорошо.

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