Comments 5
В целом правильно все написано, но кое-что решет глаз:
это сохранённое поведение именно вместе с известными багами и недокументированным поведением
Если вы не собираетесь чинить баги, зачем вам тогда рефакторинг? В конце же сами себе противоречите – что почните, но потом.
Через неделю в PR лежит 1500 строк и никто, включая тебя, не знает, что там рефакторинг, а что уже изменение поведения.
Все будет понятно, если не валить все в один коммит. Переименования/перемещения файлов в одном коммите, изменения логики в другом. Часто есть смысл тесты добавлять отдельным коммитом и прямо в описании фиксировать, что именно падало. Помогает при ребейзах во время работы убедится, что падает до сих пор там, где падало изначально. Ну и желательно, чтобы в PR было не более 10 коммитов, далее уже психологически сложно его рассматривать, как маленький. Исключение только если у вас очень много тривиальных коммитов.
Он размазан по логам, коммитам и головах тех, кто помнит инцидент три года назад.
Если его нет в комментарии к конкретному if, то вы сам себе злобный Буратино.
он увидит понятную историю: «вынесли модуль, подключили шину», а не «вынесли модуль, переехали на новый фреймворк, попутно починили три бага и переименовали половину классов».
Не нужно пихать все в один коммит. Но можно в один PR, если все это связано.
В целом правильно все написано, но кое-что решет глаз:
это сохранённое поведение именно вместе с известными багами и недокументированным поведением
Если вы не собираетесь чинить баги, зачем вам тогда рефакторинг? В конце же сами себе противоречите – что почните, но потом.
Через неделю в PR лежит 1500 строк и никто, включая тебя, не знает, что там рефакторинг, а что уже изменение поведения.
Вопрос хороший "Если вы не собираетесь чинить баги, зачем вам тогда рефакторинг"
Именно в этом случае рефакторинг рассматривается на примере выноса части монолита в микросервис. И в таком случае я акцентирую внимание, что нельзя смешивать починку одиночных багов с переносом.
Есть примеры рефакторинга, которые могут починить какое то кол-во известных багов за счет например более чистой базовой логики, например вы алгоритм сделали более общим и он захватил (и починил) несколько частных случаев-багов. тут да.
Но мой главный посыл, что не надо отвлекаться на улучшения и забывать о главной задаче. и не надо смешивать.
И разделение по коммитам - да. обязательно.
Закон Хирама (Hiram’s Law) - принцип в разработке программного обеспечения, сформулированный Хирамом Райтом (Hiram Wright). Он гласит: «При достаточном количестве пользователей API не имеет значения, что вы обещаете в контракте: все наблюдаемые поведения вашей системы будут кем-то использованы».
Если вы сделаете “правильно”, то где-то что-то сломается
Что говорят в инете на вопрос, что такое рефакторинг и является ли вынос функции из монолита в микросервис:
Определение рефакторинга (в классическом понимании, по Мартину Фаулеру):
Рефакторинг — это процесс изменения внутренней структуры программного кода без изменения его внешнего наблюдаемого поведения. Цель — улучшить читаемость, уменьшить сложность, повысить поддерживаемость и облегчить добавление новых функций, не меняя того, что система делает.
Нет, вынос функции из монолита в отдельный микросервис — это НЕ рефакторинг в классическом смысле.
Это архитектурная реорганизация (или «перестройка архитектуры»), которая обычно называется декомпозицией, миграцией, выделением сервиса или изменением архитектурного стиля (с монолитной на микросервисную).
Скучный Рефакторинг: борьба с искушениями