Павел Вейник: «Все хотят писать красивый код. Откуда вокруг столько г…кода?»

51 комментарий
Павел Вейник: «Все хотят писать красивый код. Откуда вокруг столько г…кода?»

В своей колонке программист Павел Вейник рассуждает о том, как мир разработчика и «красивого кода» пересекается с миром заказчика и бизнеса.

Читать далее

Фото: Markus Spiske via Unsplash

Один разработчик говорит другому: «Как думаю — так и пишу». А тот ему отвечает: «Фу, как животное!».  

Эту формулировку — «как животное» — произнёс один умнейший человеком, и она оказала на меня огромное воздействие. Сакральный смысл в том, что надо не только «думать и писать», но и думать, как ты думаешь — анализировать свой способ думанья и улучшать его, чтобы это отражалось на твоём коде.

В связи с этим хочется поговорить о том, как мир разработчика и кода, каким я его себе представляю, стыкуется с миром заказчика и бизнеса — и что при этом происходит. Оговорюсь: это моё полнейшее субъективное имхо.  

Два полюса: красивый код vs кровавый говнокод на костылях и распорках

Вот чему учат разработчиков: код должен быть красивый, правильный, поддерживаемый, написанный по чётким и понятным критериям, начиная от правильно расставленных скобочек и заканчивая шаблонами проектирования.

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

У каждого есть свой пример самого страшного кода, когда-либо встречавшегося на пути. В моём случае это аутсорс-проект на Apache Wicket, который мне пришлось поддерживать несколько месяцев. В нём глубина вложенности анонимных классов была 5-7 уровней по всему проекту. Чтобы исправить баг на 4-5 уровне вложенности, нужно было или рефакторить буквально весь проект, или создавать ещё один уровень вложенности, увеличивая количество говнокода и его «ужасность». Разумеется, времени на наведение красоты не было вообще. Страдая и истекая кровью, я плодил и умножал говнокод.

Напротив, как пример красоты и правильности можно вспомнить код Unix ещё из универа. Он написан давным-давно, но настолько просто, расширяемо и удобно, без сумасшедших алгоритмов (в большинстве случаев), что даже сложные вещи более-менее просто реализуются. Главное, понять концепцию.

Общий расклад такой: на одном полюсе — красивый код, на другом — кошмарный говнокод в кровавом энтерпрайзе, а посередине — все проекты, которые вообще пишутся.

Павел Вейник. Фото: Андрей Давыдчик.

Причины появления «костыльных» проектов: хотят ли разработчики писать говнокод?

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

Как же получается, что при таком отношении разработчиков к красоте кода (по крайней мере, именно оно декларируется) редко удаётся найти действительно красивый проект без говнокода? В чём секрет?

Говнокод всегда появляется по каким-то причинам.

Во-первых, контекст кода. У проекта, в рамках которого пишется код, всегда есть деньги, сроки, влияющие персоны (заказчик, постановщики, участники, включая жену или девушку разработчика), каждая из которых тянет проект в свою сторону, иногда — очень сильно тянет.

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

Контекст кода: нужен ли красивый код менеджеру?

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

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

Что думает менеджер, когда разработчик просит у него три дня на рефакторинг? Ага, команда с азартом потратит три дня (а раз разработчик сказал 3, то бери шире — все 5-6) на непонятно что, не добавив в проект нового функционала. При этом проект превратится в terra incognita: я не буду знать, какие проблемы в нём остались, какие исправлены, а какие прибавились, — его придётся заново исследовать. Более того, мне придётся как-то объяснять эти изменения ошарашенным влияющим персонам.

Ладно, всё это можно пережить. Но кое-что пережить нельзя: у проекта есть сроки, которые и без того нередко срываются, а эти ребята хотят сорвать их окончательно. Нет, мало ли что хотят эти разработчики! Лучше-ка я не дам времени на этот мутный рефакторинг и поставлю задачи поважней: пусть баги исправляют и фичи добавляют. А там, глядишь, и проект закончится. Как-нибудь проживём.

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

В позициях разработчика и менеджера по этому вопросу виден чёткий и явный конфликт: между красотой кода и скоростью/стоимостью разработки. К слову, Unix писался долго, разными людьми, без ограничений по ресурсам. Просто мечта разработчика! Вообще-то, есть примеры проектов без ограничений по ресурсам, не менее ужасных, чем любой говнокод.

Фото: Андрей Давыдчык

Just business: нужен ли красивый код заказчику?

Попробуем подняться на ступень выше, над разработчиком и менеджером.

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

Яркий пример: проект, который запомнился мне в качестве самого страшного говнокода в моей жизни, был коммерчески успешен.

Резюме: удобные ботинки первичнее красивых

