Вы встречались с проблемой, когда вы пишите много кода, нажимаете коммит и не знаете как сформулировать комментарий? Такое случается, когда во время кодинга было сделано несколько подзадач, еще рефакторинг, еще code cleanup небольшой и т.п. Приходится писать либо очень большой комментарий, либо опустить руки и написать «fixes» или «big changes» или подобный комментарий, который ничего не значит. При работе в команде такие комментарии наносят большой вред, т.к. становится сложно понять, что происходит с кодом:
Когда мы уже знаем, что такое хороший коммит, можно еще эффективнее использовать DVCS. Для этого предлагаю модифицировать рабочий процесс.
Пример я буду показывать на TortoiseHg, но тоже самое было опробовано и на TortoiseGit. Я думаю, что конкретная реализация интерфейса DVCS не должна вызывать сложность.
- Для начала открываем Workbench и пишем комментарий на задачу, которую мы сделаем за ближайшие 10-30 минут. Здесь надо привыкнуть писать комментарий в прошедшем времени, как будто задачу уже реализовали:
- Переходим в IDE и начинаем печатать код
- Когда задача реализована, возвращаемся в Workbench, комментарий к коммиту у нас уже есть, обновляем список измененных файлов и жмем коммит:
Получается, что мы сначала пишем комментарий к будущим изменениям, потом эти изменения делаем.
Плюсы
- Делаем только одну задачу. Захотели порефакторить или отвлечься? Уже нельзя, коммитом четко обозначена небольшая задача;
- Моделируем будущее у себя в сознании и думаем как бы быстрее до него дойти;
- Когда вы привыкните работать в таком стиле, то без готового комментария уже будете испытывать дискомфорт, появится стремление написать себе мини-задачу;
- Очень частые коммиты (не буду объяснять почему это хорошо);
- Если вы отвлеклись, то легко вернуться в поток, прочитав мини-задачу, которую в данный момент решаем;
- Равномерная нагрузка в течение дня. Мы ставим маленькие задачи и получаем постоянные легкие «победы» после их завершения.
Минусов нет, это отлично работает для обычных повседневных задач, когда можно декомпозировать большую User Story. Есть единственное ограничение: если вы будете работать с VCS (VSS, SVN и т.п.), то вам нужно будет использовать feature branching, иначе не получится делать такие маленькие коммиты.
Это работа с DVCS в духе TDD, когда мы сначала ставим перед собой маленькую легкодостижимую задачу и в рамках нее двигаемся. Получается задача и быстрый результат, движение маленькими шажками.
Опробовано на нескольких проектах в нашей компании, приводит к крайне положительным результатам.
