Следующий по важности критерий хорошего кода после читаемости — его готовность к изменениям. Собственно, читаемость тоже обеспечивает лёгкость изменений.

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

Ещё одна характерная черта современности — эксперименты. Бизнес пробует разные фичи и оставляет только удачные, безжалостно выпиливая не «взлетевшие».

Обычно стремительность изменений в коде является главным источником легаси. С другой стороны, стремительность неизбежна. Вопрос только в том, как сделать так, чтобы интенсивные изменения в коде как можно медленнее наращивали технический долг.

В моей личной классификации я делю технический долг на два типа:

• архитектурный — когда принятые в моменте архитектурные решения со временем оказываются неудачными
• кодовый — когда код проекта написан таким образом, что любые изменения в нём требуют больше времени, чем написание такого же кода с нуля

Избавиться от второго типа (я не преувеличиваю: не уменьшить, а именно полностью избавиться) возможно за счёт адаптированности кода к изменениям.

Увеличить степень изменяемости кода помогут несколько простых принципов:

• принцип единственного знания
• принцип единственной реализации
• принцип независимости от источника

и подходов:

• общие правила именования
• правила именования переменных
• правила именования функций