Pull to refresh

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

Reading time 3 min
Views 43K
Original author: Greg Jorgensen

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

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

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

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

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

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

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

Articles