De ce se degradează aplicațiile interne și ce oprește asta

Aproape orice firmă cu vechime are una: o aplicație internă care funcționează, pe care nimeni nu o înțelege pe deplin și de care toată lumea se teme puțin.

Cum se ajunge aici

Rareori este vorba de inginerie proastă. Este absența proprietății.

Aplicația a fost construită repede, ca să rezolve o problemă reală. A funcționat, deci a crescut. Cine a scris-o a plecat mai departe. Nu a fost alocată nimănui, pentru că nu era stricată. Dependențele au îmbătrânit, versiunea limbajului a ieșit din suport, iar documentația — niciodată scrisă — a rămas nescrisă.

Apoi trebuie schimbat ceva, iar estimarea pentru o modificare mică este de trei săptămâni, pentru că primele două se duc pe înțelegerea a ceea ce există.

Semnalele de alarmă

• Nimeni nu poate ridica o copie de dezvoltare fără ajutorul unei anumite persoane
• Punerea în producție presupune pași manuali într-o anumită ordine
• Nu există teste, deci nimănui nu îi este comod să schimbe ceva
• Dependențele sunt în urmă cu ani, câteva cu vulnerabilități publicate
• Autorul original este documentația

Ce menține sănătoasă o aplicație

Un responsabil cu nume. Nu o echipă, o persoană, cu timp alocat. Este cel mai puternic predictor.

Pornește dintr-o copie proaspătă. Dacă o mașină nouă poate ajunge de la depozitul de cod la aplicația funcțională în mai puțin de o oră, cunoașterea este în cod, nu în capul cuiva.

Actualizare automată a dependențelor. Mică, deasă, plictisitoare. Alternativa este un salt de doi ani care devine o rescriere.

Suficiente teste cât să permită schimbarea. Nu acoperire totală — atât cât cineva nefamiliarizat să poată face o modificare știind că nu a stricat calculul facturilor.

O pagină scrisă despre de ce. Nu ce face codul, ci de ce s-au luat deciziile ciudate. Cine întreține mai departe are nevoie de raționament, iar codul nu îl poate exprima.

Recuperarea uneia moștenite

Nu o rescrieți. Rescrierile sistemelor funcționale eșuează mai des decât reușesc, pentru că originalul a absorbit ani de reguli de business nedocumentate.

În schimb: faceți-o să se compileze reproductibil, adăugați teste în jurul părților care ating banii, actualizați dependențele în pași mici și scrieți pagina cu de ce. Șase săptămâni concentrate transformă de obicei o datorie înapoi într-un activ.

Preluăm acest tip de lucrări la dezvoltare software.