Вы заметили, что все информационные системы имеют тенденцию к разрастанию? Не будем обсуждать хорошо это или плохо (это – плохо!), но разрастание системы означает и разрастание кодовой базы.
Некоторые из нас пробовали время от времени предлагать руководителю проекта (владельцу продукта, собственнику бизнеса и т.п.) что-то из системы удалить и обычно это заканчивается тем, что сейчас надо срочно молотить в закрома Родины, а удалим ненужный код когда-нибудь потом, когда будет возможность. Нет, не удалим… Пару раз получив такой ответ и не увидев результата, человек перестает спрашивать. У тех, кто любит порядок, душа продолжает болеть по этому поводу, но уже молча, а нормальные люди просто принимают эту ситуацию как норму и свыкаются.
И это плохо, потому что живая, развивающаяся система похожа на живой же организм и отходы должны выводиться из системы, чтобы она оставалась здоровой.
Важно понимать, что в этой заметке мы будем говорить про удаление ненужного кода, но программисты его и так удалят без всякой санкции, если это удаление не будет видно внешне. Когда мы говорим «удаление кода», надо понимать это как «удаление фичи», что уже не может быть сделано самими программистами, а требует санкции руководства. И отсутствие этой санкции – как раз та проблематика, что мы здесь обсуждаем.
Я – владелец бюджета, и я не понимаю, зачем тратить деньги на удаление кода!
Совершенно нормальный вопрос от человека, который распоряжается бюджетом и код видел разве что на экране подчиненного программиста. Он искренне не понимает, зачем в это инвестировать.
Вот несколько ошибок, которым может быть подвержен этот человек:
Не понимаю, почему нужно тратить ресурсы на удаление мертвого кода. Лежит себе и не мешает.
Ошибка – мешает. Существует несколько степеней ненужного кода:
Код есть, код работает правильно, код постоянно тестируется перед релизом, но никем не используется на проде.
Код есть, код работает правильно, но тестировать перестали без ведома руководителя, за очевидной бессмысленностью этой работы.
Код есть, код не работает вообще, сломан, но он хотя бы компилируется, чтобы пайплайн сборки не краснел.
Кода нет, точнее он есть, но весь закомментирован. «Код» компилируется в какой-то бессмысленный бинарник, который просто лежит и никем даже не скачивается.
Кода нет, файлов нет, бинарников нет, всё молча удалено уже давно инженерами, которые устали поддерживать ненужное, но руководители этого не знают, и думают, что всё в порядке.
Вы же знаете, что ненужные для выживания гены живых существ накапливают мутации и выходят из строя? Не знаете? Спросите геном кишечных паразитов.
Невостребованный код также неизбежно деградирует в указанном выше направлении, так как на него не действует естественный отбор со стороны хищников пользователей.
Если внимательно перечитать список выше, то станет понятно, что затрат на поддержку ненужного кода очень много – на тестирование, на поддержку работоспособности, на поддержку компилируемости и так далее.
Ненужный код всё равно придет к последнему состоянию (несуществования) естественным путём, так ускорьте этот процесс и сэкономьте ресурсы!
Удаление не несет профита, а лишь только довольство программистов, но тут работа, а не отпуск, гоните нетленку в git, а довольство оставьте у входа в офис!
Ошибка – удаление сокращает затраты, как было показано выше.
Но затраты – не единственное, о чем следует беспокоиться бизнесу. То самое довольство (удовлетворение от работы) программистов (и вообще – всей команды разработки) важно, так как опытный участник проекта работает в несколько раз эффективнее специалиста такой же квалификации, но только пришедшего на проект. Если инженер предлагает что-то удалить, то стоит рассмотреть этот запрос внимательно.
Заботьтесь о своих инженерах, а они позаботятся о Вашем продукте. В этом еще один профит.
Ценность в коде! Удалять код – удалять ценность.
Ошибка – ценность в решение проблем (пользователя и других). Если код не решает никаких проблем, это не ценность, а балласт. Если вы можете решить проблему пользователя, не написав вообще никакой код, вероятно, стоит это сделать
Вообще, решать проблемы методом кодирования (и поддержки этого кода потом) – очень дорогой способ решения проблем. Программисты – звери редкие, дорогие, как и токены LLM. Их надо использовать тогда, когда более дешевого решения нет.
Но, как было показано выше, ненужный код несет затраты и не дает ценности. Так зачем он нужен, удалите его и почистите систему.
Ладно, давайте удалять. Когда нужно удалять и в каком объеме?
Совершенно понятно, что небольшой объем неиспользуемого кода не несет проблем. Если у вас 1% кода, который никому не нужен, возможно, вам и не надо ничего предпринимать. Но если у вас 30% ненужного кода, то это уже явная болезнь. Да, такое бывает на многолетних энтерпрайз-проектах. Таким образом, сначала надо определить масштаб проблемы, и уже потом решать, что с ней делать или не делать ничего.
Надо ли удалять сразу после того, как стало ясно, что код невостребован? Если вам это ясно, то чего ждать? Код не пропадет навсегда, а останется в истории git, если что (частая тревога у людей) – его можно вернуть. С другой стороны, если вы отложите удаление на несколько месяцев, тоже не произойдет ничего страшного, но тревога уляжется. Главное не откладывать на год и более.
Как определить ненужный код?
Это делается легко. Несомненно, ваши «боевые» системы мониторятся, так извлекайте из этой системы мониторинга ту информацию, которая нужна для определения какой процент пользов��телей какую фичу использует.
Например, у вас в системе 200 отчетов для пользователей, которые писались в течение 15 лет. Вы должны видеть, какие из них вызываются, а какие – нет. Поддержка ненужных отчетов – очень существенные затраты и лучше ненужные отчеты удалить.
Если некая фича не используется никем, или используется так редко, что нет смысла ее поддерживать – удаляйте её. Вам, как руководителю проекта, не надо ставить задачу в терминах кода, ставьте задачу на удаление в терминах фичи: «удалить отчет Х, так как он никем не используется уже N месяцев».
Дополнительные трудности возникают, если вы поддерживаете и разрабатываете систему вдолгую, но не для себя, а для стороннего заказчика. Как быть в этой ситуации? И вы и команда заказчика, должна понимать всё, что написано выше, что мертвый код – это деньги на ветер. Тогда вы, как команда-разработчик, должны доносить до заказчика предложения по удалению чего-то, а заказчик должен официально ставить задачу на удаление фичи (и оплачивать эту работу). Такое бывает редко.
Все эти размышления устарели, теперь код будет писать ИИ, а у него большой контекст
Очень модное возражение в наше время. Три раза ха! Если Ваш код пишет ИИ, то бегите глупцы вам тем более надо удалять ненужный код. Вы же не хотите тратить токены на поддержку мертвого кода в рабочем состоянии?
Второй аспект: несмотря на увеличение контекстного окна LLM, оно всё же не бесконечно. Лучше загрузить окно ценным кодом, чем мертвым, потому что качество генерации нового кода явно зависит от кода в контексте.
Таким образом, LLM в этом вопросе ничего принципиально не меняет.
Заключение
Каждый менеджер решает сам, где поставить запятую во фразе «удалять нельзя добавлять». Всегда нужен здоровый баланс, и мнение «ничего не удаляем, всё – ценное» однозначно находится за пределами этого баланса. Удачи в управлении кодовой базой!
