Гляньте то расширение, которое разработали авторы этой статьи. Там описаны вполне измеримые количественные критерии запутанного и сложного в сопровождении кода:
В одной из книг о микросервисах была целая глава о том, когда не нужно их применять. Одним из пунктов было неумение/незнание/непонимание компанией технологий контейнеризации и оркестрации: без них работа с микросервисами быстро превратится в ад.
Интересная аналогия. В принципе, многие приемы управления разработкой в команде при должном применении делают замену или добавление новых разработчиков таким же простым и предсказуемым процессом, как добавление нового элемента к батарее.
Все эти пункты указывают на серьезные проблемы с архитектурой.
Меньше слоев и меньше абстракций — выше зацепление, сложнее сопровождение, труднее изолировать изменения при рефакторинге. Абстракции на то и абстракции, что их не нужно сопровождать — это ведь не детали реализации, а лишь контракты и интерфейсы.
Тест, завязанный на детали реализации — плохой тест, он бесполезен при рефакторинге, так как просто дублирует эти детали и отправляется на помойку при их изменении.
Система, которую проще протестить целиком (а обычно "проще" означает "а никаким другим способом ее и не протестишь"), называется Big Ball of Mud.
Инструмент используют люди. А люди устают, ошибаются, ленятся, срезают углы, забывают и т.п. Всегда. Если инструмент не учитывает эти особенности людей (а Си — хрестомайтийный пример подобного инструмента) — конец немного предсказуем.
Разработчики, чьи приложения выступают как клиенты библиотек шифрования (то есть только используют шифрование, а не реализуют его), в любом случае не знают и не должны знать деталей внутренней реализации и причин уязвимости этих библиотек. Задача таких разработчиков — подключить стороннюю библиотеку и зашифровать свои данные с ее помощью, вот и все. По вашей логике все, что непонятно вам лично и не может быть непосредственно вами проверено (а это большинство систем в мире), вы считаете небезопасным?
Есть еще часто неосознаваемая некомпетентность, сталкивался на своем собственном опыте множество раз. Это когда смотришь на код, написанный тобой же год назад, и понимаешь, что так больше не пишешь, никогда писать не будешь, а если увидишь у кого-то из коллег — объяснишь, почему так писать нельзя. А ведь год назад считал, что крут, и гордился этим кодом, вот поди ж ты.
По сути, это отдельный проект, который только выглядит как реальный, но таковым не является. Иногда хватает презентации мокапов дизайна, даже без реально работающего прототипа.
Если руководство ставит приоритетом скорость запила новых фич и насаждает культуру пренебрежения к качеству кода (это все теории, а на практике у нас все не так), то это подобно тому, как гонять таксомотор, перевыполняя норму по заказам, но не заботясь о ТО и амортизации. Рано или поздно (скорее рано) таксомотор загнется, и зарабатывать заказами станет не на чем. Метафора кредита в статье тоже очень хороша: не имеет значения, как быстро и как легком вы можете получить новый кредит, если необходимость выплаты прошлых кредитов уже сделала вас банкротом.
На место выкупленного конкурента всегда может прийти новый, у которого процесс разработки поставлен как надо, и уделает монополиста, потому что он будет быстрее внедрять фичи, выпускать релизы с меньшим количеством багов, легче находить разработчиков в команду и т.п… Такой сценарий тоже возможен, хотя, конечно, надо смотреть на конкретный рынок и конкретный продукт.
Вам уже выше ответили — написание качественного кода и использование best practices не меняет качественно затраты. Конечно, при условии, что вы не пытаетесь внедрить их на проекте, где их невозможно внедрить. Если у вас огромный legacy-монстр, где компонент А зависит от Б, Б от В, В от Г, и все прибито гвоздями, а вы пытаетесь протестить компонент А юнит-тестом — тогда, согласен на 150%, вас ждет боль, много боли, и много затрат, и потеря огромного количества времени. Но причина этого в данном случае не в правильном подходе, который дорог, а в том, что вы не использовали его с самого начала и написали нетестируемое, негибкое, нерасширяемое нечто.
Можно сделать быстро, но плохо, а можно — медленно, но хорошо. Через некоторое время все забудут, что было быстро, но будут помнить, что было плохо. И наоборот.
Вы забываете о том, что после захвата рынка у вас, скорее всего, не будет уже ни времени, ни денег на его исправление. Будут другие задачи и другие затраты. И для их реализации вам придется говнокодить дальше, потому что архитектура обязывает. Ком технического долга будет только расти и расти, разработка новых фич будет становиться сложнее и сложнее, цена ошибочных решений все выше и выше, пока ваш проект не загниет окончательно.
Согласен со статьей, обычно выбирают тактический выигрыш, но получают стратегический проигрыш. Экономят сегодня, чтобы потратить гораздо больше завтра.
По моему скромному опыту могу сказать, что написание качественного кода отнюдь не настолько сильно отличается от говнокода по затратам времени и денег. Тесты экономят время на отладке и сильно ускоряют саму разработку. Создание абстракций, продумывание контрактов и DI практически ничего не стоят, но повышают тестируемость и снижают зацепление частей системы, что сильно увеличивает скорость внедрения новых фич.
И наоборот, затраты на перелопачивание говнокода обычно очень сильно недооцениваются:
во-первых, это чаще всего делают не те, кто этот говнокод написал, да и кто признается, что написал Big Ball of Mud, который проще переписать с нуля, чем переделать?
во-вторых, работа с легаси — непрестижный и неблагодарный труд, об этом статьи обычно не пишут; книг про работу с legacy — раз-два, и обчелся, зато про новые технологии выходят каждый месяц по несколько;
при перелопачивании плохого кода никакой ценности для пользователей в продукт не добавляется, это чистые расходы времени команды и денег фирмы;
затраты на переписывание обычно выше, чем на то, чтобы сразу сделать хорошо: приходится думать об обратной совместимости (не сломать API, оставить тот же UX и т.п.) и исправлять возникающие регрессии; надо ли говорить, что раз на тестах сэкономили, то значит, баги можно выловить только ручным тестированием или на продакшне?
В общем, чаще всего причины ситуации — обычные лень, невежество и неуважение к времени других разработчиков и деньгам работодателя, а вовсе не радение об экономии или поиск компромисса. Компромисс можно искать, если вы знаете и понимаете альтернативы. Если вы умеете писать только говнокод и не понимаете плюсы и минусы альтернативных подходов — не надо искать себе и своему продукту оправданий.
Полюбопытствуйте
Вы ведь статью прочитали полностью?
Все эти пункты указывают на серьезные проблемы с архитектурой.
Меньше слоев и меньше абстракций — выше зацепление, сложнее сопровождение, труднее изолировать изменения при рефакторинге. Абстракции на то и абстракции, что их не нужно сопровождать — это ведь не детали реализации, а лишь контракты и интерфейсы.
Тест, завязанный на детали реализации — плохой тест, он бесполезен при рефакторинге, так как просто дублирует эти детали и отправляется на помойку при их изменении.
Система, которую проще протестить целиком (а обычно "проще" означает "а никаким другим способом ее и не протестишь"), называется Big Ball of Mud.
В комментариях к оригинальной статье автору советуют использовать enum для подобных случаев: https://dev.to/lexlohr/comment/d831
C. П. Королев
По моему скромному опыту могу сказать, что написание качественного кода отнюдь не настолько сильно отличается от говнокода по затратам времени и денег. Тесты экономят время на отладке и сильно ускоряют саму разработку. Создание абстракций, продумывание контрактов и DI практически ничего не стоят, но повышают тестируемость и снижают зацепление частей системы, что сильно увеличивает скорость внедрения новых фич.
И наоборот, затраты на перелопачивание говнокода обычно очень сильно недооцениваются:
В общем, чаще всего причины ситуации — обычные лень, невежество и неуважение к времени других разработчиков и деньгам работодателя, а вовсе не радение об экономии или поиск компромисса. Компромисс можно искать, если вы знаете и понимаете альтернативы. Если вы умеете писать только говнокод и не понимаете плюсы и минусы альтернативных подходов — не надо искать себе и своему продукту оправданий.