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


10

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

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

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

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

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

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

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

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

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


1
Заряжайте всех по 1 доллару за каждый раз, когда они ломают сборку ... Вы будете удивлены, насколько она обуздывает неосторожные ошибки.
Берин Лорич

+1, потому что ваш комментарий вдохновил 3 отличных - и разных - ответов.
Карл Манастер

Ответы:


13

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

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

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

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


Не можете использовать совет Мартина Фаулера (в противном случае хороший), когда вы делаете рефакторинг кода, написанного другими. Кроме того, я полагаю, что разработчик, который отказался от методов, должен напоминать своим коллегам время от времени использовать новые методы, не слишком раздражая для ускорения перехода. У меня сложилось впечатление, что устаревшие методы в библиотеке классов Java всегда будут существовать для обратной совместимости, но я могу ошибаться.
Близпаста

@blizpasta, зависит от того, сколько клиентов у рассматриваемого API. Если у вас есть полдюжины, все в одном отделе, может потребоваться некоторое обсуждение и споры, а также несколько месяцев, чтобы завершить переход в обычных условиях. Если у вас есть миллионы пользователей и миллиарды LOC клиентского кода по всему миру, то да, вы, скорее всего, никогда не удалите эти устаревшие методы.
Петер Тёрёк

5

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


2
Когда я сделал это, мне часто удавалось изменить старый код, чтобы вызвать новый код. Это позволяет ему стать методом-заглушкой и предоставляет (надеюсь) улучшенный код для клиентов старого метода.
BillThor

4

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.