Нашел объяснение, когда чистый код нужен и когда без него можно обойтись
Когда программист решает одноразовую задачу, то тратить время на обдумывание архитектуры и писать чистый код смысла нет. Накладные расходы превышают пользу. Нашел подходящее место для изменения и говнокодишь. Принцип «и так сойдет» подходит для одноразовых задач. Не берем в расчет автоматизацию систем критически важной инфраструктуры, работа которой может повлиять на жизнь и здоровье людей и окружающей среды. 1Сники с такими проектами не сталкиваются.
Когда программист автоматизирует условно-постоянные процессы, то чистый код тоже не нужен. Пример таких процессов: работа завхоза, работа с архивом. Это второстепенные процессы для бизнеса. Второстепенные процессы меняются медленно. Процесс изменится лет через пять и тогда проще автоматизировать процесс с нуля на современном стеке.
Автоматизацию условно-изменяемых процессов опасно делать на говнокоде. К таким процессам относятся: продажи, производство, ремонты. Заказчик собирает большой бэклог хотелок для условно-изменяемых процессов. Программист знает какие будут изменения, какие блоки связаны друг с другом. Заказчик меняет требования каждый месяц, неделю, день. Бизнес меняется, чтобы конкурировать в быстро меняющемся мире. Говнокодить в этом случае тоже можно, но постепенно вносить изменения становится сложнее и сложнее. Меняешь учет продаж, а отваливается учет ремонтов.
Программист на конференциях слышит, что в 1С подвезли тесты. Честно осваивает сценарное тестирование, но это долго, дорого и не факт, что покрываешь все сценарии. Менять код по-прежнему страшно. Программист узнает о юнит тестах. Юнит тесты писать быстрее, но лапшичный код препятствует внедрению юнит тестирования. Программист не применял паттерны, не понимает, что такое программный интерфейс, не знает принцип открытости/закрытости, не применяет инверсию зависимости, а бизнес логика намешана с получением данных. Программист на проекте не один. Команда ненавидит хранилище, ругаются, что кто-то долго занимает модуль. Проблема не в хранилище, а в коде. Команда написала сильно зацепленный код, нарушающий принцип единственной ответственности.
Часто команда собирается и выносит вердикт: «Давайте перепишем базу с нуля». Бизнес не идет на такую авантюру. Почему-то парни в костюмах знают, что команда через пару лет повторит успех. Придет новый лид и снова скажет: «Все говно, переписываем с нуля». А если бы команда писала чистый код и инвестировала время в чистую архитектуру, то переписывать с нуля не пришлось бы.
Верные рассуждения? Что думаете? Кто сколько раз переписывал с нуля и получал такой же результат?
