Технички долг: кога да го отплатите и кога да го оставите на мира

За техничкиот долг се зборува како да е рамномерно лош — проблем што треба да се елиминира, знак за слабо инженерство, нешто што се натрупува од невнимание и се отплаќа со дисциплина.

Ова врамување е погрешно на корисен начин. Дел од техничкиот долг е намерен, рационален и треба да остане каде што е. Дел е навистина скап и треба итно да се реши. Повеќето инженерски тимови тешко ги разликуваат двата случаја, што води или до игнорирање долг што ги забавува, или до преработка на код што не требало ниту да се допре.

Што всушност е технички долг

Оригиналната метафора на Ворд Канингам е поконкретна отколку што обично се памети. Тој ја опишуваше намерната одлука да се напише код што работи сега, но што ќе треба да се редизајнира кога разбирањето на проблемот ќе созрее — и обврската тој редизајн да се направи подоцна.

Долгот е цената на идниот редизајн. Како и финансискиот долг, тој натрупува камата во форма на побавен развој, повеќе грешки и потешко одржување. Исто како и финансискиот долг, преземањето стратегиски — кога треба да се движите брзо и можете да си ја дозволите идната цена — не е само по себе погрешно.

Проблемот е долгот што не бил намерен. Код напишан лошо поради временски притисок без план за враќање. Системи чија архитектура не била дизајнирана за обемот што го достигнале. Зависности што никогаш не биле ажурирани сѐ додека не станале безбедносен ризик.

Долгот што навистина ве забавува

Не секој долг има иста каматна стапка. Категориите што најагресивно се натрупуваат:

Сложеност во основниот домен. Кодот што ја моделира вашата основна деловна логика — цени, кориснички дозволи, наплата, главниот работен тек на производот. Кога тој е заплеткан, секоја функционалност што го допира е потешка, побавна и поризична за градење. Бизнисот плаќа данок на секој спринт.

Празнини во тестовите на критичните патишта. Без тестови околу однесувањето што најмногу значи, промените во еден дел од системот кршат работи во друг, а никој не дознава сѐ додека клиент не пријави. Тоа создава култура на страв од промени, што го забавува развојот насекаде.

Заостанување на зависностите. Библиотеки и рамки што се повеќе главни верзии наназад не се само техничка непријатност — тие се безбедносни ранливости, темпирани бомби за некомпатибилност и сѐ поголема пречка при вработување инженери што работат со современи алатки.

Недокументирано племенско знаење. Системот што само еден инженер целосно го разбира. Кога тој ќе замине или не е достапен, сѐ што го допира тој систем застанува.

Долгот што може да почека

Естетски несовршен, но функционален код. Ако кодот не создава грешки, не го забавува развојот и не ги збунува луѓето што го одржуваат, преработката е задоволувачка, но не и вредна. Инженерите честопати наоѓаат код што им го вреѓа вкусот и сакаат да го исчистат. Тоа не е секогаш добра употреба на време.

Архитектура што е погрешна за обем што не сте го достигнале. Микросервиси дизајнирани за сто инженерски тимови додаваат координациски трошок што тим од пет луѓе не може да го оправда. Прерана оптимизација за обем што го немате е долг сам по себе — сложеноста на решението е долгот.

Стари функционалности што сѐ уште работат. Ако петгодишен дел од кодот сѐ уште функционира, има корисници и не блокира ништо, деловниот аргумент за препишување бара нешто повеќе од „кодот е стар“.

Како да одлучите

Рамката за одлука е деловното влијание, а не инженерската естетика.

Дали овој долг ја забавува испораката на функционалности што му значат на бизнисот? Дали создава грешки што ги погодуваат корисниците? Дали е безбедносен ризик или ризик за усогласеност? Дали ја блокира можноста ефикасно да вработувате и воведувате инженери?

Ако одговорот на кое било од овие е да — отплатете го, намерно, ограничено на областа што го создава проблемот, а не како расфрлана иницијатива „да преработиме сѐ“ без дефиниран крај.

Ако не — ставете го на список, прегледувајте го квартално и оставете го на мира додека градите работи што значат.

---

PNK WORKS проектира системи со одржливи темели и е искрен за тоа кога вреди да се преработи, а кога не. Започнете проект.