Pull to refresh

Comments 5

В общем, примерно правильно все написано.
Добавлю, что однажды довелось принимать участие в процессе со стороны, так сказать, "дьявола" — пытались переписать систему, автором которой был я сам. Рефакторщики совершили абсолютно все ошибки, которые здесь описаны. При этом, следуя совету к ошибке №1, они действительно начали с небольшого отдельного куска, не существовавшего в старой системе, написали его с помощью достаточно новой на тот момент технологии (сейчас она тоже уже давно устаревшая). По совету к ошибке №6 они постоянно взаимодействовали со мною, чтобы выяснить, как функционирует старая система. Я старался абсолютно откровенно отвечать на все вопросы, а также очень внимательно прислушиваться к их критике. "У тебя плохо устроено вот это" или "в старой системе нет такой фичи" — ну, OK, это я попробую исправить, а фичу добавить. В результате старая система постепенно улучшалась, а творцы новой за нею не поспевали — ведь им нужно было еще и старые полезные функции обеспечить. Для того куска, который они создали, я написал переходник, позволивший старой системе пользоваться данными из новой. Кроме того, рефакторщики не захотели (а может, были просто не в состоянии) произвести полную ревизию старого техпроцесса, много раз побеседовав со всеми его участниками.
Итог был таким — через два года новой разработки её закрыли. При этом я совсем не считаю их неумными, среди них были программисты посильнее меня, просто они были немного слишком молодыми.
А упомянутая система работает и сейчас, уже 30+ лет, хотя бизнесу, конечно же, очень мешает то, о чем здесь нельзя упоминать. С момента попытки переписывания прошло также уже очень много лет. Кусок, написанный тогда рефакторщиками, тоже успешно функционирует, ибо его писали, тщательно анализируя требования и не пытаясь сразу решить все проблемы.
Следует еще упомянуть, что описываемая система не является тиражной. Этот фактор тоже сыграл роль в неудаче переписывания, поскольку рефакторщики решили сделать систему такой, чтобы её можно было продавать (ну, или перед ними поставили такую задачу владельцы бизнеса)

Не пытайтесь создать «эталонную» архитектуру, вместо этого сфокусируйтесь на ее гибкости. Мир изменчив, бизнесу приходится реагировать на вызовы и лучшая архитектура — та, что сможет быстро адаптироваться к изменениям и не потребует нового большого рефакторинга.

- т.е. создать «эталонную» архитектуру.

Ну какая-то архитектура должна быть, и формально она будет “эталонной”. Я пытался подчеркнуть, что усложнение и попытка решить все известные проблемы - не лучшая идея. Такая архитектура часто устаревает сразу после запуска новой версии.

Пытаться все переписать потому, что написано "неправильно". Все эти принципы MVC, микросервисы, REST, SOLID, и пр. конечно хороши и их надо придерживаться. Но если это единственная причина переписывания, стоит задуматься о целесообразности.

Всё так и пункт #2 в целом про это.

Причиной должно быть не отсутствие "модных" технологии или решений, а какие-то серьезные проблемы с дальнейшей разработкой продукта: невозможность реализации какого-то важного функционала, или невозможность вообще поддерживать продукт.

Sign up to leave a comment.

Articles