Рефакторить или переписать с нуля?
#мысли
На глаза попалась статья Джоэля Спольски (основателя stackoverflow) о той ошибке, которую совершают часто многие программисты, приходящие в команду на новый проект — переписывание кода с нуля. Описывается пример браузера, о котором уже никто не знает — Netscape.
Уверен, что каждый из разработчиков слышал о том, что код, написанный предыдущей командой, ужасен, его нужно выкинуть и написать красиво: с продуманной архитектурой, с последними технологиями и подходами, с новыми библиотеками. Программисты в душе архитекторы, и их первое желание — пройтись бульдозером и построить что-то крутое. Однако, причина того, что разработчики хотят выбросить старый код и написать новый кроется в том, что читать код сложнее, чем его писать.
Например, получив огромную базу легаси кода, в которой функции по несколько страниц в длину, разработчик думает, что половина из этого кода лишняя, а вторая — вообще непонятно для чего и как работает. Но в чем причина такого огромного куска кода? Причина в том, что тут содержатся фиксы багов.
Старый код работает, он протестирован и исправлен. Многие баги сложно воспроизвести, другие же воспроизводятся только на определенных устройствах. Удалив весь код, разработчик удаляет и все труды, связанные с этим кодом.
Что же делать со старым кодом, который поддерживать не доставляет удовольствие? Думаю, что тут можно применить только одну стратегию: постепенный рефакторинг. Постепенное переписывание фич и экранов, а не удаление старой базы кода. Каким бы красивым ни был ваш код, совсем не факт, что он будет работать лучше. Думаю, что в будущих статьях напишу о том, как рефакторили код в тех командах, где я работал. А для нового кода не забывайте писать комментарии, когда происходит что-то странное.
#мысли
На глаза попалась статья Джоэля Спольски (основателя stackoverflow) о той ошибке, которую совершают часто многие программисты, приходящие в команду на новый проект — переписывание кода с нуля. Описывается пример браузера, о котором уже никто не знает — Netscape.
Уверен, что каждый из разработчиков слышал о том, что код, написанный предыдущей командой, ужасен, его нужно выкинуть и написать красиво: с продуманной архитектурой, с последними технологиями и подходами, с новыми библиотеками. Программисты в душе архитекторы, и их первое желание — пройтись бульдозером и построить что-то крутое. Однако, причина того, что разработчики хотят выбросить старый код и написать новый кроется в том, что читать код сложнее, чем его писать.
Например, получив огромную базу легаси кода, в которой функции по несколько страниц в длину, разработчик думает, что половина из этого кода лишняя, а вторая — вообще непонятно для чего и как работает. Но в чем причина такого огромного куска кода? Причина в том, что тут содержатся фиксы багов.
Старый код работает, он протестирован и исправлен. Многие баги сложно воспроизвести, другие же воспроизводятся только на определенных устройствах. Удалив весь код, разработчик удаляет и все труды, связанные с этим кодом.
Что же делать со старым кодом, который поддерживать не доставляет удовольствие? Думаю, что тут можно применить только одну стратегию: постепенный рефакторинг. Постепенное переписывание фич и экранов, а не удаление старой базы кода. Каким бы красивым ни был ваш код, совсем не факт, что он будет работать лучше. Думаю, что в будущих статьях напишу о том, как рефакторили код в тех командах, где я работал. А для нового кода не забывайте писать комментарии, когда происходит что-то странное.