О чистоте кода

Нам пишет Алексей Чикин:

Хочу задать вопрос именно тебе, как человеку, который сделал Е2. Что важнее, сделать готовый продукт такой, чтобы был прост в обращении, красив, удобен, но при этом сделать его так, как умеешь, без использования всех этих современных паттернов проектирования, замудростей с объектно-ориентированным программированием и выпиливании внутреннего кода до совершенства, или же надо сделать, чтобы всё было кошерно, чтобы код удовлетворял всем современным требованиям?

Просто у меня дилемма. Я сделал нечто, что мне нравится, но я сделал это так, как я умею. И мои умения далеки от гуру-программирования. Стоит ли это нечто представить публике или всё таки убить какое-то время на изучение и рефакторинг кода?

То есть вопрос в следующем. Важно что там и как внутри устроено или результат важнее?

Смотрите, что является вашим продуктом? Код или полезное действие, который он обеспечивает? Я не даю исходники Эгеи, потому что продуктом является сам движок, а не его код. Бывает, конечно, наоборот: если вы делаете какую-то опенсорсную библиотеку, то сам код и является продуктом. В этом случае, несомненно, важно, как он устроен внутри. Но в большинстве случаев пользователи не взаимодействуют с кодом вообще никак и никогда, и поэтому его внутреннее устройство не имеет значения.

Но всё не так просто.

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

Эгея вышла только этим летом, потому что я посвятил предыдущие три года приведению в относительный порядок её кода. Это немыслимо длительный срок для обновления программы, даже для некоммерческого проекта выходного дня. Сейчас мне намного проще добавлять разные плюшки благодаря проделанной тогда работе. Если бы я лучше писал код 8 лет назад, сегодня Е2 как продукт был бы в сто раз лучше, чем есть.

Или вот Биатлонтайм. Там совершеннейшая, беспросветная жесть под капотом. Потому что всё приходится программировать очень быстро. Вдруг оказывается, что судьи добавили кому-то 20 секунд времени штрафа согласно правилу такому-то, а код сайта не знает о том, что так вообще может быть. Приходится делать через жопу, прописывая исключение прямо в коде, потому что результаты публиковать надо прямо сейчас, и это важнее красоты кода. А вот заставлять себя потом привести всё это в порядок удаётся не всегда, и это уже мне мешает добавлять новые штуки на сайте.

Так что, конечно, вне всякого сомнения, результат важнее качества кода, но нельзя из этого делать вывод, что на качество кода можно плевать, потому что оно очень быстро начинает влиять на результат.

Отдельно хочу предостеречь вас от приравнивания понятий «качество кода» и «использование современных паттернов проектирования». Между ними нет ничего общего. Использование современных паттернов, ООП, модных фреймворков, валидной семантической вёрстки, распределённых систем контроля версий и всего другого сами по себе никому не нужны. Используйте их только тогда, когда сами точно знаете, какую именно пользу они приносят вашему продукту.