Итак, разработчики зажаты между Сциллой и Харибдой: сроками и внутренним желанием писать красивый код. Чем больше давление в части сроков, чем больше проблем во внутренней организации разработки, чем больше изменений в процессе работы над проектом, — тем больше говнокода.

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

Пятиминутка иронии: тот, кто громче всех кричит про говнокод, периодически и сам пишет говнокод, а иногда ещё и не отдаёт себе в этом отчёта.

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

Красота красотой, но есть вещи более важные.

В этом и заключается культура кода: сначала разработчик должен сделать работающую вещь по заказу — а потом уже, если у него хватит умений, времени, пороху и прочего, сделать эту вещь красивой изнутри.

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

 

Публикация подготовлена при участии Натальи Провалинской

 


*Мнение колумнистов может не совпадать с позицией редакции.

Хотите сообщить важную новость?

Пишите в наш Телеграм

Горячие события

Вебинар «Советы от рекрутеров: как найти квалифицированную работу в Европе»
4 июня

Вебинар «Советы от рекрутеров: как найти квалифицированную работу в Европе»

Тренинг Professional Scrum Master I (PSM I) Online
4 июня — 5 июня

Тренинг Professional Scrum Master I (PSM I) Online

Минск
 Туториал: новые фичи CatBoost
4 июня

Туториал: новые фичи CatBoost

Читайте также

EPAM разработал бесплатный курс по обучению детей программированию в Scratch
EPAM разработал бесплатный курс по обучению детей программированию в Scratch

EPAM разработал бесплатный курс по обучению детей программированию в Scratch

3 комментария
20 вещей, которые я вынес за 20 лет в программировании
20 вещей, которые я вынес за 20 лет в программировании

20 вещей, которые я вынес за 20 лет в программировании

Программист Schibsted Алекс Эвелёф в блоге на Medium рассказал о главных правилах и принципах, которые вывел для себя за многие годы работы в ИТ. Публикуем перевод статьи.
12 комментариев
«Зачем плодить сущности за наши деньги?» Разработчик о профсоюзах
«Зачем плодить сущности за наши деньги?» Разработчик о профсоюзах

«Зачем плодить сущности за наши деньги?» Разработчик о профсоюзах

Профсоюзная тема вызвала приступ немоты у большинства крупных ИТ-компаний Беларуси, зато нашла эмоциональный отклик у читателей dev.by. Мы предложили разработчикам высказаться о пользе и вреде профсоюзов, первым откликнулся Павел Вейник. 
13 комментариев
Мнение: концепция STEM разлагает образование
Мнение: концепция STEM разлагает образование

Мнение: концепция STEM разлагает образование

Альтернативная точка зрения про популярную концепцию от нью-йоркского писателя и сотрудника Банка Америки Джареда Вударда. Это сжатый перевод статьи, опубликованной в журнале American Affairs.
30 комментариев

Обсуждение

9

"Практически любой говнокод можно оправдать," -- как бы намекает нам Капитан.

-1

да будет срач!

6

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

2

Если вместо "говнокод" говорить "прототип", то это многое объясняет.

12

Еще не видел ни одного программиста, который, получив проект с legacy кодом не обсирал бы этот чужой код. Значит, все программисты - и говнокодеры и одновременно идеально-кодеры. А есть еще надменные личности, которые думают, что лучше других и могут всех тут лечить вроде автора этого поста.

Михаил Дубаков
Михаил Дубаков Writer в Fibery
0

Я знаю таких. Вам не повезло.

1

Эти люди познали дзен.

1

не познавал я никакой дзен и вообще в гробу видал всю эту айтишную мифологию. но, получив на переписывание чистый си 20-25ти летный давности (переписывал на с#), таки не называл это говнокодом. в нем конечно было очень трудно разбираться и у меня к нему много претензий за копипастструктуру. но это не говнокод в классическом понимании. то есть он нормально структурирован (если врубиться и знать практики 20-летней давности), решает свои задачи внятно, последовательно и логично, а не окольными путями, нормально откомментирован. в итоге, продравшись/разобравшись часто осознавал, что у меня баги в моей новой, красивой и лаконичной программе.

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

5

Пишу хороший говнокод. Хотя мир аутсорса мешает, когда продают часы, приходится писать красивый код, лепить абстракции, делать 100% покрытие тестами 100500 видов.

5

>>Что думает менеджер, когда разработчик просит у него три дня на рефакторинг? Ага, команда с азартом потратит три дня на непонятно что, не добавив в проект нового функционала.

Знаю, что таких менеджеров-гуманитариев много, но зачем с такими работать? Компаний в минске много ;-) если уж менеджер не понимает зачем нужен рефакторинг (я лично не понимаю зачем вообще нужен какой-либо даже хороший "менеджер" в принципе, но это другой вопрос). А так хороший программист всегда сам понимает где нужен хк-хк и в продакшн по быстрому (тайм ту маркет и всё вот это вот, стартапы, смузи), а где надо писать хороший, гибкий к постоянным изменениям\требованиям код.

