Бывают такие статьи который читаешь и прямо перед глазами пробегают ситуации из прошлых проектов. Сегодня статья о 8 ошибках при переписывании проектов/систем. Автор собрал замечательный список. Чаще всего здесь идет речь о переписывании системы в которых вы не принимали участия при проектировании/написании. Выбрал несколько которые особо понравились и откликнулись, остальные читайте в оригинале.
- Планировать миграцию только когда новая система будет "почти готова" - при позднем планировании миграции могут реализоваться риски по несовпадению форматов, стандартов, объема данных. Что-то чего вы не сможете учесть или увидеть при планировании. Что тогда? Возможно откат на пару шагов назад. Что делать? Помнить что есть например паттерны Strangler Fig, Parallel Run они помогут спланировать миграцию с меньшими рисками.
- Недооценивать усилия. Чаще свойственно middle или начинающим senior разработчикам, они уже могут брать на себя много ответственности но еще не попадали в капканы легаси 🥲. Это когда одна хитрая строчка может стоить пары дней нервных клеток. Что делать? Оценивайте функциональность и объем системы, планируйте по этапам. По поводу планирования связаны две следующие ошибки
- Не спрашивать о функциональности системы, пытаться копировать ее 1:1 и Пытаться заменить всю систему целиком. Спланируйте что вы меняете и почему, возможно у системы есть стабильное ядро и его можно не трогать, или возможно нарекания вызывает только системы которую вполне можно изолировать?
- Оверинжиниринг. Наша любимая программисткая ошибка. Иногда старая система так задалбывает своей отсталостью, что хочется вложить в новую версию все самое свежее и новое. Будьте очень осторожны. История разработки программного обеспечения уже знает такие истории. Легендарный Фредерик Брукс сформулировал Second-System Effect. На смену небольшим и компактным системам приходят неповортливые и раздутые монстры.
Что еще почитать на эту тему?
Patterns of Legacy Displacement (Effective modernization of legacy software systems)
Оригинальная статья "The 8 biggest mistakes when rewriting software systems (that I have seen so far)"
- Планировать миграцию только когда новая система будет "почти готова" - при позднем планировании миграции могут реализоваться риски по несовпадению форматов, стандартов, объема данных. Что-то чего вы не сможете учесть или увидеть при планировании. Что тогда? Возможно откат на пару шагов назад. Что делать? Помнить что есть например паттерны Strangler Fig, Parallel Run они помогут спланировать миграцию с меньшими рисками.
- Недооценивать усилия. Чаще свойственно middle или начинающим senior разработчикам, они уже могут брать на себя много ответственности но еще не попадали в капканы легаси 🥲. Это когда одна хитрая строчка может стоить пары дней нервных клеток. Что делать? Оценивайте функциональность и объем системы, планируйте по этапам. По поводу планирования связаны две следующие ошибки
- Не спрашивать о функциональности системы, пытаться копировать ее 1:1 и Пытаться заменить всю систему целиком. Спланируйте что вы меняете и почему, возможно у системы есть стабильное ядро и его можно не трогать, или возможно нарекания вызывает только системы которую вполне можно изолировать?
- Оверинжиниринг. Наша любимая программисткая ошибка. Иногда старая система так задалбывает своей отсталостью, что хочется вложить в новую версию все самое свежее и новое. Будьте очень осторожны. История разработки программного обеспечения уже знает такие истории. Легендарный Фредерик Брукс сформулировал Second-System Effect. На смену небольшим и компактным системам приходят неповортливые и раздутые монстры.
Что еще почитать на эту тему?
Patterns of Legacy Displacement (Effective modernization of legacy software systems)
Оригинальная статья "The 8 biggest mistakes when rewriting software systems (that I have seen so far)"