Качество унаследованного кода измеряется объемом усилий, необходимых для его удаления.
Что делает код прилипчивым, так это совокупная оценка того, насколько сложна функция, насколько жизненно важен код, о котором идет речь, и насколько сложно определить функциональность кода. Итак, давайте разберем, как можно достичь каждого из них:
- Сложность кода и его важность
Этот прямолинейный. Чем больше людей зависит от вашего кода, чтобы сделать его лучше, чтобы показать признаки жизни, тем меньше вероятность того, что ваш босс потратит какие-либо ресурсы на его переписывание.
То же самое касается важности кода. Гораздо проще остановить и переписать побочную фичу, чем то, что жизненно важно для заметного количества клиентов.
Чтобы писать код в таких местах, нужно быть нужным человеком в нужное время или очень хитрым.
В первом случае вас просто попросят написать важную функцию, так что это легко.
Однако, если вы хотите быть скрытным, вы можете внести инфра-настройки «в соответствии с требованиями к функциям». Допустим, у вас есть служебный файл. Вы можете использовать его для ссылки на вашу функцию. Теперь я говорю «ссылка», но на самом деле я имею в виду просто переместить общие функции в вашу функцию и заставить файл utils использовать их. Вы также можете сделать это с фичами, сопровождающие которых либо ушли из компании, либо им просто наплевать (и ваши собственные фичи, конечно).
Не так очевидно, конечно, но это общая идея. Чем более созависимы ваши черты, тем лучше.
Делая это, вы гарантируете, что удаление одной из ваших функций приведет к сбою всех связанных функций. Это то, что мы называем каскадным сбоем.
Это просто гарантирует, что функция не будет удалена. На более продвинутых уровнях вы можете сделать свой код настолько запутанным, что люди будут писать обходные пути, просто чтобы не трогать его.
2. Если вы можете это объяснить — вы можете написать код, который это делает. Это означает, что если будет принято решение переписать ваш код, это будет относительно сложной задачей.
Чтобы избежать этого, вы хотите, чтобы функциональность вашего кода была как можно более неясной. Высшим достижением было бы написать что-то настолько запутанное, что у ваших коллег не было бы выбора, чтобы принять это как что-то, что, по-видимому, ничего не делает, но если вы не подключитесь к нему должным образом, ваша функция не будет работать.
Хорошая техника при написании такого кода — помнить, что вы пытаетесь заставить читателя потерять контекст.
Например, мы будем использовать JavaScript, и задача будет состоять в том, чтобы написать код, который сортирует массив, а затем печатает числа:
Это был бы простой способ написать эту функцию. Убедитесь, что все реализовано вами. Бонусные баллы за использование нетрадиционных моделей:
В этот момент большинство из вас, вероятно, сказали себе: «К черту, мне не платят (достаточно), чтобы читать эту чушь». Что и правда, и именно то, что вы хотите от неприкосновенного кода.
Для более стойких вы хотите скрыть имена своих переменных. Но вы не можете просто «минимизировать» весь свой код. Вам нужно использовать имена переменных, которые выглядят так, как будто они куда-то ведут. Таким образом, вы просто запутаете людей при проверке кода до такой степени, что они одобрят его вслепую:
Хорошее эмпирическое правило — попытаться прочитать код после небольшого перерыва. Если вам потребуется время, чтобы расшифровать его, он готов к отправке.
Эпилог
Большинство людей недооценивают искусство введения в заблуждение. Но это то, что отличает средний унаследованный код от отличного. Есть очевидный вопрос, который вы можете задать себе: «Если я прочитаю эту строку через год, без предыдущего контекста, смогу ли я ее понять?». Но настоящие эксперты должны спросить себя: «Если я захочу добавить к этому второстепенную функциональность через год, какова вероятность того, что это вызовет проблемы в продакшене».
Теперь, если вы удовлетворены своими результатами, напишите модульные тесты, которые сломаются, если какая-либо строка в этом коде будет изменена. Ваше здоровье!
