Техническият дълг е като заем. Колкото по-дълго отлагате връщането му, толкова повече лихва плащате

Как да се справим с техническия дълг в Scrum

Техническият дълг е едно от най-големите смущения и демотиватори на екипите за развитие, с които работя. Екипите обикновено нямат затруднения да извикват примери за технически дълг в своята кодова база. Преки пътища в кода, нискокачествен код, временни, но не-истински решения и други хакове, които могат да решат краткосрочни решения, но гарантират дългосрочна болка. Екипите за развитие често са наясно с натрупването на технически дълг, но се чувстват безсилни и не могат да обяснят защо техническият дълг трябва да бъде приоритет. Вместо това те смятат, че „бизнесът продължава да добавя повече функции, отколкото да стабилизира фондацията“.

В тази публикация предлагам четири практически съвета как да направим прозрачния технически дълг и как да помогнем на бизнеса да постигне по-добро компромис между качеството на кода и новите функции:

1. Използвайте мощни метафори

„Технически дълг“ е мощна метафора. Използвайте го като такъв. Последиците от писането на хакове и обкръжения, които „помагат ни сега, но ни нараняват по-късно“, са много абстрактни и неразбираеми за хората, които сами не са разработчици. Просто им липсва полезен умствен модел. Непрекъснато подчертаването, че „X трябва да се подобри“ или „Y е лош код“ няма да създаде разбиране. Всъщност това вероятно ще ви постави в полето „човек, който винаги се оплаква“.

Метафорите са мощни инструменти за създаване на разбиране. Самият „технически дълг“ е такава метафора. Първоначално създаден от Уорд Канингам и допълнително разширен от Мартин Фаулър, той приравнява писането на код с ниско качество с възникване на финансов дълг. Когато кодът с ниско качество е написан с обещанието да го подобрите по-късно, възниква технически дълг с обещанието да го изплатите по-късно. Но гадното за дълговете е, че трябва да плащаш лихва. И колкото по-голям е дългът, толкова по-големи са лихвите. Докато не откриете, че прекарвате цялото си време, занимавайки се с лихвите. В случай на технически дълг, лихвата представлява времето, изразходвано (или по-точно: пропиляно) за справяне с последствията от възникналия технически дълг. Подобно на бъгове, код, който е трудно да се разбере и / или промени, код, който лесно се нарушава и рискува сигурността. Понякога сме добре с някакъв технически дълг и произтичащия от това интерес, но по-често не сме. Следващата визуализация обяснява техническия дълг и още по-сериозно последствията:

2. Поемете отговорност като разработчици

Някои екипи за разработка се чувстват жертва на начина, по който „бизнесът“ продължава да дава приоритет на новите функции пред подобряването на кодовата база, докато от друга страна ги държи отговорни за грешки, неработещ код и резултатите от техническия дълг. Екипът за развитие не може да направи право.

Важна стъпка е да спрете да се държите като жертва. Поемете отговорност за (поддържане или подобряване) на качеството на кода като екип. Това неслучайно е силно подчертано от Ръководството за Scrum. Използвайте съветите в тази публикация, за да поставите „техническия дълг“ на дневен ред и да го направите прозрачен. Върнете се назад, когато като екип усетите, че качеството на кода е опасно жертва в полза на добавянето на повече функции. Уверете се, че всички оценки, които екипът генерира, включват работата, която е необходима за писане на код с достатъчно качество. При необходимост разширете Определението на готово с аспекти, свързани с борбата с техническия дълг (напр. „Покритието на кода трябва поне да остане стабилно, когато се добавят нови функции“ или „кодът трябва да бъде в съответствие с нашите правила за кодиране“). Винаги правете технически дълг част от диалога със Собственика на продукта и с по-широкия бизнес. Но направете това категорично.

3. Използвайте кодовите показатели за количествено определяне на техническия дълг