1

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

8

А ему и не нужно понимать, ему нужно объяснить. Ну а если совсем никак, и вам приходится только добавлять костыли так, чтобы другие не вываливались - то зачем так жить? :-) Как я написал выше, компаний много, адекватных проектов и заказчиков тоже ;-). Нервы, они дороже чем лояльность к бездушному аутсорсу.

Много неадекватных заказчиков (в одном аутсорсе, помню такой был, каждый месяц задавал вопросы по отчету тайм-трекинга каждого сотрудника на его проекте типа "А почему ты потратил 4ч на задачу Х, мне кажется можно было за час сделать" (при этом он не был инженером). Много неадеватных программистов, кто-то пишет говнокод постоянно, кто-то постоянно пишет FactoryFactory там, где надо сделать прототип за день. Жизнь слишком короткая, чтобы со всеми этими людьми работать :D

1

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

4

Время на рефакторинг -- это расчет по накопившемуся техническому долгу.

0

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

0

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

0

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

Anonymous
Anonymous solutions developer в Playtika
1

>>Kод должен быть красивый, правильный, поддерживаемый, написанный по чётким и понятным критериям, начиная от правильно расставленных скобочек и заканчивая шаблонами проектирования
>>Как противовес всей этой красоте существует говнокод. Вроде как рабочий, но некрасивый, крайне непонятный, сделанный через одно место, с костылями и распорками, его тяжело поддерживать, нереально править и вообще проще переписать с нуля

На эту тему есть старый баян — https://habrahabr.ru/post/153225/

saz
saz
0

Там самое интересное - в комментариях

16

Павел, а покажите ваш код

Pavel Veinik
Pavel Veinik CTO в SplitMetrics
-3

ой ну что вы, у меня такой ужасный код, что мне стыдно его показывать :D

14

Ну статьи же не стесняетесь показывать :)

3

Буратино, программист программисту скорее что-нить из трусов достанет и покажет, чем код :))

4

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

0

1. Плохокод пишут ещё по одной причине - из-за вывернутости мозгов наизнанку, человек при этом уверен что он делает хорошо, честно стремится сделать лучше, но у него получается нечто взрывающее мозг.
2. Как уже заметили выше, хороший код выгоден в долгосрочной перспективе, конечно будущего никто не знает, но по моему впечатлению плохокод в итоге тормозит бизнес, и когда он начинает делать это объём технического долга столь велик, что нужен ИТ спецназ для её решения, а вызов таковых стоит дорого и бизнес на это не пойдёт.

8

>> разработчик просит у него три дня на рефакторинг? Ага, команда с азартом потратит три дня (а раз разработчик сказал 3, то бери шире — все 5-6)
Вот тут заржал в голос. Рефакторинг - он как ремонт: его невозможно закончить, можно только прекратить.

george
george Engineer в EIS Group
2

Срыв, блин, покровов... Но раз прочитал, поделюсь и своим опытом:

- Формализованная архитектура
- Статическое тестирование (код-ревью + линтеры)
- Джуниоров поменьше (пусть в Эпаме в лабе на кошках тренируются. Ну или если берете — то со всей ответственностью, как у Экзюпери)

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

Anonymous
Anonymous Senior Developer в EPAM
7

Сделайте мне уже кнопку 'Скрывать статьи от Павла Вейника'.
Он толстющий тролль.

3

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

Pavel Veinik
Pavel Veinik CTO в SplitMetrics
0

точно! спасибо

0

+100500
Индустрия уже давно полнёхонька персонажами, которые придерживаются вот таких вот взглядов:

И им на "все хотят писать красивый код" покласть чуть более чем полностью.

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

Павел, на ваш взгляд. Вот этот пример реализации чата в Android Activity - говнокод или нет?

2

Для большинства программистов - говнокод. Во-первых, много букаф. Во-вторых, код писали не они. :)

0

обычное легаси, если нет тестов вносить изменения или рефакторить никто не захочет
109 раз встречается слово instanceof

0

Ну писалось на конкурс, быстро-быстро и в продакшн :-) Я хз почему у многих есть мнение, что телеграм работает быстро и хорошо, как по мне, это далеко не так, особенно "хорошо".

Pavel Veinik
Pavel Veinik CTO в SplitMetrics
1

Вы бы рефакторинг Фаулера прочитайте, а потом сможете ответить сами на этот вопрос, во всех деталях ответить :)
Вот вам кратко, на случай если вы читаете только длинные классы, а не длинные книги: https://habrahabr.ru/post/169139/

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

