Сегодня речь пойдёт о простоте. Не та, которая согласно русской пословице хуже воровства, а о важнейшем принципе работы, которым должен руководствоваться не только любой админ или разработчик-программист, но и вообще любой работник в любой сфере деятельности. Принцип звучит так: «Будь проще!» А что же имеется в виду? А то, что любое изделие или программа должны быть максимально простыми в устройстве. Настолько простыми, насколько это возможно.
В наш просвещённый век отомороженных разработчиков, которые выучив один язык программирования считают себя мегакрутыми, они начинают часто придумывать то, что давно придумано до них, но чего они в силу своей фатальной неграмотности не знают. При этом изобретая велосипеды, они рождают монстров и уродов, но это ещё не самое страшное. Страшно, когда это дурацкое знамя подхватывают другие, такие же безграмотные и отомороженные, которые начинают этим пользоваться, внедряют это в проекты, расхваливают, делают модным. В результате смотришь на это и челюсть просто брякает о стол и голова кружится от дой дурости, которая процветает повсеместно.
Хотите пример? Пожалуйста. Представляю вашему внимаю чудо-юдо-сборщик проектов на PHP под название phing. Итак, какому-то идиоту, который видимо не научился пользоваться Make, пришло в голову, что как-то неудобно высранные им PHP-файлики собирать в проекте, если их много. Ну и гения конечно осенило — надо сделать сборщик! И он его сделал! Вот перевод с официальной страницы проекта:
—
Phing — это система сборки PHP-проектов или инструмент сборки на основе Apache Ant. С ней вы можете делать все, что вы могли бы делать с традиционной системой сборки, такой как GNU make, а ее использование простых XML-файлов сборки и расширяемых классов PHP «задач» делает ее простой в использовании и очень гибкой инфраструктурой сборки.
Функции включают запуск модульных тестов PHPUnit (включая отчеты о результатах тестирования и покрытии), преобразования файлов (например, замена токенов, преобразование XSLT, преобразования шаблонов), операции с файловой системой, интерактивную поддержку сборки, выполнение SQL, операции Git, Mercurial и Subversion, инструменты для создания пакетов PEAR, генерацию документации (PhpDocumentor, ApiGen) и многое, многое другое.
Если вы обнаружите, что пишете собственные скрипты для обработки упаковки, развертывания или тестирования ваших приложений, то мы рекомендуем взглянуть на Phing. Предварительно упаковано с многочисленными готовыми модулями операций (задачами) и простой в использовании OO-моделью для расширения или добавления ваших собственных пользовательских задач.
—
Уже в этом опусе мы видимо много чуши и сейчас мы это разберём. Первое, что уже должно заставить задуматься: С Phing «можно делать всё, что вы могли бы делать с GNU make». И сразу возникает вопрос, а раз всё можно сделать с Make, зачем вообще нужен Phing? Make прост, понятен и вылизан годами эксплуатации, а что Phing? «Простые XML-файлы сборки» куда сложнее для чтения и понимания, чем Makefile, а к «классам задач», которые разработчики считают священной коровой, мы вернёмся чуть ниже.
Проблема в том, что простота Makefile совершенно несопоставима с Phing. Свой первый Makefile вы можете написать спустся минуту после того как вы начали читать документацию. И это реально настолько просто, что вы сразу понимаете как и куда двигаться дальше. С Phing вы сможете писать только изучив все эти простые «XML-файлы сборки» с кучей их директив, а затем изучить ещё и классы, которые для вас приготовили разработчики. Порог вхождения в продукт растёт, понимание падает. Налицо нарушение принципа «будь проще».
Ну и давайте как вишенку на торте, посмотрим один пример «простого XML-файла» на Phing который я нашёл на просторах Интернета:
<project name="test" basedir="." default="server">
<target name="archive" depends="">
<echo>Архивируем проект</echo>
<zip destfile="phing.zip">
<fileset dir=".">
<patternset>
<include name="**/**"/>
<exclude name="vendor/**"/>
<exclude name="tests/**"/>
<exclude name="composer.*"/>
<exclude name="adminer-*"/>
<exclude name="codeception.*"/>
<exclude name="build.xml"/>
</patternset>
</fileset>
</zip>
</target>
<property name="uname" value="" override="false"/>
<property name="pwd" value="" override="false"/>
<property name="host" value="" override="false"/>
<property name="todir" value="" override="false"/>
<target name="build" depends="archive">
<echo>Отправляем на сервер</echo>
<scp username="${uname}" password="${pwd}" host="${host}"
fetch="false" file="phing.zip" todir="${todir}"/>
<echo>Удаляем архив с локали</echo>
<delete file="phing.zip" />
<echo>Подготавливаем директорию на сервере</echo>
<ssh username="${uname}" password="${pwd}" host="${host}"
command="rm -rf ${todir}/www"/>
<echo>Разархивируем на сервере</echo>
<ssh username="${uname}" password="${pwd}" host="${host}"
command="unzip -o -q ${todir}/phing.zip -d ${todir}/www"/>
<ssh username="${uname}" password="${pwd}" host="${host}"
command="chmod -R 777 ${todir}/www/templates/{cache,compiled}"/>
</target>
</project>
Посмотрите, вас нично не смущает? Так в итоге, несмотря на «классы задач», люди сводят написание XML-файлов к вызову всё тех же shell-команд. Там где в Makefile бы написали:
HOST="foo"
здесь вы пишете
<property name="host" value="foo" override="false"/>
как по вашему, что проще?
Ну и про «классы задач». Я не буду спорить, что в Phing есть готовые классы для выполнения каких-то комплексных действий. В случае их примнения они заменят много строк на shell. Но тут есть несколько больших НО:
- Чтобы ими пользоваться надо их изучить со всеми параметрами и т.д.
- А устроит ли эти самые классы разработчика, которому суждено им пользоваться? Может быть изучив потенциально подходящий класс он скажет, что он пользоваться им не будет, потому что тут не хватает чего-то, что нужно именно в его проекте?
- Никто и ничто не мешает вам, написать на shell код, который будет реализовывать все эти классы и преспокойно использовать его, вызывая как функции в Makefile
И вот посмотрев на то на это делаешь вывод — что Phing ненужная хрень, которую ни в коем случае не надо изучать, а надо просто выкинуть за недобностью, закидав разработчика гнилыми помидорами и отправиь учить Make.
Пример, как вы понимаете, не единственный, хотя и очень показательный. Например, чего стоит система компиляции файлов стилей .css, для которой нужно установить и настроить аж NodeJS? Это же надо было такую долбаную хренотень придумать?