RE: The MicroPHP Manifesto

Меня всегда удивляла способность некоторых людей возводить всё в абсолют. Они мыслят чёрно-белыми категориями. Как будто есть только “да” и “нет”, “хорошо” и “плохо”. Мир серый, люди! И в жизни есть 40  оттенков чёрного.

xx> Пошёл в магазин, купил там новых носков,
одинаковых, обычных, чёрных, без рисунков и всякой фигни……
xx> Живи и радуйся.
yy> чувак ТЫ ГЕНИЙ!
yy> готовься познать дао
сорока оттенков черного, гений 😉

// bash.org.ru

Написать этот пост меня побудил топик TheMicroPHP Manifesto на хабре. А вот и оригинал на английском. И мне захотелось написать свой “ответ”.

Только ситхи всё возводят в абсолют.

Основная мысль данного манифеста в принципе правильная: писать надо только то, что надо. Но она возводится в абсолют – не нужны никакие обертки, не будем использовать фреймворки (“тяжелые” фреймворки типа Zend Framework или Symfony). Это всё не к чему. Надо стремиться к минимализму. Если количество кода, написанного автором меньше, чем количество кода фреймфорка – то это плохо. Значит автор считает, что количество инфраструктурного кода должно быть всегда меньше, чем количество программного кода бизнес-логики. Феерично, что сказать. Ведь именно инфраструктурный код (уже написанный например в ZF) даёт нам, разработчикам, возможность сосредоточится на действительно своей работе – написанию кода бизнес-логики = того, что нужно заказчику. Т.е. используя фреймворк мы как раз таки пишем меньше, чем при подходе псевдо-минимализма, выраженного в The MicroPHP Manifesto. Значит не такой уж это и минимализм. Что-же это? Стремление к говнокодингу? Скорее да, чем нет. На харбе один из комментов был такой:

Любой, кто воспринимает этот манифест, как руководство к действию, НИКОГДА не написал ни одного серьезного большого проекта! Микрофреймворк хорош для микропроекта, выполняющего одну, две функции, но когда проект разрастается любой адекватный разработчик понимает, что он выходит за рамки микрофремворка, и идет дальше. Есть люди, которые не хотят идти дальше и пишут костыли, другие переделывают архитектуру. // habr

Вот она истина – микрофреймворк хорош для микропроекта, а не для полноценного enterprise решения. Мой научник всегда говорит  «отталкивайся от задачи, Андрей». Иными словами, чёткое понимание задачи и её ближайших перспектив даёт нам возможность выбора оптимального инструмента. Если вам надо написать сайт-визитку – это одна задача, а если распределённое веб-приложение, держащее приличную нагрузку – это совсем другая песня.

Zend Framework vs микрофреймворки



Теперь поговорим про зенд. Многие сталкиваясь с ZF видят сложный код, видят верхушку уровней абстракции, и считают что он сложен, тяжел для понимания. НО, никто не заставляет вас использовать весь ZF. Он как лего, вы можете использовать только тот компонент, который вам нужен. Что самое забавное – эта же мысль есть и в вышеупомянутой статье:

Для дополнительного функционала я беру легковесные библиотеки, которые помогают мне решить поставленные задачи. Четкость и краткость – это то, на что я обращаю внимание в первую очередь.

Ну а что мешает автору брать те же легковесные, но совместимые друг с другом компоненты ZF? Думаю незнание фреймворка, или просто отсутствие практики. Сейчас довольно много кодеров, которые один раз посмотрев на ZF ставят на него клеймо. Мне искренне жаль таких людей. Ведь они сами себе создают проблемы. Им приходится либо писать “велосипеды” (например для пагинации страниц), которые уже давно написаны (скажем в ZF) и что самое главное оттестированы! Такие разработчики как раз добавляют себе работы тем, что им в такой ситуации приходится писать инфраструктурный код, и меньше времени остаётся для бизнес-логики.

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

Детерменизм или функциональность

Детерменизм отделяет сущности и предлагает использовать в практике одну вещь для реализации одной функции. Телефон – для того, чтобы звонить, фотоаппарат – чтобы фотографировать. Основной посыл – фотографии с телефона никогда не будут лучше, чем фотографии с фотоаппарата. Принцип функциональности предлагает нам совмещать ряд функций в одном устройстве, например смартфон вполне в состоянии справиться с фотографированием и звонками, да ещё и в интернет будет выходить. А то что фотки не такие качественныые – это ничего, всё равно нам качество не нужно, а дополнительная возможность может оказаться не лишней при необходимости.

Холивары про фреймворки очень часто скатываются в эту сторону. Универсальное решение (ZF) плохо подходит для какой-то конкретной задачи. Моё мнение такого. ZF – отлично кастомизируем, и полностью приспособлен к решению практически любых задач. Если что-то не нравится – всегда можно отнаследоваться и переписать нужный кусок. Можно использовать другой. Можно даже спуститься на C уровень и работать там, добиваясь оптимизации конкретной задачи (об этом я ещё напишу). Иными словами пробелма  выбора не стоит. Можно использовать компоненты ZF детерминировано (например только Zend_Config), а можно функционально (с Zend_Application и прочими плюшками).
Выбор всегда за вами!

Заключение

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

Ссылки

http://habrahabr.ru/blogs/php/139115/

http://microphp.org/

4 Comments

  1. Спасибо, за хорошую идейную статью. Я всегда говорил, что инструмент подбирают под задачи. Моё знакомство с ZF изначально было ещё в то время когда я был далек от ООП. И на то время я понимал что это пока не мой уровень. Но в скорее я набрался знаний, опыта и пришел к тому, что нужно было как то подобрать для себя стартовую платформу, и писать именно бизнес-логику. Не знаю как кому, мне ZF очень нравиться, может потому, что я кроме всего прочего дизайнер ). Да не спорю изучать его не так легко, но всё приходит со временем.

    1. Именно! Вы очень точно уловили мою мысль.

  2. Вы тоже описываете одну из крайностей.
    ZF не самый лучший пример, на котором можно разбирать преимущества больших фреймворов (Симфони тоже)
    Я 3 года использовал ZF и он меня порядком подзадоел. Пробовал сделать проект на симфони, тоже не пошло. Сейчас уже 2 года использую Yii, получаю такой же результат, при этом пишу в два раза меньше строк и букв.
    По той же причине, товарищь, 2 года программируя на ZF, перешел на рельсы.
    ZF закостенелый старикан. Это как prototype и jquery, все перешли на второй, т.к. меньше бекв надо писать и меньше бороться с мельницами.
    Причина та же, о которой вы пишете, надо писать бизнеслогику, а не утилитарный код с кучей строк вида путь_пакет_подпакет_пакета_забылчто_мойкласс_класс() а до этого ещё пять подобных классов, которые сетапят или передаются в основной.

    1. Согласен, используя ZF можно уйти в крайность. Действительно слишком большая гибкость, обилие возможностей, которые скорее всего никогда не понадобятся, и при этом тянут за собой кучу зависимостей – не есть хорошо. Это как раз та причина, по которой люди думают, что не надо использовать ZF.
      Проблема шире. Адаптеры, фасады и декораторы. Использование паттернов там где это не надо, overengeneering – вот то, о чём вы говорите. ZF действительно перекошен в сторону гибкости, не спорю, Yii более лаконичный. Но мне всё равно нравится ZF. Возможность (какая-нибудь фишка) есть, а использовать её или нет, и как использовать – это уже выбор разработчика.

Leave a Reply to Андрей Токарчук Cancel reply