Статья для начинающих программистов (попытка привести понятные обоснования).
Тот самый вопрос, который задает начинающий программист, и на который обычно получает расплывчатый ответ от опытных разработчиков: «это удобно», «быстрее разработка» и тому подобная, с точки зрения задающего, ерунда. Ситуацию осложняет тот факт, что проекты на фреймворках работают обычно медленнее аналогичных, написанных «с нуля». Любой нормальный программист, стремится оптимизировать параметр скорости по максимуму, поэтому недоверие и непонимание фреймворков лишь усиливается.
Сегодня попробую максимально доходчиво объяснить молодым коллегам, почему же все-таки фреймворки настолько популярны и почему их использование не только значительно упрощает жизнь разработчику, но и многое говорит о его квалификации.
Начнем, пожалуй, с простых фактов. Да, конечно же, оптимизировать свой продукт и делать его максимально шустрым необходимо. Однако, давайте посмотрим на вопрос чуточку с другого ракурса, с позиции бизнеса. Работодатель (вообще любой заказчик), на самом деле, платит нам не только за знания, но и за время, которое мы тратим. То есть, час работы опытного разработчика стоит, к примеру, 1000 рублей. Когда мы пишем сильно оптимизированный на производительность код, он неизбежно усложняется.
Через определенное время, текст и алгоритмика (части) кода благополучно забыта, нам поступает задание внести изменения в логику или исправить баг и т.д. Открываем исходники, — там хитроумные условия с ветвлениями, и другие архитектурные «ошибки» в угоду скорости. Начинаем тратить дорогостоящее время, которое, как условились, 1000р/час. Много, иногда не час и не два, даже несколько дней!
Вообще, как думаете, на что больше всего времени тратит, по статистике, программист? На чтение кода! Значит, есть резон упростить сие занятие по максимуму, то есть, строить простую архитектуру, избегать сложных элементов (хитроумные условия, лютые регулярки, излишнее ветвление и т.д.)
Переоптимизировав код, сколько выиграли миллисекунд в производительности? Одну? Две? Десять? Важно понять: машинное время стоит значительно дешевле, и экономить его не всегда имеет смысл, особенно когда речь о малых долях секунды. Здесь понятие растяжимое, но фанатизм точно неуместен. Перестаем печалиться, касаемо «сжираемых фреймворком просто так» ресурсов. Излишняя экономия, в итоге, обходится проекту очень дорого. Кроме того, излишне оптимизированный код часто становится сильно связанным. То есть монолитным, его трудно разделить на изолированные подсистемы.
Чем больше кода сможем использовать в других проектах, тем быстрее будет идти разработка. Вот вам и тот самый ответ «ускоряет разработку». Мы должны всегда стараться избегать сильно связанного кода, потому как он и модификации поддается крайне тяжело и реюзать его проблематично. Еще один признак – исправляем в одном месте, разваливается совершенно в другом. Знакомо? =)
И вот тут мы с идеей слабосвязанного кода подходим к парадигме ООП, но главное, к набору бест-практик, которые принято называть шаблонами разработки (проектирования) – design patterns. Именно они во многом позволяют писать хороший, как говорят, «прозрачный» код. Разделять задачу на независимые блоки. Есть такой термин – инверсия зависимости, когда частное как бы зависит от общего, а не наоборот.
Бывает, новички пишут код с применением классов, но, по сути, остаются на процедурке, просто используют некоторые инструменты ООП, чаще всего инкапсуляцию и наследование. Так вот, код на классах еще не означает объектно-ориентированный подход. Изучайте паттерны, они помогут осознать парадигму и увидеть ее преимущества. На самом деле, в настоящем ООП гораздо чаще используется полиморфизм. Строго говоря, он и является основным инструментом.
Причем же здесь фреймворки, спросите вы? Вся соль как раз и есть, что они построены на паттернах, и сами по себе, не представляют абсолютно никакой сложности. Примитивно говоря, фреймворк всего лишь набор паттернов с небольшой обвязкой вокруг (glue layer-ом). Вам не нужно (и бестолку) заучивать конструкции из мануала того же Symfony или Laravel. Часто, малоопытные специалисты, зная спрос рынка, стараются поскорее изучить тот или иной продукт и начинают не с того края. Поймите, опытный собеседник в один момент распознает, заучили вы мануал, или действительно понимаете, о чем говорите.
Путь к фреймворкам примерно такой: базовые понятия ООП -> паттерны -> Symfony/Laravel (you name it). Причем все они, по мере скилла, будут казаться весьма похожими, чуть ли не одинаковыми.
Надеюсь, теперь вам понятно, почему именно: удобно, быстро; и почему бизнес приветствует разработку на фреймворках.