Решил утащить на память к себе две чудесные статьи, которые полностью описывают моё отношение к разработке. Из первой я несогласен только с одним абзацем – который говорит про невозможность работы с неработающим кодом.

Я ненавижу программировать

Нет, не так. Программировать я люблю. Я ненавижу писать код.

Каждая строчка кода появляется на свет с первородным грехом — она виновна в своём существовании задолго до того, как я запущу компиляцию. Код — это отвратительно. Каждый объявленный тип, каждая фигурная скобка — всё кричит о своей порочности подобно изгнанному из Эдема человеку по Кальвину.

Единственное оправдание существованию кода — его способность решать проблемы. (Необязательно рабочие проблемы — например, написание того или иного кода может служить высокой цели познания мира). Но для того, чтобы оправдать своё существование, каждой строчке кода нужно выплатить много-много долгов, которые она берёт на себя автоматически при рождении. Лучший код — отсутствие кода. Но поскольку отсутствие кода не всегда умеет решать проблемы, лучший код — это минимально сложный код, решающий данную задачу. В идеале — просто обращающийся к библиотеке, которая уже умеет эту задачу решать.

Из этого следуют некоторые особенности моего стиля программирования, которые я считал самими собой разумеющимися много лет подряд, пока не столкнулся с людьми, которые по какой-то непонятной причине любят писать код. Эти особенности таковы:

— Если кто-то уже сделал решение проблемы — его необходимо использовать. За исключением тех случаев (где-то 0.5%), когда разобраться в чужой библиотеке сложнее, чем написать своё решение, или она создаёт дополнительную сложность при интеграции.

— Коду, который не работает, нет оправдания. Он должен быть немедленно снесён из проекта и забыт как страшный сон. Не закомментирован, не оставлен на будущее, а именно удалён. Если что, в гите останется история. Проект всегда должен компилироваться и запускаться (на мой взгляд, это вообще не обсуждается, но я знаю немало людей, которые сутками могут работать с некомпилирующимся проектом).

— Экспрессивные языки, где одной строчкой можно выразить целую поэму (Scala) лучше стандартизированной манной каши, где на описание простейших вещей требуются горы прелюдий (Java и особенно C++). Но дело не в количестве символов, а именно в воспринимаемой сложности, поэтому к языкам вроде J, где многие вещи укладываются вообще в несколько знаков, я отношусь скептически (хотя и ценю их порыв).

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

— Когда я слышу слова «а что если завтра…» (обычно сопровождаемые предложением ввести в проект некоторую функциональность, не нужную прямо сейчас), я хватаюсь за пистолет. Завтра никогда не наступает. А если и наступает, то обычно оказывается совсем не таким, как предполагали.

— При рефакторинге кода моя любимая кнопка — это «Delete». Каждый раз, удаляя класс, я радуюсь как ребёнок.

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

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

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

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

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

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

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

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