Впервые про поделия в разработке ПО я услышал от Вадима Глебова, за что ему большое спасибо.
Что является критерием завершенности задачи, над которой работал программист? Почему просто написать код и положить его в репозиторий недостаточно.
Самый распространенный на мой взгляд акт завершения задачи разработчиком это:
- Запушил код в репозиторий с пояснительным текстом коммита и номером задачи
- Написать в комментариях к задаче “Готово”
Казалось бы не придраться. Код есть, таску закрыл. Вроде как бы где-то работает. Однако, есть самый простой и адекватный метод проверки готовности задачи. Это вопрос от тимлида: “Докажи”.
Грубо говоря, закрыл программист задачу, что-то сделал, а вы ему — докажи. Пускай реально докажет, что все что он сделал работает и работает правильно. Пинки задачами между отделом разработки и отделом контроля качества не считаются. Речь идет о критерии завершенности задачи для самого разраба, для его команды, для тимлида.
Всегда задавайте себе вопрос: “А как я могу доказать то, что я решил задачу?”. Чем результат моей работы отличается от поделия на выброс? Поделие — классное определение говнорезультата. Помните, на уроках труда в школе делали кривые и косые табуретки и мастак благим матом орал “Что это блять за поделие?!”. Садился на нее и хрупкая табуретка под его жопой, трескаясь, ломалась и он под хохот класса падал на пол.
Поэтому, чтобы не выпускать из под себя поделия нужно всегда иметь неопровержимые доказательства того, что код ваш решает задачу и работает. Самые простые и базовые вещи: это тесты, которые работают в изоляции и вместе со всеми тестами на CI. Пройденными тестами ты доказываешь самому себе, команде и проекту, что твой код рабочий и что твой код не ломает другой код.
Чтобы снизить риск создания поделий в проекте можно создать строгий пайплайн в CI, который будет отбривать код без тестов, с ошибками линтера, с ошибками анализатора сложности и другие. Но тестов и линтера для современного тулинга вполне достаточно.
Ранее статья была опубликована тут.