За то время, что я занимаюсь программированием, я видел не мало проектов, загнувшихся, благодаря фанатичному следованию различным модным правилам и практикам. Это может быть что-то увлекшее всю команду, например OOP или TDD, или что-то, на чем настоял отдельный разработчик, например: табы против пробелов, или определенный стиль фигурных скобок. Даже программист работающий в одиночестве, может саботировать проект, выбрав фетиш в ущерб продуктивности.
Вот немного вещей, отнимающих часы, а то и дни программистского времени:
- Табы против пробелов. Сколько ставить?
- Стиль фигурных скобок
- CamelCase, mixedCase, нижние_прочерки
- Соглашения об именовании переменных, особенно Венгерская нотация
- Ф-ции не могут быть больше 50 или 100 строк, или ф-ции не могут быть больше, одного экрана
- Никогда не использовать GOTO, eval, перегрузку операторов, синглтоны, и любые другие возможности языка, считающиеся злом.
- Функции имеют только одну точку выхода
- Никаких глобальных переменных
- Только ООП, только функциональное программирование
- Паттерны проектирования
- TDD (Разработка через тестирование)
- Диаграмма Ганта, Agile, Scrum, Экстремальное программирование, Пользовательские истории
- Никогда не использовать хранимые процедуры SQL или реализовывать всю логику на хранимых процедурах SQL
- SQL против NoSQL
- Никогда не использовать короткую форму записи тегов PHP
- Все web интерфейсы должны быть RESTful
- HTML код должен проходить валидацию W3C
- Strict XHTML
Не все из перечисленного плохо. И вообще, для программистов в команде, важно следовать каким-то общим правилам, что бы их код был понятен остальным членам команды и сочетался со всей системой. Проблемы начинаются, когда программист или команда, решают что беспрекословное следование правилам — важнее самой разработки. Когда кто-то платит вам, за приложение — действительно не важно, какие конкретно отступы вы используете в коде. Для заказчика важно, что бы программисты не тратили уйму оплаченного времени, на споры о том, так ли плохо использовать синглтоны, и все ли имена переменных соответствуют чьему-либо любимому соглашению.
Проблема похожа на культ Карго в программировании. Очень плохо, когда неопытный программист, делает что-то, не понимая, почему он это делает. Но еще хуже, когда опытный программист, превращает свои личные предпочтения в фетиш, заставляя следовать ему всех, кто с ним работает, даже если это означает некоторый риск для проекта.
Последние несколько лет, я много работаю с кодом, заброшенным, после того, как программист и заказчик разошлись, из-за перерасхода средств, срыва сроков или неоправданных ожиданий. Я вижу код, который даже не работает, но зато комментарии изобилуют ссылками на паттерны Банды Четырех. Я вижу плохо написанную замену библиотеки, которая существует только потому, что программист решил, что у стандартной отстойное название. Я вижу спецификации, переполненные обоснованиями по различным техническим решениям, в которых нет не слова про бизнес логику.
Мне также часто встречается код, который не использует специальных отступов, определенного стиля фигурных скобок, соглашения о наименовании переменных и т.д. Время потраченное мной на приведение такого кода к виду, соответствующему моему эстетическому вкусу — будет просто тратой денег клиента. Я понял, что код, написанный “не в моем вкусе”, ни разу не сложнее для меня в чтении и поддержке, чем мой собственный код.
Методологии, техники и “best practices” — должны быть понятными, и использоваться для решения проблем, но никак не стать предметом поклонения, которым нужно следовать любой ценой. Если вы тратите больше времени на споры с коллегами (или сами с собой) об именовании переменных, чем пишете полезный код — вы тратите время на фетиш-ориентированное программирование.
Автор: voff
