Каждый, кто начинает свой путь программиста, имеет огромный запас энтузиазма, который поддерживает разработчика долгие годы.
Каждый день что-то новое, новые методы решения задач, технологии и даже минимальный результат – поднимают вас на седьмое небо.
Но проходит время, ваш код «успокаивается» и все действия, которые раньше были новыми, становятся рутинными.
В такие моменты, чтобы поддерживать мотивацию, не вводя каждый день что-то новое, нужно развивать свои рецепторы удовольствия; один из способов этого – организация рабочего процесса для максимальной наглядности результата.
Подробнее об этом под катом.
Обо мне
Я PHP-разработчик с 5-летним опытом, за свою практику пробовал много разного в продакшене, от Zend Framework до экосистемы Symfony-Laravel, Memcached-Redis, MySQL-Postgres, MongoDB, RabbitMQ-Gearman, и т. д. Со временем набор увлекающих тебя технологий уменьшается, а вместе с ним приходит и тоска по тому прежнему ощущению знаний.Весь мой код и рабочий процесс претерпели мутации, от правок самописных сайтов через FTP в продакшене до грамотного подхода к деплою и анализу кода.
Опираясь на свой опыт, я определил список вещей, которые позволяют получить максимальную мотивацию при минимуме действий.
Примечание : Не следует воспринимать приведенную ниже информацию как стандарт для организации программного обеспечения; эта информация может служить лишь примером для исследования аналогичных подходов в вашей экосистеме.
Некоторые вещи могут быть неприменимы для определенного круга систем, но даже там общие принципы остаются прежними.
Простота разработки
Речь идет не об ортопедических креслах и десятке мониторов (хотя при наличии бюджета это вряд ли навредит), а об очень простой и в то же время важной области — инструментах разработки.Если вы серьезно работаете над проектом, вам просто необходимо настроить рабочую среду максимально удобно.
В идеале использовать IDE с интеграцией и анализом не только синтаксиса и логики всего используемого языка, но и с анализом на более высоком уровне — на уровне фреймворка и интеграций.
Например: при разработке в Symfony изнутри PhpStorm плагин Symfony + плагин PhpAnnotations значительно упрощает жизнь.
Таким образом, часть умственной деятельности передается IDE, и освобождает мозг для более серьезной работы.
Анализ и тестирование кода
Многие разработчики занимаются чисто разработкой функционала, но, как показывает практика, не менее важно базовое покрытие юнит-тестами.Это довольно рутинный процесс, который иногда может свести вашу мотивацию к нулю.
Начните с малого - покройте тестами Конечные части вашего приложения, например - работа со сторонним API, простая бизнес-логика на уровне ввода-вывода и т. д., это покажет вам этот функционал с другой стороны, позволит вам понять, какие решения были приняты правильными в конкретном случае, а какие лучше сразу пересмотреть.
Стабильность и качество разрабатываемого продукта повысятся, а это уже большой плюс.
Но как получить от этого часть дофамина, которого вы заслуживаете? Генерация покрытия + статический анализ кода.
Выходные отчеты можно развернуть на тестовом сервере (например, промежуточном) для постоянной доступности разработчику (команде).
Они превращают весь процесс покрытия тестами в своеобразную игру, отображая классы, которые покрыты тестами, и выделяя то, что еще нужно охватить, стимулируя «пройти эти уровни», чтобы минимизировать блоки непокрытого функционала.
Например, для PHP-проектов для модульных тестов обычно используют PhpUnit, в команду запуска которого можно добавить параметр --coverage-html (более подробную документацию лучше посмотреть на --help), который будет генерировать освещение в удобном для человека формате.
Для статического анализа кода на PHP можно использовать следующие продукты — phlint, phploc, phpcs, phpcpd, phpmd. ПРЕДУПРЕЖДЕНИЕ : Развертывая отчеты где угодно, позаботьтесь о том, чтобы скрыть их от внешнего мира, ведь это кладезь информации о вашем продукте, который может способствовать его компрометации.
Не забывайте о безопасности при выполнении любых действий.
Версии
Как бы тривиально это ни звучало — используйте системы контроля версий! Я знаю многих разработчиков, для которых это «ненужные проблемы», хотя поддерживаемые ими системы уже давно превзошли CRUD. Системы контроля версий, как минимум, позволяют бэкапить ваш код, а как максимум, грамотно контролировать выкатку кода, сравнение, версионирование и многое-многое другое.Как заработать на этом дофамине — каждая фича в своей ветке позволяет визуализировать процесс заливки кода в основной поток, теги — позволяют запускать производство по версиям и наблюдать за прогрессом от версии к версии.
Это на самом деле очень сильно продвигает нас вперед.
Сборка и распространение
Так уж повелось, что люди привыкли считать сборку компиляцией программы, опуская в этом понятии системы, которыми управляет интерпретатор.В наш век миллиона PHP-пакетов и миллиарда JS-библиотек понятие сборки уже не является чем-то чисто компиляторным, количество действий в системе, необходимых для ее запуска, давно перевалило за 1 десяток, поэтому важно ускориться.
максимально упростить процесс развертывания конкретного приложения за счет автоматизации рутинных действий.
Существует множество приложений, которые создают ваш продукт; для PHP я выбрал Phing, который легко устанавливается через композитор и описывает задачи сборки в достаточно удобном формате (хоть и xml, но на примере интуитивно понятно даже новичку).
Цель этих манипуляций — свести разработку продукта к нажатию кнопки «сделать все хорошо».
Извлечение пакетов, доставка актуальных конфигов, запуск миграций, запуск тестов, прогрев кеша — это малая часть того, что может сделать сборщик.
Даже если ваш код еще нигде не был развернут, в будущем наличие автосборщика существенно упростит начало разработки проекта на новой машине и значительно упростит развертывание и релизы ПО.
В сочетании с системами непрерывной интеграции (CI) вся рутинная работа ложится на плечи машин, предоставляя вам простор для полета фантазии и непосредственного решения проблем.
Ну, по крайней мере, у нас меньше шансов забыть что-то сделать во время развертывания.
Как выжать из этого каплю дофамина — найдите баланс в автоматизации сборки вашего продукта, начните с простых вещей и попробуйте посмотреть, как оно работает хотя бы в песочнице, даже при минимальном количестве потраченных часов, ощущение, что машина работает на тебя, неописуемо.
Например, я использую Jenkins в качестве системы CI с установленным плагином Phing. Достаточно выбрать в ассемблере шаг сборки «Invoke Phing Target» — и все зашуршает, проверяйте и собирайте.
Общая визуализация процессов
Ощущение контроля над системой очень заряжает энергией, поэтому постарайтесь визуализировать максимальное количество продуктов, которые вы используете.Начиная от статистики загрузки серверов, заканчивая визуализацией различного ПО, с которым работает ваш продукт. Например, для RabbitMQ есть Management Plugin, в виде веб-интерфейса для просмотра статистики и содержимого очередей, что очень помогает при отладке, а в продакшене — для контроля оптимальной работы процессов.
В целом существует множество программ для визуализации логов, которые вы можете выбрать под свои нужды, основная цель — обеспечить себе максимально высокую визуализацию происходящего в ваших продуктах (особенно актуально для сервис-ориентированной архитектуры (SOA) , где множество компонентов взаимодействуют друг с другом).
Информация о вашей системе даст не только возможность быстро отладить происходящее, но и моральное удовлетворение от наблюдения за изменениями и динамикой.
Все узкие места видны сразу, все неоптимальные участки системы под вашим контролем.
Совместимость
Если продукт выходит за пределы одной системы, очень мудрым решением будет поддерживать версии каждой подсистемы (модуля) и сопоставлять их совместимые версии, обновляя их с каждым выпуском.Такой подход позволит вам выкинуть из головы информацию об их особенностях, что было добавлено в какой версии и не сломает ли это всю работу.
Таким образом вы сможете избавить себя и других разработчиков от рутины копания в истории коммитов, чтобы определить, всё ли там в порядке.
Заключение
В мире, где так много технологий, где на тебя со всех сторон давит постоянно растущее количество информации, очень важно иметь пространство для гибкости, как в своем продукте, так и в своих мыслях.Основной посыл – ищите то, что позволяет визуализировать прогресс, избавьтесь от обезьяньей работы, и тогда даже самые скучные задания будут приносить огромное удовольствие.
Заключение
Этот пост предназначен в первую очередь для разработчиков и новичков, которые хотят улучшить (или сравнить) свой рабочий процесс.Весь представленный материал взят исключительно из моего собственного опыта; если у вас есть замечания, буду рад услышать их в комментариях.
Теги: #веб-разработка #программирование #автоматизация #психология #разработка веб-сайтов #php
-
Хрупкость Компьютеров
19 Oct, 24 -
Ларавел 7
19 Oct, 24 -
Формат Ms Outlook Станет Открытым
19 Oct, 24 -
Объяснение Необъяснимого. Часть 3
19 Oct, 24 -
Прогнозы — Дело Неблагодарное
19 Oct, 24
