Лучшие практики для переименования, рефакторинга и прерывания изменений в командах

Каковы некоторые рекомендации для рефакторинга и переименования в командной среде? Я привожу это с учетом нескольких сценариев:

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

2. Если проекты переименованы и решения должны быть перестроены с обновленными ссылками на них.

3. Если структура проекта изменена на «более организованную», добавьте папки и переместите существующие проекты или решения в новые места.

Некоторые дополнительные мысли / вопросы:

1. Должны ли изменения, подобные этому, или в результате боли указание на неправильную структуру?

2. Кто должен нести ответственность за исправление ошибок, связанных с критическими изменениями? Если разработчик вносит решающее изменение, должен ли он отвечать за вход в затронутые проекты и обновлять их, или они должны предупредить других разработчиков и предложить им что-то изменить?

3. Это можно делать по расписанию или делать это как можно чаще? Если рефакторинг откладывается на слишком долгое время, становится все труднее согласовать его, но в то же время в течение дня тратит 1 час на исправление сборки из-за изменений, происходящих в другом месте.

4. Это вопрос формального процесса общения или он может быть органическим?

Каждый из перечисленных вами сценариев подпадает под категорию «опубликованный API / код». Реорганизовать это сложно, поэтому не стоит ничего слегка менять. Скорее, он должен заранее договориться о запланированных изменениях со всеми вовлеченными сторонами. Это, по крайней мере, такой же политический вопрос, как и технический.

Так что совет номер один от Мартина Фаулера заключается в том, чтобы не публиковать ваши интерфейсы (названия проектов и структуры) преждевременно .

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

Также, если возможно, рассмотрите возможность добавления нового метода (при этом устарел существующий) вместо переименования существующего. Это гарантирует, что клиентский код не нарушается, и предоставляет им период перехода для обновления своего кода в соответствии с последним API. Недостаток в том, что это усложняет ваш API. Хотя это состояние только временное, может пройти много времени, прежде чем вы сможете безопасно удалить устаревшие методы API (в случае библиотеки классов Java - годы).

Вы можете почти всегда избежать этих проблем путем рефакторинга в два этапа. На первом этапе введите новый код и не используйте старый код. Когда все команды перейдут на новый код, удалите старый код. Я также использую эту технику для постепенного рефакторинга одного модуля. Таким образом, я могу ограничить количество кода, которое должно быть изменено между запусками теста.

Обратите внимание, что это одна из основных причин наличия сервера сборки, на котором выполняются тесты.

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