February 13, 2020

Маленькие изменения

По моеу опыту лучший способ ускорить написание софта - это делить процесс на маленькие этапы. Я не про итерации 1 или 2 недели. Я про выкатывать коммит раз в полчаса. Вот прям нормальный, с тестами, доками, чтоб ничё не отваливалось.

Почти все подвижки с конца 90х они про то как дать возможность сделать законченное изменение за минимальное время. Все эти CD, TDD, BDD, microservices, serverless видятся мне как инструменты для уменьшения гранулярности изменений. Фидбэк от пользователей, корректировка сроков и ожиданий, "чистая" архитектура - это кул-сторисы для среднего менеджмента. Коммит раз в несколько десятков минут - вот реальный бенефит.

Маленькие изменения позволяют понять что ты куда-то двинулся а не топчешься на месте или гребёшь назад, превращая работающий код в фарш. С пачкой законченных коммитов можно делать много полезный вещей: пофильтровать, перемешать, перенести из одного релиза в другой. Быстро.

Отдельная история - это слияние и перенос веток. Между merge двух веток по 1000 изменений и rebase 10 коммитов по 100 на ветку с 1000 есть большая разница. Особенно если знаешь что в каждом коммите релевантные тесты добавлены и старые не сломаны. По моему опыту разница легко может быть в 3-4 раза.

Да, оно конечно не всегда возможно. Если есть API с двумя сотнями вызовов то хочешь не хочешь пару часов провозмшься. Но подавляющее большинство продуктовых изменения можно нарезать на дифы в сотню строк получаемые за полчаса работы.

Tags: process programming thoughts