"Программное обеспечение пожирает мир". В своей знаменитой статье, написанной в 2011 году, Марк Андриссен написал, что «мы находимся в середине драматического и широкого технологического и экономического сдвига, в ходе которого компании-разработчики программного обеспечения готовы захватить большую часть экономики». Он ожидал, что программное обеспечение изменит многие другие отрасли, и оказался прав. С недавними прорывами в области ИИ мы еще не видели конца всех сбоев.

Марк Андриссен выступал за более крупные инвестиции в программное обеспечение, признавая полученную ценность для бизнеса. Хотя бизнес-преимущества программных решений часто признаются, создание программного обеспечения обходится дорого. Создание каждых 5-10 тысяч строк кода стоит примерно 1 FTE. Среднее приложение для iPhone легко занимает ~10–50 тысяч строк кода, современный автомобиль использует 100 миллионов строк кода (источник: размеры кода).

Программное обеспечение также дорого стоит. Даже если нет необходимости изменять функциональность, среда исходного программного обеспечения подвержена постоянным изменениям. Новые операционные системы ломают функциональность, которая отлично работала годами. Новое оборудование, даже с теми же функциями, требует от разработчиков программного обеспечения установки новых драйверов. При наличии новых способов нарушения безопасности части программного обеспечения необходимо переписывать, чтобы сделать его безопасным. По моему опыту, каждые 50-200 тысяч строк кода требуют примерно 1 FTE обслуживания ежегодно.

Если у вас есть команда из 10 FTE, создающая от 50 000 до 100 000 LOC в год, вы также создали постоянную потребность поддерживать этот код в течение всего срока службы этого программного обеспечения. Первый год команда работает суперпродуктивно. На 2-м году им нужно часть своего времени для поддержки кода, который они создали в первый год 1 и так далее. Если вы предполагаете, что обслуживание зависит от размера кода, скорость ваших инноваций упадет до нуля!

Есть несколько факторов, которые делают размер вашего кода больше, чем необходимо:

  • Перепроизводство. Некоторые инженеры более многословны, чем другие. Для создания лаконичного программного обеспечения требуются навыки, время и анализ. Как сказал Марк Твен: «У меня не было времени написать короткое письмо, поэтому вместо этого я написал длинное».
  • Чрезмерная абстракция: инженеры-программисты могут «чрезмерно абстрагироваться», например. создавайте код с широкими возможностями настройки или создавайте фреймворки для повторного использования в будущих сценариях использования. Хотя это может быть реальным бизнес-требованием, часто это не требуется для удовлетворения бизнес-потребностей. Код, который необходимо настроить или повторно использовать, более подробный, чем код, адаптированный для конкретного использования.
  • Излишняя обработка. Архитектуры, основанные на событиях/асинхронные, более подробные, чем синхронные архитектуры. Не все проблемы реального мира требуют асинхронной архитектуры, и я считаю, что шаблон используется слишком часто. Кроме того, асинхронные архитектуры могут генерировать ненужную динамику во время выполнения, создавая дорогостоящие и труднодиагностируемые проблемы с качеством.
  • Чрезмерное количество ветвей. Давление со стороны бизнеса всегда велико, и многим проектным группам необходимо улучшать один и тот же код одновременно, чтобы одновременно уложиться в срок. Итак: что просит руководитель проекта? Независимость! Мне нужна собственная ветка, и мне это нужно сейчас! Конечно, это приводит к накладным расходам на слияние. Слияния дороги и сложны. Разделение, вероятно, создало необходимость поддержки большего количества вариантов продукта. И есть большая вероятность, что код в разных ветвях, созданный изолированно, будет более раздутым, чем целостный.

По прошествии лет не все требования, которые команда изначально должна была реализовать, по-прежнему требуются. Программные технологии, которые когда-то были горячими и новыми, теперь устарели, а новые парадигмы позволяют выразить функциональность более лаконично. Часто программные стеки содержат слои абстракции, утратившие свою ценность. В результате большинство кодовых баз намного больше, чем необходимо. Я привел примеры раздутого, но работоспособного кода. Также возможно, что стек кода содержит код, который больше не используется (мертвый код). На первый взгляд безобидное повторное использование мертвого кода в новом контексте может иметь существенные негативные последствия для бизнеса. Для примера прочтите это интервью с Кевлином Хенни, который утверждает, что мертвый код нужно найти и удалить.

Чем больше у вас кода, тем больше у вас ошибок. Это не масштабируется линейным образом. Если вы удваиваете код, вы более чем удваиваете количество ошибок. Конечным результатом написания слишком большого количества кода является то, что вы тратите больше времени на обслуживание, чем необходимо, и не даете заинтересованным сторонам достаточно того, что им нужно.

Как разорвать негативную спираль? Первый шаг — осознать важность контроля размера вашего кода. Вам нужно внедрить это в культуру команды. Создание культуры «минималистического кода» позволит вашим командам контролировать свою кодовую базу. Они могут обнаружить неожиданное увеличение размера кода и бросить себе вызов в поиске возможностей для его уменьшения. Постановка собственных целей будет стимулировать команды находить и удалять мёртвый код там, где это возможно.

Для больших размеров кода это многолетняя работа. Но начало путешествия может сэкономить много ЭПЗ на техобслуживании. Вот некоторые из известных мне методов уменьшения размера устаревшего кода:

  • Начинается с просьбы. Большинство инженеров-программистов хорошо чувствуют, когда стек кода раздут.
  • Измерьте свои требования и протестируйте покрытие. Тестирование вашего кода — это первый шаг к уверенному уменьшению размера кода.
  • Восстановление моделей из устаревшего кода. Прочтите это интервью с Арджаном Муи из TNO ESIj, чтобы узнать больше.
  • Повысьте выразительность кода: используйте языки, специфичные для предметной области (где это применимо), чтобы выразить свои намерения наиболее кратким образом.
  • Используйте инструменты разработки программного обеспечения на основе моделей, такие как Verum’s dezyne.

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

  • потому что вам нужна скорость инноваций
  • потому что вам нужно повысить качество кода
  • потому что нужна здоровая инженерная культура

Пожалуйста, дайте мне знать об успешных способах, которые вы использовали для уменьшения стека кода!