В поисках дофамина в разработке или избавляем себя от рутины

Каждый, кто начинает свой путь как программист имеет огромнейший запас энтузиазма, который поддерживает разработчика долгие годы. Каждый день что-то новое, новые методы решения проблем, технологии, и даже минимум результата — возносит на седьмое небо. Но время идет, Ваш код "устаканивается" и все действия, которые раньше были в новинку — стают рутиной. В такие моменты для поддержки мотивации без внедрения нового каждый день необходимо развивать свои рецепторы получения удовольствия, один из методов этого — организация своего workflow для максимальной наглядности результата. Об этом под катом.

Обо мне

Я разработчик PHP с 5-летним стажем, в своей практике успел попробовать в продакшне много разного, начиная от Zend Framework, заканчивая Symfony-Laravel экосистемой, Memcached-Redis, MySQL-Postgres, MongoDB, RabbitMQ-Gearman и т.д. Со временем стек технологий, которые захватывают Вас снижается, а с ним накатывает тоска по тому былому ощущению познания. Весь мой код и воркфлоу прошли мутации от правок самописных сайтов через FTP в продакшне, до грамотного подхода деплоя и анализа кода. На своем опыте я выделил список того, что позволяет получать максимум мотивации при минимуме действий.

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

Удобство разработки

Речь идет не об ортопедических стульях и десятке мониторов (хотя при наличии бюджета — это вряд ли навредит), а об очень простой и одновременно важной сфере — инструментах разработки. Если Вы серьезно занимаетесь проектом — просто необходимо настроить свое рабочее окружение максимально удобно. В идеале — использовать IDE с интеграцией и анализом, не только синтаксиса и логики всех ЯП, которые используются, но и с анализом на более высоком уровне — на уровне фреймворка и интеграций. Для примера: разрабатывая на Symfony из-под PhpStorm — очень сильно упрощает жизнь Symfony Plugin + PhpAnnotations Plugin. Таким образом часть мыслительной деятельности выносится на "аутсорс" в IDE, и освобождает мозг ^[1] для более серьезной работы.

Анализ кода и тестирование

Многие разработчики занимаются сугубо разработкой функционала, но, как показывает практика, не меньшее значение имеет базовое покрытие юнит тестами. Это достаточно рутинный процесс, который иногда может свести Вашу мотивацию в ноль. Начните с малого — покройте тестами End-части своего приложения, например — работу со сторонними Api, простую бизнес-логику на уровне I/O, и т.д., это покажет Вам этот функционал с другой стороны, позволит осознать какие решения были приняты правильно в конкретном случае, а какие лучше немедленно пересмотреть. Вырастет стабильность и качество разрабатываемого продукта, а это уже большой плюс.

Но как получить из этого долю заслуженного дофамина? Генерируйте coverage + статический анализ кода. Отчеты на выходе можно деплоить на тестовом сервере (staging, например) для постоянной доступности их разработчику (команде). Они превращают весь процесс покрытия тестами в своего рода игру, отображают классы, которые покрыты тестами, и подсвечивают что еще нужно покрыть, стимулируя "проходить эти уровни", для минимизации блоков непокрытого функционала. Например для PHP-проектов для юнит тестов обычно используют PhpUnit, в команду запуска которого можно добавить параметр --coverage-html (лучше глянуть --help для более подробной документации), который сгенерирует покрытие в удобном для человека формате. Для статического анализа кода в PHP можно использовать следующие продукты — phplint, phploc, phpcs, phpcpd, phpmd.

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

Версии

Как бы это не звучало банально — используйте системы контроля версий! Я знаю много разработчиков, для кого это "лишние проблемы", хотя поддерживаемые ими системы давно перевалили за CRUD. Системы контроля версий как минимум позволяют бекапить свой код, как максимум — грамотно контролировать выкатку кода, сравнение, версионирование и много-много другого. Как нажить на этом дофамина — каждая фича в своей ветке позволяет визуализировать процесс вливания кода в основное русло, теги — позволяют вести свой продакшн по версиям и наблюдать прогресс от версии к версии. Это, на самом деле, очень сильно движет дальше.

Сборка и дистрибуция

Так уж повелось, что сборкой люди привыкли считать компиляцию программы, опуская в этом понятии системы, которые запускает интерпретатор. В наш век миллиона PHP-пакетов и миллиарда js библиотек, понятие сборки уже не является чем то сугубо компиляторным, количество действий над системой, необходимых для ее запуска, давно перевалило за 1 десяток, поэтому важно максимально ускорить процесс развертки конкретного приложения, автоматизировав рутинные действия. Есть много приложений, которые занимаются сборкой вашего продукта, для PHP я выбрал для себя Phing, который можно легко установить через composer и описывать задания сборки в достаточно удобном формате (хоть и xml, но интуитивно понятно даже новичку на примере). Цель данных манипуляций — свести развертку продукта до нажатия кнопки "сделать все хорошо".

Подтягивание пакетов, поставка актуальных конфигов, запуск миграций, выполнение тестов, warmup кеша — это малая часть того, что может делать сборщик. Даже если Ваш код еще никуда не деплоится, в будущем, наличие автосборщика существенно упростит начало разработки проекта на новой машине и существенно упростит деплой и релизы софта. В паре с Continuous Integration (CI) системами — вся рутина уходит на плечи машин, предоставляя Вам пространство для полета фантазии и, непосредственно, решения задач. Ну, и как минимум, имеем меньше шанса забыть что-то сделать при деплое.

Как выдавить капельку дофамина из этого — найдите баланс в автоматизации сборки своего продукта, начните с простых вещей, и попытайтесь глянуть как это работает хотя бы в песочнице, даже с минимальным количеством потраченных часов ощущение того, что машина работает за вас — непередаваемое. Для примера я использую Jenkins в качестве CI системы, у которого установлен плагин Phing. Достаточно в сборщике выбрать шаг сборки "Invoke Phing Target" — и все зашуршит, завериться, соберется.

Общая визуализация процессов

Очень заряжает ощущение контроля над системой, поэтому попытайтесь визуализировать максисум продуктов, которые используете. Начиная со статистики по загрузке сервера, до визуализации различного ПО, с которым работает Ваш продукт. К примеру — для RabbitMQ есть Management Plugin, в виде web-интерфейса для просмотра статистики и содержания очередей, очень помогает в отладке, а в продакшне — для контроля оптимальности работы процессов.

В целом для визуализации логов есть очень много софта, который можно подобрать под свои нужды, основная цель — предоставить себе максимально возможную визуализацию того, что происходит в Ваших продуктах (особенно актуально для Service Oriented Architecture (SOA), где множество компонентов общаются между собой). Информация о Вашей системе даст не только возможность быстрой отладки происходящего, а и моральное удовлетворение от наблюдения изменений, динамики. Все узкие горлышки сразу видны, все неоптимальные части системы под Вашим надзором.

Совместимость

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

Вывод

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

Заключение

Данный пост предназначен в первую очередь разработчикам выше новичка, которые хотят улучшить (или сравнить) свой workflow. Весь изложенный материал взят сугубо из своего опыта, если есть замечания — с радостью выслушаю в комментариях.

Автор: iqw

Источник ^[2]