Каждый, кто начинает свой путь как программист имеет огромнейший запас энтузиазма, который поддерживает разработчика долгие годы. Каждый день что-то новое, новые методы решения проблем, технологии, и даже минимум результата — возносит на седьмое небо. Но время идет, Ваш код "устаканивается" и все действия, которые раньше были в новинку — стают рутиной. В такие моменты для поддержки мотивации без внедрения нового каждый день необходимо развивать свои рецепторы получения удовольствия, один из методов этого — организация своего workflow для максимальной наглядности результата. Об этом под катом. Я разработчик PHP с 5-летним стажем, в своей практике успел попробовать в продакшне много разного, начиная от Zend Framework, заканчивая Symfony-Laravel экосистемой, Memcached-Redis, MySQL-Postgres, MongoDB, RabbitMQ-Gearman и т.д. Со временем стек технологий, которые захватывают Вас снижается, а с ним накатывает тоска по тому былому ощущению познания. Весь мой код и воркфлоу прошли мутации от правок самописных сайтов через FTP в продакшне, до грамотного подхода деплоя и анализа кода. На своем опыте я выделил список того, что позволяет получать максимум мотивации при минимуме действий.  Примечание: Не стоит воспринимать информацию ниже как эталон организации ПО, данная информация может служить только примером для исследования подобных подходов в своей экосистеме. Некоторые вещи могут быть неприменимы для определенного круга систем, но и там общие принципы остаются те же. Речь идет не об ортопедических стульях и десятке мониторов (хотя при наличии бюджета — это вряд ли навредит), а об очень простой и одновременно важной сфере — инструментах разработки. Если Вы серьезно занимаетесь проектом — просто необходимо настроить свое рабочее окружение максимально удобно. В идеале — использовать IDE с интеграцией и анализом, не только синтаксиса и логики всех ЯП, которые используются, но и с анализом на более высоком уровне — на уровне фреймворка и интеграций. Для примера: разрабатывая на Symfony из-под PhpStorm — очень сильно упрощает жизнь Symfony Plugin + PhpAnnotations Plugin. Таким образом часть мыслительной деятельности выносится на "аутсорс" в IDE, и освобождает мозг для более серьезной работы. Многие разработчики занимаются сугубо разработкой функционала, но, как показывает практика, не меньшее значение имеет базовое покрытие юнит тестами. Это достаточно рутинный процесс, который иногда может свести Вашу мотивацию в ноль. Начните с малого — покройте тестами 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. Весь изложенный материал взят сугубо из своего опыта, если есть замечания — с радостью выслушаю в комментариях. Software Engineer