tgoop.com/itextrapolation/511
Last Update:
По аналогии с термином «пуленепробиваемый дизайн», сформулируем «пуленепробиваемый код».
Ну вот, написали вы некую функциональность. Она была написана за один присест, поэтому выглядит очень лаконично и солидно, что прям хвастаться можно. Но буквально спустя дюжину изменений этот код не узнать — он ужасен и воняет. Каждое изменение привнесло в этот код какой-то дополнительный костыль, что-то такое инородное или какую-то дополнительную функциональность, которая лежит как бы сбоку, не задевая того, что было написано до этого. В результате на код страшно смотреть.
А бывает заморочились вначале и придумали такую архитектуру, в которой все последующие изменения идут как по маслу. Даже те, о которых и думать не думали. Да, заморочиться вначале нужно больше, но эффект не заставит себя ждать.
Это и есть пуленепробиваемый код.
Критериев и признаков такого кода много. Опустим такие банальные штуки, вроде «понятен при прочтении», «делает только одно действие» и тому подобное. Есть и вполне практичные штуки, описанные не в одной книге, на подобии «глобальные переменные это плохо» или «чистые функции это хорошо», о них тоже упомянем вскользь.
Самое главное что нужно помнить — код должен быть устойчивым к изменениям. Ну, в том смысле, что если код начнут менять или рефакторить, то это не будет увеличивать энтропию в кодовой базе. Иначе говоря, не добавит говна в проект.
#перечитываяэкстраполяцию
BY Экстраполяция IT
Share with your friend now:
tgoop.com/itextrapolation/511