«Если в здании разбито одно стекло и никто его не заменяет, то через некоторое время в этом здании не останется ни одного целого окна».
Интересная теория, которая к тому же применима и в программировании.
Часто замечал, что, если в приложении уже есть небрежно реализованные участки, то программисты, работающие в этой “аномальной” зоне, подвержены искушению подбросить в нее еще кучку неприятно пахнущего кода — “А что, хуже ведь не станет, а задача будет решена”.
Почему так происходит?
Где-то горят сроки и решили срезать углы, где-то разработчикам не хватило желания или дисциплины сделать «хорошо”, а где-то и понимания того, что значит это самое “хорошо». Да, функционал наращивается и система даже выполняет свои функции, но при этом ухудшается кодовая база, появляется больше багов, усложняется поддержка и падает мотивация у тех разработчиков, которым не все равно.
Что делать?
- Вводить стандарты кода.
- Внедрять процесс код ревью.
- Повышать уровень квалификации и ответственности команды.
- Выбивать время на рефакторинг (что жизненно необходимо, если проект уже в плачевном состоянии).
И даже в мире бьющих плетьми сроков менеджеров, апатичных и горе программистов стараться не разбивать новых окон и чинить старые.
- делайте хорошо
- не делайте плохо
- гуляйте на свежем воздухе
- читайте умные книги...
Пустопорожний трёп очередной. Скиньте кейс по введению новых стандартов в вашей компании и на сколько процентов увеличились показатели благодаря этому. Скиньте ссылку на этот проект.
Это конечно не кейс, но можете почитать https://vc.ru/dev/242768-dolg-inflyaciya-i-bankrotstvo-chto-skryvaet-iznanka-it-produktov
Интересно что происходит когда разбиты все окна и разрушены жылие кварталы?