Hap një repository gjashtë muaj pasi një veçori është lançuar dhe mund të rindërtosh shumëçka. Mund të gjurmosh arkitekturën, të inspektosh skemën, të lexosh testet dhe të shohësh saktësisht cilat rreshta kanë ndryshuar.
Ajo që zakonisht nuk mund të rindërtosh është biseda që i bëri të nevojshme ato rreshta.
Kodi nuk do të të tregojë se një rregull validimi ekziston sepse një klient dërgon eksporte të formuara gabim. Nuk do të shpjegojë se një politikë e çuditshme riprovimi parandalon transaksione të dyfishta në një sistem downstream. Nuk do të tregojë se ndërfaqja më e pastër u refuzua pas një testi aksesueshmërie, apo se një kufi shërbimi pasqyron një kufizim kontraktual dhe jo një preferencë inxhinierike.
Git është i shkëlqyer në ruajtjen e historisë së kodit. Ai e ruan qëllimin vetëm kur një ekip e shkruan qëllimisht atë dhe e mban të lidhur me implementimin.
Ky hendek ka qenë gjithmonë pjesë e inxhinierisë së softuerit. Mjetet e kodimit me AI e bëjnë më të dukshëm. Një sistem mund të lexojë çdo skedar në një repository, të ndjekë çdo simbol dhe të gjenerojë një patch teknikisht bindës, ndërsa prapë zgjidh problemin e gabuar.
Problemi nuk është se kodi të çon në gabim. Kodi po i përgjigjet një pyetjeje më të ngushtë.
Pesë shtresa të së vërtetës inxhinierike
Shumica e ndryshimeve me kuptim në softuer varen nga pesë shtresa të ndryshme prove.
- Qëllimi — Çfarë rezultati po kërkon përdoruesi, klienti ose biznesi? Kjo mund të gjendet në një specifikim, ticket, bisedë me support ose shënim mbledhjeje.
- Kufizimet — Çfarë nuk duhet të prishet? Premtimet e përputhshmërisë, kufijtë e sigurisë, rregulloret, kontratat, buxhetet dhe afatet shpesh qëndrojnë jashtë repository-t.
- Implementimi — Si funksionon sistemi sot? Kodi, testet, skemat, varësitë dhe konfigurimi i deployment-it e ofrojnë këtë shtresë.
- Provat në runtime — Çfarë po ndodh në sistemin real? Log-et, traces, metrikat, të dhënat e prodhimit dhe raportet e incidenteve mund të kundërshtojnë supozime që në kod duken të arsyeshme.
- Historia e vendimeve — Pse u zgjodh qasja aktuale? Pull request-et, diskutimet e dizajnit, alternativat e refuzuara dhe incidentet e mëparshme e mbajnë përgjigjen.
Repository është më i fortë në shtresën e tretë. Ai përmban pjesë të të tjerave, por rrallë mjaftueshëm sa për t’i përfaqësuar plotësisht.
Kjo ka rëndësi sepse dështimet e softuerit shpesh shfaqen në kufijtë mes shtresave. Implementimi përputhet me një specifikim të vjetëruar. Zgjidhja e plotëson ticket-in, por shkel një kufizim operacional. Testet kalojnë sepse kodifikojnë supozimet e djeshme. Kodi është i qëndrueshëm brenda vetes, ndërsa të dhënat e prodhimit ndjekin një model që askush nuk e dokumentoi.
Një patch lokalisht i saktë mund të jetë prapë ndryshimi i gabuar.
Çfarë nuk mund t’i përgjigjet vetë depoja
Merrni parasysh një përdorues që redakton një dokument dhe më pas kërkon fjalinë e përditësuar, por në rezultate sheh vetëm versionin e vjetër. “Bëjeni kërkimin të përditësohet menjëherë” tingëllon si një kërkesë e qartë. Depoja zbulon disa vende të mundshme ku mund të fillohet, por nuk mund ta përcaktojë vetë zgjidhjen e saktë.
| Pyetja | Burimi i mundshëm |
|---|---|
| Cili version i dokumentit është autoritativ? | Dokumenti burimor dhe historiku i rishikimeve |
| Ku mbetet teksti i vjetër? | Regjistrat e sinkronizimit, rezultati i nxjerrjes, indeksi i kërkimit ose cache |
| Çfarë do të thotë “menjëherë” për këtë produkt? | Premtimi i produktit ose objektivi i shërbimit |
| A ndryshuan lejet e dokumentit bashkë me përmbajtjen e tij? | Lejet e burimit dhe historiku i auditimit |
| A kufizohet rezultati i vjetruar te një përdorues, burim ose rajon? | Gjurmët e kërkesave dhe metrikat e prodhimit |
Kodi i kërkimit mund të shpjegojë se si kthehen rezultatet. Ai nuk mund t’ju tregojë nëse defekti i vërtetë është vonesa e sinkronizimit, nxjerrja e vjetruar, pavlefshmëria e cache, përhapja e lejeve apo një pritshmëri që produkti nuk e ka përcaktuar kurrë.
Ky dallim bëhet edhe më i rëndësishëm në sisteme të pjekura. Një fushë që duket e vjetëruar mund të mbështesë ende një klient legacy. Një shërbim që duket i dyfishuar mund të ndajë të dhëna me kërkesa të ndryshme lejesh. Një kontroll që duket i tepërt mund të jetë e vetmja gjurmë në nivel kodi e një incidenti në prodhim që ekipi aktual nuk e ka parë kurrë.
Heqja e kompleksitetit ka vlerë. Heqja e historisë së maskuar si kompleksitet kushton shtrenjtë.
Më shumë kontekst mund të prodhojë sërish përgjigjen e gabuar
Zgjidhja e dukshme është t’i jepet AI-së më shumë material: e gjithë depoja, çdo tiketë, çdo dokument, çdo mesazh dhe çdo regjistër.
Kjo krijon qasje, jo kuptim.
Burimet mund të jenë të vjetruara, kundërthënëse, spekulative ose të shkruara për audienca të ndryshme. Një brainstorming nuk duhet të ketë përparësi ndaj një specifikimi të miratuar. Një kërkesë gjashtëmujore nuk duhet të mbizotërojë në heshtje mbi vendimin e djeshëm të produktit. Një regjistër prodhimi duhet të lidhet me versionin, mjedisin dhe rrugën e kodit që e prodhoi. Një kërkesë klienti nuk duhet të trajtohet si kërkesë universale pa verifikuar shtrirjen e saj.
Prandaj, një sistem serioz konteksti ka nevojë për më shumë se thjesht rikthim. Atij i duhet një mënyrë për të arsyetuar rreth:
- Autoriteti: Cilit burim i lejohet të përcaktojë kërkesën?
- Aktualiteti: Cili informacion është aktual dhe çfarë është zëvendësuar?
- Prejardhja: Nga erdhi secili pretendim, kufizim ose përfundim?
- Marrëdhëniet: Cilat çështje, versione, klientë, datasete dhe rrugë kodi i përkasin njëra-tjetrës?
- Lejet: Cilat burime mund të përdoren për këtë detyrë dhe t’i shfaqen këtij personi?
Konteksti nuk është një grumbull tokenësh. Është një graf me kohë, autoritet dhe kufij.
Më shumë kontekst duhet të prodhojë më shumë prova, jo më shumë siguri pa prova.
Njësia e vërtetë e punës është ndryshimi
Redaktorët dhe mjetet e kodimit organizohen rreth skedarëve sepse skedarët janë ato që ne modifikojmë. Ekipet inxhinierike organizohen rreth ndryshimeve.
Një ndryshim nis me një arsye. Ai bëhet kërkesë, prek kodin dhe të dhënat, kalon në rishikim, arrin në prodhim dhe krijon prova të reja. Nëse këto faza mbeten të shkëputura, çdo detyrë e ardhshme nis me një raund tjetër arkeologjie.
Një sistem AI që punon mbi softuer real duhet ta ndjekë atë cikël jete.
Përpara implementimit, ai duhet të identifikojë kërkesën, kufizimet përkatëse dhe çdo burim kundërthënës. Duhet të dijë nëse po rregullon një defekt, po ndryshon sjelljen e pritur apo po prezanton një kontratë të re.
Gjatë implementimit, ai duhet të lidhë çdo zgjedhje domethënëse me prova. Pse ky modul? Pse kjo strategji migrimi? Pse të ruhet kjo degë? Shpjegimi duhet të mbijetojë përtej bisedës që prodhoi kodin.
Pas zbatimit, duhet t’ia bashkëngjisë ndryshimit rezultatet e verifikimit, vendimet e rishikimit dhe kufizimet e zbuluara rishtazi. Përndryshe, personi tjetër—ose sesioni i ardhshëm i AI—do të duhet t’i rizbulojë ato.
Ky është ndryshimi mes një mjeti që mund të redaktojë një repository dhe një sistemi që mund të marrë pjesë në punën inxhinierike.
AI duhet të zvogëlojë rindërtimin, jo të heqë gjykimin
Konteksti më i mirë nganjëherë paraqitet si një rrugë drejt zhvillimit autonom të softuerit. Vlera e menjëhershme është më pak dramatike dhe më e dobishme: ulja e kostos së rindërtimit të realitetit përpara se të bëhet një ndryshim.
AI mund ta sjellë kërkesën fillestare pranë kodit përkatës. Mund të nxjerrë në pah incidentin që shpjegon një masë mbrojtëse të pazakontë. Mund të lidhë një metrikë që po dështon me release që e ndryshoi atë. Mund të tregojë se dy burime autoritative nuk pajtohen përpara se të fillojë zbatimi.
Këto aftësi nuk e heqin gjykimin inxhinierik. Ato e bëjnë atë më të informuar.
Një person ende duhet të vendosë cili kompromis është i pranueshëm, nëse një kërkesë është e plotë dhe sa rrezik mund të mbartë një release. Sistemi duhet t’i bëjë provat të dukshme dhe arsyetimin të inspektueshëm. Nuk duhet ta fshehë pasigurinë pas një patch-i të lëmuar.
Standardi nuk është “a mund të gjenerojë kod?”
Standardi është “a mund të shpjegojë pse ky është ndryshimi i duhur tani?”
Nga i vetëdijshëm për repository te i vetëdijshëm për punën
Asistentët e kodimit u bënë fillimisht të dobishëm duke kuptuar skedarin përpara zhvilluesit. Vetëdija për repository ishte hapi tjetër i madh: gjetja e kodit të lidhur, ndjekja e simboleve dhe zbatimi i ndryshimeve në të gjithë një projekt.
Hapi i ardhshëm është vetëdija për punën përreth repository.
Kjo do të thotë të lidhësh kodin me specifikimin që e kërkoi, bisedën që e sqaroi, provat nga prodhimi që e vunë në dyshim dhe vendimin që duhet të mbahet mend më pas. Do të thotë gjithashtu të përjashtosh kontekstin që është i parëndësishëm, i vjetëruar ose jashtë lejeve të përdoruesit.
Teksa po ndërtojmë Dvina, kjo është një nga idetë te të cilat kthehemi vazhdimisht. Puna nuk ndodh brenda një skedari, aplikacioni apo bisede të vetme. Kuptimi jeton në lidhjet mes tyre dhe në mënyrën se si ato lidhje ndryshojnë me kalimin e kohës.
Repository mbetet thelbësor. Ai është burimi i ekzekutueshëm i së vërtetës për sjelljen e sistemit. Thjesht nuk është burimi i plotë i së vërtetës për synimin e produktit, realitetin operacional apo kujtesën organizative.
E gjithë historia ndryshon atë që ndërtohet
Vetëm me kodin, pyetja natyrore është:
Cili ndryshim i përshtatet këtij sistemi?
Me kontekstin më të gjerë, pyetja bëhet:
Cili ndryshim i përshtatet këtij sistemi, kësaj kërkese, kësaj historie dhe këtij momenti?
Ajo pyetja e dytë i kap kufizimet përpara se të kthehen në regresione. U jep rishikuesve arsyetimin pas implementimit. I ndihmon anëtarët e rinj të ekipit të kuptojnë pse sistemi duket ashtu siç duket. I jep AI-së një rol të mbështetur në fakte: jo si një orakull brenda editorit, por si një pjesëmarrës që mund të mbledhë prova nga e gjithë puna.
Repo-ja juaj nuk ka qenë kurrë e gjithë historia.
Mundësia është të ndërtohen sisteme që mund ta lexojnë edhe pjesën tjetër të saj — dhe të tregojnë punën e tyre.