Метриките предлагат прекрасна възможност да се направи нещо субективно и абстрактно по-обективно и осезаемо. Той също така ви дава измерима цел, която да подобрите. Няколко показатели, които са полезни и широко достъпни:

  • Цикломатична сложност: този показател количествено определя сложността на класовете и методите, като анализира броя на функционалните пътища в кода (ако / след това / друго, превключвател / случай и т.н.) в сравнение с използваните редове на код. Колкото по-висока е цикломатичната сложност, толкова по-труден код ще бъде поддържането;
  • Покритие на кода: липсата на единични тестове е източник на технически дълг. Повечето IDE и CI сървъри могат да изчислят количеството код, обхванато от единичните тестове. Добро правило е да се уверите, че покритието остава поне същото, когато се добави нов код;
  • SQALE-рейтинг: показател, който предлага широка оценка на качеството на софтуера въз основа на редица вътрешни правила. Скалата отива от А до Е, като А е най-високо качество. Повечето специализирани приставки за качество на кода могат да изчислят тази оценка (вижте по-долу);
  • Брой нарушения на правилата: този показател изчислява броя на нарушените правила от даден набор от правила за кодиране. Нарушенията обикновено са групирани в категории - от критични до незначителни;
  • Цена на забавяне: този (най-вече ръчен) показател помага да се види колко време губи екипът поради технически дълг;
  • Проблем с грешки: с увеличаване на техническия дълг, качеството на софтуера намалява. Броят на бъговете вероятно ще нарасне. Мониторингът на броя на (критичните) грешки, които се появяват, е прост, но полезен показател за проследяване;

Налични са много инструменти и показатели за количествено определяне на техническия дълг. Повечето от тези инструменти се базират на „статичен анализ на кода“ и често могат да се стартират от IDE или от сървъри за изграждане и интеграция. Изброих няколко по-долу, за да ви вдъхновя (което ми отне около 30 минути за настройка):

NЗависи в действие

NDepend е плъгин за Visual Studio (.NET), който предлага натоварване с метри. Особено полезни са SQALE-рейтингът (от А до Е), процентът на възникналия досега технически дълг и броят дни, необходими за поправянето му (груба оценка, разбира се). NDepend може също така да генерира топлинна карта на класовете, които са главни кандидати за рефакторинг - много полезно. Visual Studio IDE (като се започне от Professional) също предлага редица вградени показатели, като Cyclometic Complexity.

Друг вариант е SonarQube. Тази платформа лесно се интегрира с повечето CI-тръбопроводи и IDE и автоматизира огромен брой кодови показатели (включително SQALE-рейтинг).

Въпреки че хесе показателите понякога са груби и несъвършени, това не е причина за изхвърляне. Показателите наистина помагат на хората да разберат последиците от техническия дълг и им помага да вземат по-информирани решения относно качеството на кода. Екипите, които проверяват тези показатели (поне) по време на Sprint Review, са склонни да провеждат отлични и балансирани дискусии относно техническия дълг. Далечен вик от липсата на разбиране, което често характеризира екипи, които не използват този вид инструменти.

4. Направете прозрачен технически дълг на продукта

И накрая, но най-важното, направете техническия дълг прозрачен. Не го крийте от собственика на продукта или от по-широката организация. Идентифицирайте конкретни подобрения, преценете ги и ги предложете за включване в продуктовия бек. Отнасяйте се към тях като към обикновен продукт за изоставането на продукта; разбийте големи артикули според нуждите и ги приоритизирайте със собственика на продукта. Това помага на собственика на продукта да вземе съзнателно решение как да се справи с техническия дълг.

Друг вариант е да се споразумеете със Собственика на продукта, за да запазите (структурен) процент от времето в спринт за справяне с техническия дълг, както екипът за развитие сметне за необходимо. При този подход съществува риск техническият дълг (и какво се прави за него) остава невидим за всички извън екипа за развитие. Така че не забравяйте да създадете елементи за специфичните подобрения и да ги поставите на Sprint Backlog по време на Sprint Planning.

Заключителни мисли

Техническият дълг може да бъде смущаваща и мотивираща тема за много екипи за развитие. Ключовата дума е прозрачност. Обяснете цената на нискокачествения код, като използвате прозрачната метафора „технически дълг“. Направете технически дълг видим в кода, като използвате различни обективни показатели и често преоценявайте тези показатели. И накрая, направете технически дълг видим на продукта и / или Sprint Backlog. Не крийте техническия дълг от собственика на продукта и по-широката организация.

Можете да ни подкрепите, като закупите от нашия уебсайт, като се присъедините към някое от нашите събития или като станете патреон.