Ну для себя у меня ответ есть, хотелось бы компетентное мнение услышать :)

Pavel Veinik
Pavel Veinik CTO в SplitMetrics
-3

Вот мнение Фаулера - намного компетентнее чем мое :)

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

Егор Павловец
Егор Павловец Project and engineering manager в ITS Partner
0

Можете ответить мне в личку, это сообщение останется строго конфеденциальным и между нами. Мне интересно знать ваше личное мнение. Проверки не причем - мы же не в школе :)

Pavel Veinik
Pavel Veinik CTO в SplitMetrics
-3

А зачем вам интересно именно мое мнение про чей-то код, даже не ваш? хм...

-1

А вот это, Павел, несерьёзно. Берётесь поговорить о гнокоде - найдите в себе смелость привести примеры и ответить на вопросы. А то выдал пару общих фраз - и в кусты.
< тут картинка "Будь мужиком, ... " >

Pavel Veinik
Pavel Veinik CTO в SplitMetrics
0

Пффф. Фаулера читайте. Я уже нашел смелость это написать, а демонстрировать вам что-то - задачи такой передо мной не стоит.

-1

Омг. Децки сад ясельная группа :)
Выдать пару общих строк - это смелость? Пойду к кофеварке, кофейку себе заварю. Я такой смелый. :)))

4

Кто-то где-то (как мне кажется умный) сказал следующее:

"Сначала ты делаешь что-то просто и плохо. Потом сложно и по-прежнему плохо. После, поднаторев, сложно и хорошо. И в конце концов ты делаешь что-то просто и гениально".

Примерно поэтому не стоит путать простое решение опытного товарища с примитивным (да пусть даже сложным) решением товарища новичка. Но учиться и пробовать что-то делать - просто, сложно - как умеешь - все равно надо.

0

Для этого и нужен CTO. Даже в самом матером аутсорсе должен быть человек который не продается напрямую, а получает зп за внутреннюю работу и следит за порядком в реализации манки-кодеров.
Тут вопрос конечно на какое количество манки нужен такой смотрящий и где их найти при масштабировании :)

3

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

1

Соглашусь с теми, кто намекает на то, что главная проблема "плохокода" (спасибо за термин, @worldmind) - это бизнес. Бизнесу надо всё побыстрее и подешевле. Тут уж не до чистоты принципов и рефакторинга. Но у бизнеса свои законы. Если не сделать быстро и дешево, то завтра продолжение проекта и его разработчики уже просто не нужны. Поэтому делаем как есть, но сегодня, запускаем проект и оборот его денег, на вырученные деньги заказываем улучшение (переделку, перекраску и т.п.)

Pavel Veinik
Pavel Veinik CTO в SplitMetrics
1

и на вырученные деньги - пилим новый проект! :D

Спасибо за комент, вы уловили на что я тоже пытаюсь намекнуть. Да, согласен, бизнес - это большая проблема для красоты кода :)

1

Решился вот добавить ещё, вдруг кто-нибудь подхватит идею. С технической, точнее математической точки зрения, идеальный код реализует собственные вектора решения на многомерной матрице контекста проекта, включающей задачу, оборудование, опыт заказчика и исполнителей и т.д. Матрица представляется очень большой, иначе задача была бы уже давно автоматизирована. Когда задача формализуется, упрощается, рефакторится - происходит приближение решения к этим собственным векторам. Но фишка в том, что каждый конкретный индивид скорее всего имеет подмножество задачи, слегка "кривые" решения и поэтому тянет проект в точку немного в стороне от математического идеала. То есть к своему "идеалу". Это объяснимо, и так бывает не только в программировании. Обобщая, это есть ограничение так называемого "ручного" проектирования. Но пока другого нет.

Pavel Veinik
Pavel Veinik CTO в SplitMetrics
1

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

Мне кажется, сейчас достаточно простых утилит, которые позволяют держать плохость кода на низком уровне, например CheckStyle для java. Нарушения простых правил отображается как ошибка в среде разработки. А решать общую проблему на матрице контекста проекта - мы можем пока только мечтать об этом.

2

Комментарий от бизнеса: не забывайте, зарплату всем платит бизнес. В бизнес- подразделениях зачастую работают далеко не дураки, которые прекрасно понимают пользу от рефакторинга в длинной перспективе. Ключевое слово- в длинной. Пока девелоперы вылизывают код- компания может остаться без средств- это касается любой компании в высококонкурентной среде. И это нормально.
Плюс требования к продукту меняются кардинально быстро, что вызывает необходимость переписывать продукт, не успев пожать плоды ох**нного кода.
Поэтому хотите и умеете писать идеальный код- космическая индустрия ждет вас, а бизнесу это часто просто не нужно и никто за это платить не будет.

Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже