Что такое хороший код
Что такое хороший код? Считаем звёзды
Никогда такого не было, и вот опять! Опять на прошлой неделе на Хабре появился (и был очень активно комментирован) пост, ныне удалённый, о том, что такое хороший код и чем он отличается от плохого. Яндекс подсказывает, что публикаций о хорошем (вариант: отличном, идеальном, правильном, чистом, грязном, плохом и т.д.) коде здесь уже десятки и сотни, появляются они стабильно на протяжении многих лет, всегда активно обсуждаются, но к единому мнению на этот счёт так и не пришли.
Этот код тянет как минимум на одну звезду 🙂
Такой код в настоящее время распространён повсеместно. Причин этому несколько, вот наиболее заметные:
Массовая цифровизация, из-за которой техзадания программистам ставят люди, далёкие от IT (например, руководители заводов) и они в принципе не могут оценить качество кода.
Высокие зарплаты в IT активно привлекают всех-всех-всех, которые трудоустраиваются, пройдя курсы «вайти-вайти за месяц» и имея соответствующие навыки.
Справедливости ради: не всегда это плохо. Если разработка маломасштабная, то её и оптимизировать особо незачем (и так летать будет, ну ведь правда же!). Так или иначе, такой код обычно пишут начинающие программисты и по мере обретения опыта переходят на уровень выше.
Код, который не просто работает, но ещё и работает достаточно быстро. Можно сказать, что этот код оптимизирован по процессорной вычислительной мощности. Одно из формальных определений:
Программа считается эффективной по времени, если время работы программы пропорционально количеству элементов последовательности поступивших данных N, т.е. при увеличении N в k раз время работы программы должно увеличиваться не более чем в k раз.
На практике эффективность по времени иногда определяется не по этому учебно-тренировочному критерию, а по объективным целям и задачам проекта, и может быть задана как относительно («на каждый N не больше k»), так и абсолютно («открывать окно не дольше 0,5 секунды») или даже субъективно («не менее 80% опрошенных согласились, что программа открывается мгновенно»).
Код, который задействует условно небольшое количество памяти при работе. Можно сказать, что он оптимизирован не только по процессорной мощности, но и по оперативной памяти.
Код, который сам имеет минимальный объём. Можно сказать, что он оптимизирован и по процессору, и по оперативке, и по накопителю.
Обычный программист может при желании слегка усечь объём кода: заменив повторяющиеся куски на функции, используя однобуквенные переменные или даже через #define заблаговременно переименовать все команды языка в более краткие, если это оказывается выгодно. Однако всё это, конечно, баловство, которое приносит минимальный результат и в целом скорее вредит. Для того, чтобы принципиально сократить код путём его полной переработки, требуется очень высокая квалификация.
Код, который не только отлично оптимизирован, но и прекрасен: легко читаем, красиво оформлен, в нужных местах прокомментирован, понятен будущим поколениям программистов. Высший пилотаж от мира IT. Дальнейшие комментарии, как говорится, излишни.
Выводы
Понятно, что моя классификация далека от идеала. Например, как классифицировать красиво оформленный, но при этом неоптимизированный код, если оптимизация не очень важна? Поэтому я не претендую на высшую истину в этом вопросе, но надеюсь, что эта заметка поможет приблизиться к таковой, дав пищу для размышлений.
Что такое хороший код, или как стать востребованным разработчиком
Данный цикл статей предназначен прежде всего для начинающих разработчиков или для тех, кому не понятно, почему они до сих пор «бегают» в джуниорах, а не сеньорах.
Начну, пожалуй, с философии, а именно, со слов Сократа: «Вот вам мой совет — никогда не слушайте ничьих советов».
Уверен, что вопрос «Что такое хороший код?», возник с самого начала появления такой отрасли как программирование. И в процессе становления этой индустрии критерии оценки довольно серьезно менялись. Вот некоторые из них:
Хороший код — это код минимального размера, проще говоря, употребление минимального количество операторов, которое необходимо для достижения результата.
Хороший код — это код, который наиболее быстро исполняется в системе.
Хороший код — это код, который… бла-бла-бла.
Я занялся программированием более 20 лет назад и честно пытался придерживаться правил написания хорошего кода, которые были актуальны на тот период времени. Только вот в чем фишка: как бы я ни старался, меня не покидало ощущение, что я написал нехорошо и можно сделать лучше. И я старался снова, осваивал новые технологии, некоторые канули в лету, некоторые развились настолько, что стали иметь мало общего с первоначальным прототипом, и все равно я так и не получил 100% уверенности, что да — этот код написан хорошо. И как оказалось, причина этому довольно проста. Хорошего кода в классическом понимании не существует, потому что невозможно угодить всем и вся. Но в процессе поиска ответа на вопрос, как научиться писать хороший код, я получил ответы на множество других вопросов и, что самое важное для программиста — это профессиональный опыт и знания. И я готов поделиться своим опытом в своих статьях.
И вот первый совет: если хотите быть профессиональным разработчиком, готовьтесь к тому, что придется учиться постоянно.
Любой продукт имеет заказчика априори. Заказчиком может выступать ваш непосредственный работодатель, какой-либо сторонний заказчик, либо вы сами. Так может быть, если программный продукт, который полностью реализует требования заказчика — это и есть эталон, который можно обозвать хорошим кодом? Это первое заблуждение новичка. На самом деле сделать продукт согласно требованиям заказчика может любой разработчик. В срок — опытный разработчик, а вот сделать продукт в срок и правильно может только профессионал. Таким образом, правильно написанный код — это тот, который легко поддерживать и сопровождать.
Легко масштабируемый продукт — это продукт, на внесение изменений в который уходит минимум средств (под средствами понимаются любые трудозатраты: будь то труд/ часы разработчика или тестировщика, время, затрачиваемое на управление проектами и даже время на коммуникацию!)
Разобрались с первым, правильно написанный код — это код, который легко масштабируется.
Примечание: у любого правила есть исключения, и на моем опыте они выглядят следующим образом. У кода (программы) существует два основных критерия: первый — это быстродействие, второе — масштабируемость. Так вот добиться их одновременно — пустая трата времени так как они, как правило, противоречат друг другу. Часто намного дешевле увеличить быстродействие с помощью добавочного железа, чем нанять группу разработчиков, которые оптимизируют программу, при том что при оптимизации увеличивается вероятность насаживания новых багов и т.д., и, наверное, самый главный плюс — это управляемость кода.
Совет второй — ваша задача как разработчика, это понять, что нужно заказчику. Чем точнее вы это поймете, тем точнее вы это реализуете.
Чем быстрее и гармоничнее происходит процесс, тем более важной частью команды Вы становитесь:
• Программирование — это командный вид отрасли, если хотите преуспеть в ней, то с этим придется считаться;
• Если вы думаете, что вы самый умный программист, а все остальные программисты тупые, то советую переехать из Антарктиды и прекратить общаться с пингвинами. Допускаю, что они не очень сильны в этой области, но, если вы все-таки находитесь в цивилизации и являетесь сотрудником маленькой компании, тогда вперед в большую. Уверяю на 100% вас там ждут, правда, вас проверят на наличие знаний и спрашивать о них будут не пингвины;
• Если вы гениальны в программировании и считаете, что компания с большим (хорошо, уточню) многомилионным оборотом и выше будет расположена к вам, то вы ошибаетесь. Скорее всего вы окажетесь за бортом. Объясняю на своем примере: от меня должностные обязанности требуют управления командой разработчиков. Другими словами, на мне лежит ответственность за сроки разработки и качество кода разработки. А вот с чем я сталкиваюсь, когда беру в команду гениального программиста:
Первое. Продукт должен быть доставлен в срок. Гениальный программист никогда не соблюдает сроки, и причина проста: он ВСЕГДА пытается найти наилучшее решение, не понимая, что лучшее — враг хорошему.
Второе. Продукт должен быть надлежащего качества. Гениальный программист всегда будет добиваться чтобы качество было наилучшим и, к сожалению, это во вред срокам и работе всей команды.
Третье. По мнению гениального программиста, продукт есть действие его самого, а не всех участников команды, и его гениальный мозг не терпит чтобы вы что-то поменяли в его архитектуре без его ведома.
Четвертое. Гениальный программист не понимает, что, если в контроле «КНОПКА» обнаруживается текст «КНОПКО» — для заказчика это баг.
Отсюда главный совет — ваша задача, если хотите быть профессионалом, то быть частью команды, а если знания позволяют, то быть её значимой частью. В помощь — ответы на актуальные вопросы.
Как отличить хороший код от плохого?
По сигнатуре кода. В большинстве случаев хороший код от плохого отличается логикой и архитектурой. Используйте в разработке принципы SOLID и всегда их придерживайтесь.
Что нужно всегда помнить при разработке программ?
Старайтесь не нарушать и не отклоняться от базовых принципов, даже если пишите какой-то тест для себя. Нужен класс — начните его писать с разработки интерфейса, даже если в этом нет прямой необходимости. Это вырабатывает стиль. Не ленитесь перечитывать литературу и добивайтесь не заучивания, а понимания материала.
Сколько и чему нужно учиться чтобы стать востребованным (и хорошо оплачиваемым) разработчиком?
Текст объявления: «Нужен личный водитель до 20 лет с навыками эксперта по рукопашному бою, умению пройти тренировочный рубеж спецназа ГРУ за минуту в водолазном скафандре, при этом поджарив одновременно 10 пирожков на одной сковородке». Примерно так обычно описываются должностные обязанности. Но это совершенно не значит, что вам все это нужно выполнять. В требованиях, как правило, указан максимум. Выделите из всего круга то, что вы знаете и умеете, добавьте немного артистизма и красок, и вперед — убеждать наших менеджеров по персоналу. Но прежде чем это сделать, все-таки оцените трезво свои знания. А то у некоторых есть один очень хороший симптом под названием «Я знаю очень много», который сразу говорит о том, что вы обладаете посредственным багажом знаний. С другой стороны, если у вас большое количество вопросов и вы начинаете понимать, как мало вы знаете, то это уже показатель, что ваш багаж знаний солидный и можно претендовать на уровень разработчика, а не джуниора.
Сколько требуется учиться — это очень индивидуально, но в любом случае знает больше тот, кто больше учиться, и, как я уже говорил, программирование такая отрасль, в которой нужно учиться постоянно. Но в среднем цифры такие:
• достичь уровня начинающего разработчика (junior) вполне можно за 6 месяцев;
• достичь уровня разработчика (developer) — за 12-18 месяцев;
• продвинутого разработчика (key developer) — 2-5 лет;
• экспертного уровня(seignior) — от 7 лет и выше.
С чего начать?
В качестве ответа на этот вопрос хорошо подходит высказывание Лао-Цзы: «Даже самое долгое путешествие начинается с первого шага».
Практика хорошего кода
За годы присутствия на хабре я прочитал немало статей на тему того, как должен выглядеть идеальный код. И поменьше статьей о том, как конкретно достигать этого идеала. Также стоит отметить, что весьма значительная часть всех этих материалов была переводом западных источников, что, вероятно, является следствием более зрелой отрасли IT «за рубежом», со всеми вытекающими вопросами и проблемами.
К сожалению, во многих случаях авторы либо забираются в недосягаемые выси многослойных архитектур, что требуется в лучшем случае для 1% проектов, либо ограничиваются общими фразами вроде «код должен быть понятен» или «используйте ООП и паттерны», не опускаясь до подробных объяснений, в чем например измеряется «понятность» кода.
В этой статье я хочу попытаться систематизировать те критерии оценки качества кода, и те практики его написания, которые мне удавалось применять в реальных проектах практически независимо от их размеров и специфики, используемого языка программирования и других факторов.
1. Простота
Здесь все уже придумано до нас — существует замечательный принцип KISS, а также афоризм Альберта Эйнштейна «Все должно быть изложено так просто, как только возможно, но не проще», которыми всем нам стоит руководствоваться.
Простой код лучше сложного по всем параметрам — проще для понимания, легче поддается изменениям и тестированию, требует меньше комментариев и документации, содержит меньше ошибок (хотя бы чисто статистически, если мы принимаем среднее количество ошибок по отношению к количеству языковых и логических конструкций в коде за некоторую постоянную величину для каждого конкретного программиста).
Также, перефразируя положение ТРИЗ об идеальной системе можно сказать, что идеальный код — тот, которого нет, причем задача, которую он должен решать — успешно решается. Очевидно, что этот идеал (как и любой другой), недостижим на практике, однако способен направить ум разработчика в нужном направлении.
На практике все эти красивые фразы означают одно — не используйте инструменты, реальная (а не гипотетическая) польза применения которых не превышает ущерб от усложнения и запутывания кода. Не стройте приложение вокруг целого фреймворка ради одной узкой задачи, которую он может помочь решить. Не используйте сложные паттерны там, где можно обойтись простым классом. Не используйте класс для пары функций, которые даже не работают со свойствами родного объекта в своем коде (в обратном случае — используйте). Не оборачивайте в функцию код из 3-х строк, который нигде более в приложении не используется повторно (и не будет использоваться в ближайшем будущем, а не через 150 лет).
Разумеется, все это вовсе не означает, что нужно писать спагетти-код в императивном стиле на 5000 строк. Как только возникнет такое желание, нужно еще раз перечитать и осознать вторую часть цитаты приведенной выше, о том что код должен быть «простым, насколько возможно, но не проще«.
Не нужно бояться простых конструкций, если они позволяют решить поставленную задачу. Также не стоит прикрываться размышлениями на тему того, как ваш код может быть теоретически использован при развитии проекта или смене пожеланий заказчика через год-другой. Дело даже не в том, что ваш код будет «в любом случае выброшен и переписан с нуля», как заявляют многие сторонники простой и быстрой разработки. Возможно, что не будет. Но проблема в том, что с высокой долей вероятности вы просто не угадаете нужного направления. Вы спроектируете молоток так, чтобы им можно было (после небольшой доработки напильником) закручивать саморезы, а окажется, что нужно прикрутить автоматическую подачу гвоздей и лазерное наведение при замахе. И ваша архитектура, рассчитанная под развитие в определенную сторону, только проиграет по сравнению с «просто молотком». Поверьте, я знаю, о чем говорю, т.к. уже 5 лет поддерживаю проект в рунете, который вырос и стал довольно успешным вообще не на том, куда были вложены максимальные усилия и ради чего он создавался, а за счет небольшой ветки «побочного» функционала.
2. Концептуальность
Этот критерий во многом пересекается с «простотой» кода, но все-таки я решил его вынести в отдельный раздел. Суть подхода — в использовании концепций, причем в идеале — общепринятых концепций, которые уже широко применяются в других решениях.
Примером блестящей концепции является «перенаправление» в UNIX-системах, которое позволяет создавать различные программы, не тратя ни строчки кода на то, как они будут работать с чтением/записью в файлы или другие потоки, либо на взаимодействие с другими программами, например текстовым фильтром grep. Все что нужно — обеспечить стандартный интерфейс ввода/вывода текста.
Таким образом даже несколько десятков наиболее популярных команд порождают тысячи вариантов их использования. Напоминает что-нибудь? Правильно — это решение задачи с помощью «кода, которого нет».
Более простой пример из практики — однажды мне потребовалось ротировать на одном рекламном месте сайта объявления сторонней рекламной сети с двух различных аккаунтов, с условием примерно равного распределения прибыли между ними (с допустимым отклонением 1-2%). Громоздкое решение, которое можно было бы применить «в лоб», состояло в том, чтобы фиксировать в базе данных показы объявлений по каждому аккаунту с учетом стоимости этих показов (которые тоже могли отличаться), и на основании этих данных при каждом следующем открытии страницы принимать решение о том, чьи объявление показывать, чтобы обеспечить минимальный дисбаланс.
Чуть позже выяснилось, что согласно закону больших чисел банальная проверка вероятностей по принципу «орел-решка» при выборе аккаунта полностью решает задачу в рамках заданных условий. Более того, не составляет никаких проблем таким образом распределять показы между 3 и более аккаунтами. Само собой, это не придуманная человеком концепция, а базовый математический принцип, но с точки зрения кода важно лишь одно — это работает.
3. Уникальность функционала (Don’t repeat yourself)
Принцип «Don’t repeat yourself» (сокр. DRY) говорит нам о том, что каждая функциональная единица системы, будь то логический блок кода, функция или целый класс, должна быть представлена в коде только один раз.
Повторяющиеся блоки кода обычно выносятся в функции. Для функций используются подключаемые библиотеки и пространства имен. Когда же дело доходит до классов, в бой вступает целый зоопарк методик, направленных на снижение дублирования кода, начиная от банального наследования и заканчивая сложными системами из «фабрик по производству фабрик» вперемешку с «фасадными адаптерами», которые зачастую требуют больше кода и умственных усилий программиста, чем позволяют сэкономить.
Стремление с самого начала спроектировать код так, чтобы избежать любых повторений — заведомо губительно, т.к. для 80% ситуаций вы не будете знать о дублировании кода, пока не напишите его.
Реальный совет для практического использования в любом проекте — решайте проблему дублирования кода сразу после ее обнаружения (но не раньше!), и делайте это наиболее простым и очевидным способом, доступным вам в текущей ситуации.
Есть несколько очень похожих блоков кода из 5-10 строк, отличающихся лишь парой условий и переменных, но вы пока не уверены, как лучше завернуть их в функцию? Используйте циклы.
Не знаете, в какой класс/объект положить код нового метода? Просто создайте функцию и положите ее в подключаемую библиотеку до тех времен, когда у вас появится более полная информация о разрабатываемой системе.
Используете наследование классов, но приходится полностью переопределять 50-строчный метод в наследнике ради изменения одной логической конструкции? В первую очередь подумайте о разделении большого метода на несколько более изолированных, либо об использовании инстансов других классов со всеми их методами в качестве значений свойств исходного объекта.
Простые и проверенные решения позволят решить 95% всех проблем с дублированием кода, а для оставшихся 5% надо 10 раз подумать о целесообразности механического применения сложных конструкций «из учебников» по сравнению с осмысленным перепроектированием «плохого» участка кода (с упором на снижение сложности и повышение читабельности).
Вы всегда сможете заменить простое решение на более высокоуровневое, и сделать это будет намного проще, чем применять сложный рефакторинг к сырому коду на более позднем этапе, когда дубликаты уже разбросаны по всей системе.
4. Удобочитаемость
Что можно сказать в заключение
Статья получилась несколько более объемной, чем было запланировано, хотя я сознательно избегал обсуждения множества аспектов, вроде связности и связанности, шаблонов проектирования и других понятий, о которых уже написаны целые книги, и можно написать немало новых.
Моей целью было подробно изложить самые основы «правильного» (с моей точки зрения) программирования, многие из которых достойны пера Капитана Очевидности, и тем не менее регулярно игнорируются большинством разработчиков, особенно в веб-сегменте. Хотя соблюдение только этих простых основ, без углубления в дебри перфекционизма, способно сделать их код лучше в разы, во всех отношениях.
Если я что-то упустил или где-то ошибся — конструктивная критика в комментариях всячески приветствуется.
Как важно писать хороший код
Мне приходится очень много читать код. Это и open source, и всяческие фреймворки, и код enterprise приложений. Именно о последних я хотел бы сегодня поговорить.
Большая часть кода enterprise приложений — отстой. Приложения глючат и тормозят, их сложно тестировать, постоянно проблемы с развертыванием и обновлением. Это как бы никого не удивляет.
Но удивляют люди, написавшие отстойный код. Эти люди, с немалым опытом, знают несколько языков, прочитали много книг, знают ООП, SOLID, рефакторинг, паттерны и другие малопонятные слова. То есть примерно такие, как многие из вас, читающих этот пост.
Теория разбитых окон
В 1969 году был проведен эксперимент. В ходе эксперимента две одинаковые машины были оставлены в двух местах – в благополучном университетском городке и неблагополучном районе крупного города. Не удивительно что в неблагополучном месте машина простояла всего пару дней и была выпотрошена, а в благополучном машина простояла нетронутой неделю. Но как только в уцелевшей машине разбили стекло, жители этого самого благополучного городка за несколько часов разобрали её на детали и перевернули вверх дном.
В последствии ученые назвали это явление “Теорией разбитых окон”. Согласно теории, любое проявление беспорядка или нарушение норм провоцирует людей также забыть о правилах. Теория получила несколько экспериментальных подтверждений и её можно считать вполне достоверной.
Есть также и обратный эффект. Поддержание порядка приводит к тому, что окружающие также поддерживают порядок.
Как это влияет на код
В enterprise разработке прессинг сроков и неопределенности требований бывает настолько высок, что кажется сделать “быстро и грязно” – гораздо лучший вариант, чем сделать правильно. Моментально подход “быстро и грязно” начинает распространяться по всему приложению, как путем clipboard inheritance (aka copy-paste), так и за счет эффекта разбитых окон.
Еще один фактор влияющий на качество кода – сложность и несовершенство платформ и фреймворков, используемых в разработке. Из-за этого в коде часто появляются хаки и нелепые workaround-ы. Со временем начинает казаться что эти хаки и есть хороший код. Даже когда проблемы фреймворков исправляют, люди продолжают использовать хаки. Кстати эти хаки со временем могут попадать в интернет через форумы, блоги или pastebin и распространяться далеко за пределы одного приложения.
Вы можете сказать, что качество кода не влияет на качество приложения. Увы, еще как влияет. Программисты допускают ошибки. Чем более плохой код, тем сложнее эти ошибки найти и исправить так, чтобы не создать новых. Прессинг сроков и сложности, скорее всего, не даст написать хороший код и появится еще один хак.
В open source и продуктовой разработке такое встречается реже. Там больше следят за качеством и меньше прессинг сроков.
Код пишется для людей
Часто программисты забывают что код программ пишется в первую очередь для людей. Даже если вы пишите программу в одиночку, то посмотрев на нее через месяц, вы не вспомните почему написали тот или иной кусок кода и за что он отвечает.
Хороший код должен, в первую очередь, очень ясно выражать намерения. К сожалению “быстрые и грязные” способы разработки бьют в первую очередь по понимаемости кода. Улучшение кода осознанно откладывается до лучших времен, когда будет пауза чтобы провести рефакторинг. Те самые лучшие времена никогда не наступают, а код начинают читать и дорабатывать сразу же после попадания в source control.
Даже если вы полностью довольны свои кодом (в большинстве случаев программисты свои кодом довольны), то подумайте о том как будет ваш код читать другой человек (в большинстве случаев программисты недовольны чужим кодом).
Приверженность качеству
Единственный способ добиться высокой продуктивности и эффективности – писать хороший код сразу. Единственный инструмент повышения качества кода – вы сами. Если вы не стремитесь всегда делать хороший код, то вам не помогут ни тесты, ни инструменты статического анализа. Даже ревью других программистов не поможет. Код всегда можно сделать настолько запутанным, что в нем невозможно будет найти ошибку при чтении, при этом сделать вид, что код очень важен и никто не возьмется его переписать.
В первую очередь необходимо думать о структуре и именовании. Код с зашифрованными идентификаторами и малопонятным потоком исполнения скорее всего будет содержать ошибки. Не допускайте такого кода, это гораздо дешевле, чем исправлять ошибки.
Ясно выражайте намерения в своем коде, сводите к минимуму неочевидные неявные аспекты. Не надо стремиться сделать код максимально лаконичным, стремитесь сделать его максимально понятным.
Если вам приходится править код, то не создавайте хаков. Потратьте немного времени, напишите нормально. Сэкономите на поддержке. Если же код совсем плохой, был сделан “быстро и грязно” и оброс хаками, то просто выкиньте его и перепишите. Только не надо пытаться переписать все. Учитывайте продуктивность: программист пишет 40-60 отлаженных строк кода в день в нормальном темпе и 120-200 в ускоренном (высокая концентрация, четкая цель, понятно что делать).
Если вы сами пишете “быстро и грязно”, например прототип для уточнения требований, то выкиньте код и перепишите нормально сразу после того, как ваш код сделает свое дело.
Если вы скопировали часть кода из другого места или, не дай бог, из интернета, то разберитесь как он работает, прежде чем заливать изменения в source control. Вообще не используйте непонятные для вас фрагменты кода.
Всегда поддерживайте чистоту и порядок в вашем коде, пользуйтесь инструментами, которые помогают вам это делать. Не будете этого делать – код очень быстро превратится в помойку. Собирайте статистику по плотности проблем в коде, это поможет вам лучше понять, как писать хороший код.
Перечитывайте свой код. Проводите рефакторинг постоянно в процессе написания. Помните, что рефакторинг “потом” никогда не наступает.
Думайте о том, какой код вы хотите написать, до того как начать его писать. Само написание кода – настолько поглощающий процесс, что думать о качестве некогда. Состояние потока – это состояние свободы самовыражения. Необходимо заранее ограничить самовыражение, чтобы код получился хорошим.
Экономика качества кода
Все знакомы с кривой стоимости ошибки: 
Ошибка найденная и устраненная на этапе кодирования в 10 раз дешевле, чем ошибка найденная при тестировании и в 100 раз дешевле ошибки, найденной в production. В истории есть реальные примеры ошибок, исправление которых обошлось в десятки тысяч долларов.
Поэтому очень важно устранять ошибки на этапе разработки, причем усилиями самих разработчиков.