Про разбитые окна и программирование
«Если в здании разбито одно стекло и никто его не заменяет, то через некоторое время в этом здании не останется ни одного целого окна».
Интересная теория, которая к тому же применима и в программировании.
Часто замечал, что, если в приложении уже есть небрежно реализованные участки, то программисты, работающие в этой “аномальной” зоне, подвержены искушению подбросить в нее еще кучку неприятно пахнущего кода — “А что, хуже ведь не станет, а задача будет решена”.
Почему так происходит?
Где-то горят сроки и решили срезать углы, где-то разработчикам не хватило желания или дисциплины сделать «хорошо”, а где-то и понимания того, что значит это самое “хорошо». Да, функционал наращивается и система даже выполняет свои функции, но при этом ухудшается кодовая база, появляется больше багов, усложняется поддержка и падает мотивация у тех разработчиков, которым не все равно.
Что делать?
- Вводить стандарты кода.
- Внедрять процесс код ревью.
- Повышать уровень квалификации и ответственности команды.
- Выбивать время на рефакторинг (что жизненно необходимо, если проект уже в плачевном состоянии).
И даже в мире бьющих плетьми сроков менеджеров, апатичных и горе программистов стараться не разбивать новых окон и чинить старые.