Всегда оставляйте лагерь чище, чем вы его застали
Это мини-серия статей по написанию поддерживаемого объектно-ориентированного кода без лишней нервотрепки.
Предыдущие части: Часть 1, Часть 2, Часть 3 и Часть 4.
Энтропия
Энтропия — это отсутствие порядка или предсказуемости; постепенное стремление к бесконечности.
Энтропия в физике характеризует меру «беспорядка» в системе. Закон термодинамики доказывает, что энтропия мира стремится к максимуму.
Законы физики не применяются к разработке программ, чего не скажешь о понятии «энтропии». Если в приложении разрастается беспорядок, то программисты называют подобное явление «деградацией софта».
Теория разбитых окон
Деградация софта начинается с одного разбитого окна.
Если долго не чинить окно, то возникнет ощущение заброшенности. И разобьют еще одно окно. Люди начнут мусорить. Появится граффити. Все это приведет к полному разрушению конструкции. За сравнительно короткое время и без желания владельца здания вложиться в ремонт, оно начнет разрушаться, и ощущение заброшенности станет реальностью.
Правило бойскаутов
Бывали случаи, когда я собирал код по частицам, потому как весь компонент работал неисправно. От этого код становился еще хуже, чем раньше, и изменить его в дальнейшем было намного труднее. Если же вы работаете в команде или над проектом с чисто написанным, отлично спроектированным и элегантным кодом, то сделаете все возможное, чтобы его не испортить.
Не оставляйте «разбитые окна» без ремонта. Чините каждое «окно» сразу после обнаружения. Всегда оставляйте код чище, чем вы его застали.
Разбираемся с энтропией
Как говорит Дядя Боб, нужно не просто уметь хорошо писать код. Он должен оставаться чистым по прошествии времени. Если мы подчистим код на входе лучше, чем на выходе, то он не успеет деградировать. Такая «чистка» не обязательно должна быть масштабной. Присвойте одной переменной более подходящее имя, разбейте какую-то длинную функцию на несколько составляющих, удалите небольшой дубль в коде, подчистите один составной оператор if.
Сделали еще лучше
Программисты — люди умные и умеют делать свою работу. Однако всем нам необходимо научиться одновременно выполнять свою работу и делать код еще лучше.
«Вам нужен тот, кому вы дадите проект на исследование, а в понедельник он придет и скажет: «Я все сделал. И, кстати, в процессе работы немного доработал существующую инфраструктуру»». — Stevey’s Blog Rants
Коротко о главном
Вы видите зло. Вы разрушаете зло. Всегда занимайтесь рефакторингом. Я пришел к выводу, что отлично помогает следующая приоритетность:
ошибки> рефакторинг> фичи
Такая схема применима к любой парадигме программирования, не только к ООП. Энди Хант и Дейв Томас написали об этом подробнее в книге «Программист-прагматик».
Перевод статьи Arun Sasidharan: Object Oriented Tricks: #5 Boy Scout Rule
