Почему код может становиться хуже бесконечно: нет предела деградации
There's No Limit to How Bad Code Can Get
Автор, бывший инженер Amazon, разбирает метафоры «тонущего корабля» и «рушащегося здания» применительно к кодовым базам. Он утверждает, что бизнес умирает задолго до того, как код достигнет «дна», а технический долг не имеет аналога банкротства. На примере своего опыта в Amazon он показывает, как попытки переписать архитектуру проваливаются, а код продолжает деградировать бесконечно. Единственный способ поддерживать качество — постоянные усилия, а не надежда на «перезагрузку».
Программное обеспечение находится в области абстрактного. Оно не похоже на здание или мост, которые находятся в физическом мире, где вы можете видеть и чувствовать природу вещи. Если вы будете бесконечно добавлять этажи и комнаты к зданию, оно рухнет. У программного обеспечения нет такого ограничения. Код может всегда стать хуже. Всегда может появиться новый уровень косвенности или снижение производительности.
- ChrisMarshallNY
Одна из моих первых работ была должностью инженера по сопровождению кодовой базы объёмом более 100 000 строк на FORTRAN IV образца 1970-х годов.
Никаких комментариев.
Никаких подпрограмм (того, что мы сейчас называем «функциями»).
Ни одно имя переменной не было длиннее 4 символов.
Весело. Самым эффективным инструментом отладки была доска для спиритических сеансов. Она сделала меня экспертом по гаданию.
Именно поэтому я сейчас так зациклен на качестве кода. Я никогда не хочу подвергать этому кого-либо ещё.
Кстати: с современными LLM нет никаких оправданий для плохо документированного или плохо отформатированного кода. Можно написать тысячу строк коммерческой «лапши» и попросить LLM отформатировать и задокументировать её.
- lukasgelbmann
Познавательная статья. Автор приводит отличные аргументы о динамике технического долга в организациях.
Я думаю, что тонущий корабль — довольно удачная метафора, хотя затонувший корабль — это ужасный, страшный исход.
В этой метафоре кодовая база считается затонувшей, когда её дальнейшее использование становится нецелесообразным. Организация перестаёт над ней работать и больше её не запускает. В этот момент код становится совершенно бесполезным для бизнеса, как корабль на дне океана. Теоретически можно представить, что код ухудшается и дальше. Но на практике он просто останется лежать и гнить.[0] Бизнес может попытаться переписать его или просто прекратить выпуск продукта.
Возможно, но не обязательно, что бизнес утонет вместе с одной из своих кодовых баз. Это может произойти и с кораблём, если бизнес сильно зависит от него.
- blevinstein
> У технического долга нет банкротства, нет чистого сброса
Определённо существует вариант банкротства технического долга.
Можно перестать использовать конкретный фрагмент кода или технологию, например, заменив его (новым кодом, сторонним или вендорским решением) или перепроектировав систему или бизнес-процесс так, чтобы функция кода больше не требовалась.
Именно это и означает метафора технического долга. Недолговечные системы могут накопить много технического долга без особых опасений, потому что вы планируете вскоре объявить банкротство (устаревание и вывод из эксплуатации); долгоживущие системы должны планировать выплату технического долга обычными платежами в рассрочку.
- socalgal2
Две вещи
1. По моему опыту, LLM может это исправить. LLM, особенно более современные, обладают гораздо большей кратковременной памятью, чем большинство людей (или, по крайней мере, чем я). Они могут копаться в таком коде, выявлять все крайние случаи, писать тесты, предлагать различные пути улучшения и затем реализовывать их. По запросу они с радостью настроят dev-системы, staging-системы и всё, что нужно для безопасного перехода. По крайней мере, таков мой опыт. Они могут копать гораздо глубже, чем я когда-либо стал бы.
2. Если не считать исправления с помощью LLM, этот паттерн технического долга, я думаю, почти неизбежен, по крайней мере, с участием людей. В идеальном мире каждый человек и каждый рецензент точно знает, какую архитектуру писать и какие тесты нужны, чтобы передать все правила и допущения, потому что, что бы ни случилось, люди будут уходить. Но я никогда не видел такой кодовой базы. Поэтому правила и допущения в лучшем случае записаны наполовину, возможно, в комментариях или документации, которые следующий человек, редактирующий эту часть кода, может увидеть, а может и нет. И так далее.
Я работаю с кодовой базой, которая работает на Windows, Mac, Linux, Android, iOS. Эти ОС меняются со временем, меняются их требования, меняются их API, мир меняется, и для новых действий людей нужны новые API, а наши первоначальные решения для кроссплатформенной разработки больше не подходят идеально. Нам нужно продолжать двигаться и выпускать релизы, и мы не можем просто остановить мир и перепроектировать всё. Кроме того, как и автор поста, не все […]
- cebert
Если вы когда-либо работали с дешёвыми оффшорными подрядчиками, вы знаете, что это правда…