Зачем вообще кому-то нужно иметь качественный код? Чтоб без костылей, чтоб все «по-хорошему», с комментариями и без лишних вложенных циклов?

Причин, насколько я знаю, несколько:

• Реюзабельность
• Тестируемость/правильность
• Читаемость
• Эстетика/лаконичность
• Производительность
• Масштабируемость

Все они не имеют смысла в моем случае.

Реюзабельность

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

Тестируемость

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

Читаемость

Когда говорят о читаемости кода, то имеют ввиду, что любой другой человек, владеющий этим языком программирования, мог бы легко и быстро понять, что этот код делает. Автор кода, как правило, даже через несколько лет может вспомнить логику, с которой он писал этот код. В моем случае «любого другого человека» попросту нет. Некому читать мой говнокод, поэтому и незачем его приводить в удобочитаемый вид. Если вдруг один из моих проектов внезапно выстрелит так, что его придется расширять до нескольких человек, то в любом случае нужно будет переписывать весь код с нуля. Не имеет смысла на ранней стадии проекта пытаться сделать идеальным его внутренности. А у меня все проекты заканчивают расти на ранней стадии :)

Эстетика/лаконичность

Раньше я радовался, когда удавалось сократить код с 20 строчек до 10 или 5. Но когда понял, что это не приносит ни денег, ни дополнительного удобства для посетителя, то перестал пытаться сделать код более лаконичным. Пусть этим занимаются на различных олимпиадах по программированию, у нас тут суровая жизнь. Эстетика, красота, оформление кода — ну, в этом что-то есть, когда оформление кода повышает его читаемость для меня самого. Получается эстетика на основе моих собственных правил.

Производительность

Пожалуй, это одна из главных причин в относительно недавном прошлом следить за качеством кода. У меня было несколько раз, когда из-за говнокода вырубали на шаред-хостинге или выдавалась 5хх ошибка на выделенном сервере. Но там были очень тупые косяки, которые быстро правились. В данный момент производительность железок настолько высока, что она прощает многие огрехи программной части. Контент-проекты требуют очень немного ресурсов. И если все-таки проект внезапно упирается в производительность, то достаточно беглого просмотра для поиска узких мест и устранения этих узких мест. Скорее всего это грубые ошибки типа несколько раз вложенных циклов с тяжелыми операциями, либо разросшаяся БД, структуру которой пришла пора немного изменить или сократить кол-во технических нигде не используемых данных. Есть еще один нюанс — внезапно возросшая нагрузка, когда ссылку на проект кидают на каком-нибудь посещаемом ресурсе. Тогда действительно, косяки в коде могут серьезно повредить. Хотя и это частично компенсируется облачным хостингом, когда за 10 минут можно нарастить в несколько раз производительность виртуального сервера.

Масштабируемость

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

Конечный продукт — работающий так, как задумывалось проект. Что у него под «капотом» никого не интересует. Редкие некритичные ошибки отображения исправляются достаточно оперативно, тормознутость компенсируется быстрой железкой. В результате собранный на коленке сайт практически ничем не отличается от сайта, над которым работала команда со всякими ревизиями, юнит-тестами, стресс-тестированием и прочими вещами больших дядек.