Post #33

Всем привет! Сегодня хочу поделиться чек-листом, которым я пользуюсь каждый раз, когда разрабатываю новую фичу. 1️⃣ Бизнес-требования Самое важное перед началом работы над любой задачей — это сформулировать требования. А что конкретно мы хотим от решения этой задачи? Я, как и многие разработчики, люблю писать чистый и красивый код, но зачастую бизнесу не так важен сам код, как тот факт, что он закрывает конкретную потребность. Поэтому важно перед началом работы выровняться с автором задачи: а что именно мы хотим? 2️⃣ Ответить на вопрос: как мы поймём, что задача действительно выполнена? Часто при решении задачи погружаешься в архитектуру, красоту и прочее, и на выходе можешь получить красивый, рабочий код — но, увы, не решающий задачу. Поэтому полезно возвращаться к изначальной формулировке и сверяться: в том ли направлении я иду? 3️⃣ Надёжность Зачастую после решения мы получаем код, который будет работать долгое время и в суровых реалиях продакшена. Поэтому надёжность выходит на первое место. Важно не забывать оборачивать наше решение хотя бы базовым мониторингом, логами и тестами, которые позволят ответить на вопрос: а наша фича вообще ещё работает? 4️⃣ Воспроизводимость окружения для разработки Работая над проектами, наш фокус внимания постоянно меняется, и бывают ситуации, когда уже через неделю ты не помнишь, как запускать и проверять фичу. На такие случаи стоит сразу после разработки оставить какие-либо "рецепты" — будь то коллекции запросов или просто набор скриптов, позволяющих в пару команд быстро поднять окружение и протестировать фичу. 5️⃣ Продумать схему деплоя — и, что важно, схему отката! Думаю, не нужно объяснять, почему важно понимать, как будет раскатываться ваша фича. Но я заметил, что многие не продумывают схему отката. Увы, мы все люди, и нам свойственно ошибаться. Поэтому лучше заранее понять, что делать, если что-то пойдёт не так. Для себя я выделяю несколько вещей: 👉 миграции данных, позволяющие откатиться к предыдущей схеме; 👉 конфигурируемые флаги, отключающие новую функциональность (feature flags); 👉 ну и, на "advanced" уровне — канареечные деплои. 6️⃣ Документация Наверное, самое сложное в работе разработчиков — это поддержка документации. Буду честен, сам страдаю от написания инструкций, рецептов и прочего. Но в моменты инцидентов или доработки функциональности понимаешь всю её значимость. Необязательно писать многостраничную документацию о том, как это работает и почему было принято то или иное решение. Достаточно верхнеуровнево описать логику или использовать максимально человеко-понятные конструкции в коде. Например, в моей команде мы придерживаемся правила: неочевидные решения описываем в тикете задачи, и при необходимости — оставляем ссылку на тикет в комментарии к коду. А какие пункты добавили бы вы? Какие моменты кажутся вам спорными? Оставляйте комментарии — давайте обсудим!