The Broken Window Theory
A window gets broken at an apartment building, but no one fixes it. It's left broken. Then something else gets broken. Maybe it's an accident, maybe not, but it isn't fixed either. Graffiti starts to appear. More and more damage accumulates. Very quickly you get an exponential ramp. The whole building decays. Tenants move out. Crime moves in. And you've lost the game. It's all over.
Аналогично и с программированием. Вы написали код, хороший код, почти идеальный. От "почти" до идеала вас отделила какая то мелочь. То ли не вовремя закончился рабочий день, а с ним и вдохновение, то ли не кстати появилась критическая проблема, которую срочно нужно было решать. В конце концов мы не идеалисты, мы реалисты! И, черт побери, этот код работает, что еще нужно?!
Прошло время и оказалось что кому то в вашем идеальном коде не хватило той самой мелочи, например точки расширения. Будучи то ли слишком скромным, то ли слишком самостоятельным, этот кто то отвлекать вас не стал, а сам добавил в один из ваших базовых классов какой то метод для своих целей. Прошло еще время и этот метод стал использоваться во многих местах вашего и не только вашего кода. Заодно этот метод обзавелся "соседями" - другими методами на всякие другие случаи жизни. Ваш код заматерел, оброс методами-"мясом", однако оригинальная цель и идея уже не так явно просматривается в этом наборе методов "на-все-случаи-жизни". Зато у многих ваших коллег есть четкое понимание куда нужно добавлять новые методы-помощники, если вдруг такие понадобятся. Взамен вы лишились возможности навести в, когда то вашем, коде порядок, потому что теперь вы связаны по рукам и ногам совместимостью, связанностью и т.д.
Поздравляю! Вы очередной автор очередного г..нокода!
Что такое "чистый код"?
Как улучшить плохой код?
Почему чистый код часто "портится"?
Почему в написании кода так важны мелочи?
Читаем Роберт Мартин "Чистый Код"!
