„Софтуерът изяжда света“. В известната си статия, написана през 2011 г., Марк Андреесен пише, че „ние сме в средата на драматична и широка технологична и икономическа промяна, в която софтуерните компании са готови да поемат големи части от икономиката“. Той очакваше много повече индустрии да бъдат нарушени от софтуера и се оказа прав. С неотдавнашните пробиви в AI не сме видели края на всички прекъсвания.

Марк Андреесен се аргументира в полза на по-сериозни инвестиции в софтуер, като признава доставената бизнес стойност. Въпреки че бизнес ползите от софтуерните решения често се признават, създаването на софтуер е скъпо. Създаването на всеки 5K до 10K реда код струва приблизително 1 FTE. Средно приложение за iphone лесно приема ~10–50K реда код, модерна кола използва 100M реда код (източник: кодови базови размери).

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

Ако имате екип от 10 FTE, създаващ между 50K и 100K LOC на година, вие също сте създали повтарящата се нужда да поддържате този код през целия живот на този софтуер. Първата година екипът е супер продуктивен. Втората година те се нуждаят от част от времето си, за да поддържат кода, който са създали през първата година 1 и т.н. Ако приемете, че поддръжката е функция на размера на кода, скоростта на иновациите ви ще достигне нула!

Има няколко фактора, които правят размера на вашия код по-голям от необходимия:

  • Свръхпроизводство: Някои инженери са по-многословни от други. Необходими са умения, време и преглед, за да създадете кратък софтуер. Както е казал Марк Твен: „Нямах време да напиша кратко писмо, затова вместо това написах дълго“.
  • Прекалено абстрактно: Софтуерните инженери могат да „прекалено абстрактно“, напр. създайте код, който е много конфигурируем или създайте рамки за повторна употреба за бъдещи случаи на употреба. Въпреки че това може да бъде реално бизнес изискване, често не е необходимо да се отговори на бизнес нуждите. Кодът, който трябва да бъде конфигуриран или повторно използван, е по-подробен от кода, пригоден за конкретна употреба.
  • Прекомерна обработка: Базираните на събития/асинхронните архитектури са по-подробни от синхронната архитектура. Не всички проблеми в реалния свят изискват асинхронна архитектура и вярвам, че моделът се използва прекалено много. Освен това асинхронните архитектури могат да генерират ненужна динамика на времето на изпълнение, създавайки скъпи и трудни за диагностициране проблеми с качеството.
  • Прекомерно разклоняване:Бизнес натискът винаги е висок и много екипи по проекти трябва да подобрят един и същ код едновременно, за да спазят крайния срок по едно и също време. И така: какво иска ръководителят на проекта? Независимост! Имам нужда от собствен клон и имам нужда от него сега! Разбира се, това въвежда допълнителни разходи за сливане. Сливанията са скъпи и сложни. Разделянето вероятно е създало необходимостта от поддръжка на повече продуктови варианти. И има голям шанс кодът в различните клонове, когато е създаден изолирано, да е по-раздут, отколкото когато е проектиран холистично.

С течение на годините не всички изисквания, които екипът първоначално беше помолен да изпълни, все още са необходими. Софтуерните технологии, които някога бяха „горещи и нови“, сега са остарели, а новите парадигми ви позволяват да изразите функционалността по по-сбит начин. Често софтуерните стекове съдържат абстракционни слоеве, които са загубили своята стойност. В резултат на това повечето кодови бази са много по-големи от необходимото. Дадох примери за код, който е раздут, но все още функционира. Възможно е също кодовият стек да съдържа код, който вече изобщо не се използва (мъртъв код). Въпреки че изглежда безобидно, повторното използване на мъртъв код в нов контекст може да има значителни неблагоприятни бизнес ефекти. За пример прочетете това интервю с Кевлин Хени, който твърди, че мъртвият код трябва да бъде намерен и премахнат.

Колкото повече код имате, толкова повече грешки имате. Това не се мащабира по линеен начин. Ако удвоите кода, вие повече от удвоявате грешките. Крайният ефект от писането на твърде много код е, че отделяте повече време за поддръжка от необходимото и не давате на заинтересованите страни достатъчно от това, от което се нуждаят.

Как да прекъснем негативната спирала? Първата стъпка е да осъзнаете важността на наблюдението на размера на вашия код. Трябва да вградите това в екипната култура. Установяването на култура на „минималистичен код“ ще запази вашите екипи в контрола върху тяхната кодова база. Те могат да забележат неочаквани увеличения на размера на кода и да се предизвикат в намирането на възможности за намаляване. Поставянето на собствени цели ще стимулира екипите да намират и премахват мъртъв код, където е възможно.

За по-големи размери на кода това е многогодишно начинание. Но започването на пътуването може да спести много FTE от поддръжка. Ето някои от методите, които видях, че успяват да намалят размера на наследения код:

  • Започва се с питане. Повечето софтуерни инженери имат добър усет къде кодовият стек е раздут.
  • Измерете вашите изисквания и тествайте покритието. Тестването на вашия код е първата стъпка към увереното намаляване на размера на кода.
  • Възстановяване на модели от наследен код. Прочетете това интервю с Arjan Mooij от TNO ESI, за да научите повече.
  • Увеличете изразителната сила на кода: Използвайте специфични за домейна езици (където е приложимо), за да изразите намерението си по най-сбития начин.
  • Използвайте управлявани от модели инструменти за софтуерно инженерство като Dezyne на Verum

Софтуерът изяжда света. Но поддържането на наследена софтуерна кодова база, която е по-голяма от необходимото, намалява скоростта на иновациите ви.Нуждаете се от цел за намаляване на размера на кода за вашия екип!

  • защото имате нужда от скоростта на иновациите
  • защото имате нужда от повишаване на качеството на кода
  • защото имате нужда от здравословна инженерна култура

Моля, уведомете ме за успешни начини, които сте използвали за намаляване на стека от кодове!