Фетиш-ориентированное программирование

За то время, что я занимаюсь программированием, я видел не мало проектов, загнувшихся, благодаря фанатичному следованию различным модным правилам и практикам. Это может быть что-то увлекшее всю команду, например OOP или TDD, или что-то, на чем настоял отдельный разработчик, например: табы против пробелов, или определенный стиль фигурных скобок. Даже программист работающий в одиночестве, может саботировать проект, выбрав фетиш в ущерб продуктивности.
Вот немного вещей, отнимающих часы, а то и дни программистского времени:

• Табы против пробелов. Сколько ставить?
• Стиль фигурных скобок
• CamelCase, mixedCase, нижние_прочерки
• Соглашения об именовании переменных, особенно Венгерская нотация
• Ф-ции не могут быть больше 50 или 100 строк, или ф-ции не могут быть больше, одного экрана
• Никогда не использовать GOTO, eval, перегрузку операторов, синглтоны, и любые другие возможности языка, считающиеся злом.
• Функции имеют только одну точку выхода
• Никаких глобальных переменных
• Только ООП, только функциональное программирование
• Паттерны проектирования
• TDD (Разработка через тестирование)
• Диаграмма Ганта, Agile, Scrum, Экстремальное программирование, Пользовательские истории
• Никогда не использовать хранимые процедуры SQL или реализовывать всю логику на хранимых процедурах SQL
• SQL против NoSQL
• Никогда не использовать короткую форму записи тегов PHP
• Все web интерфейсы должны быть RESTful
• HTML код должен проходить валидацию W3C
• Strict XHTML

Не все из перечисленного плохо. И вообще, для программистов в команде, важно следовать каким-то общим правилам, что бы их код был понятен остальным членам команды и сочетался со всей системой. Проблемы начинаются, когда программист или команда, решают что беспрекословное следование правилам — важнее самой разработки. Когда кто-то платит вам, за приложение — действительно не важно, какие конкретно отступы вы используете в коде. Для заказчика важно, что бы программисты не тратили уйму оплаченного времени, на споры о том, так ли плохо использовать синглтоны, и все ли имена переменных соответствуют чьему-либо любимому соглашению.

Проблема похожа на культ Карго в программировании ^[1]. Очень плохо, когда неопытный программист, делает что-то, не понимая, почему он это делает. Но еще хуже, когда опытный программист, превращает свои личные предпочтения в фетиш, заставляя следовать ему всех, кто с ним работает, даже если это означает некоторый риск для проекта.

Последние несколько лет, я много работаю с кодом, заброшенным, после того, как программист и заказчик разошлись, из-за перерасхода средств, срыва сроков или неоправданных ожиданий. Я вижу код, который даже не работает, но зато комментарии изобилуют ссылками на паттерны Банды Четырех. Я вижу плохо написанную замену библиотеки, которая существует только потому, что программист решил, что у стандартной отстойное название. Я вижу спецификации, переполненные обоснованиями по различным техническим решениям, в которых нет не слова про бизнес логику.

Мне также часто встречается код, который не использует специальных отступов, определенного стиля фигурных скобок, соглашения о наименовании переменных и т.д. Время потраченное мной на приведение такого кода к виду, соответствующему моему эстетическому вкусу — будет просто тратой денег клиента. Я понял, что код, написанный “не в моем вкусе”, ни разу не сложнее для меня в чтении и поддержке, чем мой собственный код.

Методологии, техники и “best practices” — должны быть понятными, и использоваться для решения проблем, но никак не стать предметом поклонения, которым нужно следовать любой ценой. Если вы тратите больше времени на споры с коллегами (или сами с собой) об именовании переменных, чем пишете полезный код — вы тратите время на фетиш-ориентированное программирование.

Автор: voff

Источник ^[2]