Skip to content

Изменения и сопровождение

Назад к Глоссарию.

Изменяемость

Изменяемость — это легкость, с которой систему можно изменять без несоразмерного роста стоимости, риска или путаницы.

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

На практике изменяемость часто оказывается более полезной мерой инженерного качества, чем абстрактная элегантность сама по себе.

Рефакторинг

Рефакторинг — это дисциплинированное улучшение внутренней структуры кода без изменения его предполагаемого внешнего поведения.

Его цель обычно состоит в том, чтобы улучшить читаемость, изменяемость, границы или локальное качество проектирования. Рефакторинг особенно ценен тогда, когда он снижает будущую стоимость изменений, проясняет намерение кода или убирает трение из реально предстоящей работы.

Технический долг

Термин «технический долг» полезно использовать как метафору компромисса, а не как общий ярлык для всего несовершенного.

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

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

Связанное чтение: Технический долг должен что-то покупать.

Legacy

Legacy не является синонимом возраста системы, устаревшего стека или технического долга.

Legacy — это прежде всего код, который фактически остался без полноценного сопровождения на уровне знания о нем. Он может быть сформирован накопленной историей, ограничениями, обязательствами по совместимости и решениями, которые продолжают влиять на настоящее, но сам по себе возраст еще не делает систему legacy. Ключевой признак здесь — утрата надежного знания о том, как этот код устроен и как с ним безопасно работать.

На практике это часто выражается в отсутствии тестов, слабой или устаревшей документации, а иногда и в отсутствии людей-носителей знания, которые еще понимают реальное устройство системы. В таком состоянии даже обычные изменения начинают превращаться в (не)угадывание.

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

Legacy превращается в технический долг только тогда, когда решение продолжать жить с проблемной legacy-структурой принимается осознанно, цена его понятна, а изменения все равно откладываются при наличии реального давления на систему.

Связанное чтение: Legacy — это не автоматически технический долг.

Спорные технические решения

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

Этот термин полезен для решений, которые выглядят сомнительными, спорными, слабо обоснованными или явно рискованными, но при этом не являются автоматически ни legacy, ни техническим долгом. Решение может быть спорным просто потому, что его компромиссы оспариваются, контекст недостаточно ясен или его цена уже стала заметной раньше, чем команда определилась, как именно его классифицировать.

Выделять такие решения полезно, потому что это создает пространство для разговора о качестве, рисках и альтернативах, не сваливая все подряд либо в технический долг, либо в legacy.

Но не менее важно правильно называть вещи своими именами. Не всякое плохое или спорное решение является legacy. Не всякий дискомфортный дизайн является техническим долгом. Точный язык помогает различать историческую нагрузку, осознанные компромиссы и просто спорное инженерное суждение.

Last updated: