Наткнулся на статью, в которой автор даёт советы по подходу к задачам разработчиков. Среди советов выделяется один – писать список коммитов перед непосредственным написанием кода. То есть планировать и продумывать структуру, архитектуру, граничные кейсы до реализации.

Меня это зацепило, и я продолжил читать. В статье также говорилось про чеклист, по которому автор проходит, выполняя задачу. Мне идея понравилась, и я написал свой.

Вот так выглядит шаблон для рабочей заметки в Obsidian:

Url: 
Branch: 

## Todo
- [ ] Поставить задачу In Progress
- [ ] Создать ветку
- [ ] Понять/выяснить требования, выписать цель таска и расписать план по разработке
- [ ] ... (место для плана)
- [ ] Не забыл про мобилку (GET/SAVE)?
- [ ] Написать тесты
- [ ] Обновить спеку
- [ ] Протестировать решение 
- [ ] Пройтись по TODO
- [ ] make cs-fix
- [ ] make phpstan
- [ ] Создать МР
- [ ] Прочекать МР глазами
- [ ] Оставить комментарий к таску: МР, что сделал, For QA, Deployment Notes
- [ ] Отправить МР на ревью
- [ ] (?) Залить мобильщикам на сервер
- [ ] (?) Отписать менеджерам/фронту/мобильщикам, если срочно
- [ ] (?) Написать доку

## Notes

Структура

• заголовок - название задачи из трекера, может быть видоизменено для понятности или чтобы убрать символы, которых не должно быть в имени файла (в Obsidian любая заметка - это файл на жёстком диске);
• тег, worktasks для активных и archiveworktasks для архивных;
• ссылка на задачу в трекере;
• чеклист;
• заметки по задаче, сюда записываю любую инфу, которая можем понадобиться - хитрые запросы, рекомендации для QA, что сообщить фронтендеру или мобильному разработчику и т.п.

Сначала я просто добавлял чеклист как подзадачи в Todoist, но не хватало места для заметок, поэтому я перешёл в Obsidian. В самом Todoist я ставлю ссылку на заметку в описание задачи.

Важное в чеклисте

• задачу ставлю в In Progress сразу как приступаю, а не когда буду готов написать первую строчку кода;
• выяснение требований и цели идёт отдельным пунктом;
• планирование задачи как до реализации, так и в процессе — всего учесть нельзя, а ещё есть всеми любимые изменения требований на ходу;
• под конец чеклиста всё расписано максимально подробно, чтобы нигде не профакапиться из-за “эйфории” от завершения таска.

Завожу такие заметки на все задачи из трекера, кроме хотфиксов. Даже если в коммите одна строчка кода, я лучше пройдусь по чеклисту - так спокойнее. Чеклист избавляет от факапов, а ещё заставляет задуматься прежде, чем писать код.

До чеклиста

• я практически никогда не читал свой код в МР перед отправкой на ревью, хотя считаю эту практику очень полезной;
• иногда забывал запускать анализаторы (да, можно сделать гитхук, но мне удобнее так);
• забывал обновить спеки.

Ссылки:

• Оригинальная статья и её продолжение с примером из реальной жизни