Sudėtingiausia dalis slypi dar iki kodo

Prieš dešimt metų dalyvavau Greg Young, Alberto Brandolini ir kitų patyrusių praktikų mokymuose. Vėliau dirbau skirtingose įmonėse, su įvairiais produktais ir komandomis. Technologijos keitėsi, tačiau sudėtingiausios problemos dažnai likdavo stebėtinai panašios.

Vis kartojosi vienas dalykas: dauguma IT problemų nėra vien technologinės.

Parašyti kodą dažnai yra paprastesnė darbo dalis. Sudėtingiausi sprendimai priimami dar iki kodo.

Jie atsiranda bandant suprasti problemą, susitarti dėl bendros kalbos, aiškiai paskirstyti atsakomybes ir nuspręsti, su kokiais kompromisais komanda pasirengusi gyventi.

Tos pačios problemos skirtingose sistemose

Ir augančiose įmonėse, ir didelėse organizacijose ne kartą mačiau situacijas, kai:

• komandos nariai sunkiai susikalba, todėl auga silosai ir priklausomybės;
• architektūra nebeatitinka verslo realybės, sudėtingėja ir nebesukuria pakankamai vertės;
• sprendimų priėmimas užtrunka, o jų įgyvendinimas kainuoja daugiau nei tikėtasi;
• techninės lyderystės trūkumas sudėtingus sistemų pokyčius paverčia pernelyg rizikingais;
• produkto ir inžinerijos kryptys pradeda tolti viena nuo kitos.

Produktai buvo skirtingi. Žmonės buvo skirtingi. Požymiai dažnai buvo tie patys.

Turėjau galimybę ir pasitikėjimą ne tik kurti sistemas kartu su komandomis, bet ir padėti suprasti, kur iš tiesų stringa jų darbas. Kartais apribojimas slypi kode. Tačiau neretai jis atsiranda procesuose, komunikacijoje, neaiškioje atsakomybėje ar neišspręstame pasirinkime tarp kelių pagrįstų variantų.

Technologija neišsprendžia kiekvieno apribojimo

Ne kiekvienai sudėtingai sistemai reikia:

• mikropaslaugų ar įvykių šaltinio modelio;
• DI agentų;
• Kubernetes;
• įmonės masto architektūros programos.

Šie sprendimai savaime nėra blogi. Jie naudingi, kai atitinka problemą. Tačiau pasirinkti dar gerai nesupratus problemos jie gali sukurti dar vieną sudėtingumo sluoksnį ir nepašalinti tikrojo apribojimo.

Kartais geriausias sprendimas yra gerai sukurtas monolitas. Kartais reikia aiškesnės ribos, mažesnio sprendimo arba pokalbio tarp žmonių, kurie iki šiol rėmėsi skirtingomis prielaidomis.

Apie ką rašysiu

Šiame tinklaraštyje nagrinėsiu sudėtingąją programinės įrangos kūrimo dalį, kuri retai telpa į vieną įgyvendinimo užduotį:

• architektūrą ir veiklos sričių ribas;
• paskirstytas sistemas ir realaus laiko duomenis;
• modernizavimą be nereikalingų perrašymų;
• inžinerinę lyderystę ir bendradarbiavimą tarp komandų;
• kur DI padeda inžineriniam darbui, o kur sukuria naujų problemų;
• pamokas iš sprendimų, kurie pasiteisino, ir tų, kurie nepasiteisino.

Pavyzdžiai bus paremti tikromis sistemomis ir realiomis darbo aplinkomis, prireikus pakeičiant atpažįstamas detales. Tikslas nėra propaguoti vieną architektūros stilių. Tikslas – aiškiau parodyti problemą, kompromisus ir sprendimą.

Nuo to ir verta pradėti: pirmiausia suprasti, kas iš tiesų trukdo, ir tik tada rinktis technologiją.

Turbūt apie tokius dalykus artimiausiu metu čia ir rašysiu: apie išspręstas (ir, dėja, neišspręstas) problemas, technologijas, komandas, architektūrą, DI ir pamokas iš realių projektų.

O jus kviečiu sekti, klausti, komentuoti ar tiesiog dalintis savo istorijomis.