Зачем нужны фреймворки?

Статья для начинающих программистов (попытка привести понятные обоснования).

Тот самый вопрос, который задает начинающий программист, и на который обычно получает расплывчатый ответ от опытных разработчиков: «это удобно», «быстрее разработка» и тому подобная, с точки зрения задающего, ерунда. Ситуацию осложняет тот факт, что проекты на фреймворках работают обычно медленнее аналогичных, написанных «с нуля». Любой нормальный программист, стремится оптимизировать параметр скорости по максимуму, поэтому недоверие и непонимание фреймворков лишь усиливается.

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

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

Через определенное время, когда текст и алгоритмика (части) кода благополучно забыта, нам поступает задание внести изменения в логику или исправить баг и т.д. Открываем исходники, — там хитроумные условия с ветвлениями, и другие архитектурные «ошибки» в угоду скорости. Начинаем тратить время, которое, как договорились выше, 1000р/час. Много времени, иногда не час и не два.

Вообще, как думаете, на что больше всего времени тратит по статистика программист? На чтение кода! Значит, есть смысл упростить сие занятие по максимуму, то есть, строить простую архитектуру и избегать сложных элементов (хитроумные условия, лютые регулярки, излишнее ветвление и пр.)

Переоптимизировав код, сколько выиграли в производительности миллисекунд? Одну? Две? Десять? Важно понять: машинное время стоит значительно дешевле, и экономить его не всегда имеет смысл, особенно когда речь о малых долях секунды. Здесь понятие растяжимое, но фанатизм точно неуместен. Перестаем печалиться, касаемо «сжираемых фреймворком просто так» ресурсов. Излишняя экономия, в итоге, обходится проекту очень дорого. Кроме того, излишне оптимизированный код часто становится сильно связанным. То есть монолитным, его трудно разделить на изолированные подсистемы.

Чем больше кода сможем использовать в других проектах, тем быстрее будет идти разработка. Вот вам и тот самый ответ «ускоряет разработку». Мы должны всегда стараться избегать сильно связанного кода, потому как он и модификации поддается крайне тяжело и реюзать его проблематично. Еще один признак – исправляем в одном месте, разваливается совершенно в другом. Знакомо? =)

И вот тут мы с идеей слабосвязанного кода подходим к парадигме ООП, но главное, к набору бест-практик, которые принято называть шаблонами разработки (проектирования) – design patterns. Именно они во многом позволяют писать хороший, как говорят, «прозрачный» код. Разделять задачу на независимые блоки. Есть такой термин – инверсия зависимости, когда частное как бы зависит от общего, а не наоборот.

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

Причем же здесь фреймворки, спросите вы? Вся соль как раз и есть, что они построены на паттернах, и сами по себе, не представляют абсолютно никакой сложности. Примитивно говоря, фреймворк всего лишь набор паттернов с небольшой обвязкой вокруг (glue layer-ом). Вам не нужно (и бестолку) заучивать конструкции из мануала того же Symfony или Laravel. Часто, малоопытные специалисты, зная спрос рынка, стараются поскорее изучить тот или иной продукт и начинают не с того края. Поймите, опытный собеседник в один момент поймет, заучили вы мануал, или действительно понимаете, о чем говорите.

Путь к фреймворкам примерно такой: базовые понятия ООП -> паттерны -> Symfony/Laravel (you name it). Причем все они, по мере скилла, будут казаться весьма похожими, чуть ли не одинаковыми.
Надеюсь, теперь вам понятно, почему именно: удобно, быстро; и почему бизнес приветствует разработку на фреймворках.

Удачи!

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *