Ukifungua repository miezi sita baada ya kipengele kutolewa, unaweza kujenga upya mengi. Unaweza kufuatilia usanifu, kukagua schema, kusoma majaribio, na kuona hasa ni mistari ipi iliyobadilika.
Kile ambacho kwa kawaida huwezi kujenga upya ni mazungumzo yaliyofanya mistari hiyo kuwa ya lazima.
Msimbo hautakuambia kwamba kanuni ya uthibitishaji ipo kwa sababu mteja mmoja hutuma exports zenye hitilafu. Hautaeleza kwamba sera ya ajabu ya kujaribu tena huzuia miamala ya kurudiwa katika mfumo wa downstream. Hautaonyesha kwamba interface iliyo safi zaidi ilikataliwa baada ya jaribio la accessibility, au kwamba mpaka wa huduma unaakisi kizuizi cha kimkataba badala ya upendeleo wa uhandisi.
Git ni bora sana katika kuhifadhi historia ya msimbo. Huhifadhi nia pale tu timu inapoiandika nia hiyo kwa makusudi na kuiweka imeunganishwa na utekelezaji.
Pengo hilo daima limekuwa sehemu ya uhandisi wa programu. Zana za AI za kuandika msimbo zinafanya lionekane zaidi. Mfumo unaweza kusoma kila faili katika repository, kufuatilia kila symbol, na kuzalisha patch inayosadikisha kiufundi huku bado ikitatua tatizo lisilo sahihi.
Tatizo si kwamba msimbo unapotosha. Msimbo unajibu swali finyu zaidi.
Tabaka tano za ukweli wa uhandisi
Mabadiliko mengi yenye maana katika programu hutegemea tabaka tano tofauti za ushahidi.
- Nia — Ni matokeo gani ambayo mtumiaji, mteja, au biashara inaomba? Hili linaweza kupatikana katika specification, ticket, mazungumzo ya usaidizi, au dokezo la mkutano.
- Vikwazo — Ni nini kisichopaswa kuvunjika? Ahadi za compatibility, mipaka ya usalama, kanuni, mikataba, bajeti, na tarehe za mwisho mara nyingi huwa nje ya repository.
- Utekelezaji — Mfumo unafanyaje kazi leo? Msimbo, majaribio, schema, dependencies, na usanidi wa deployment hutoa tabaka hili.
- Ushahidi wa runtime — Nini kinatokea katika mfumo halisi? Logs, traces, metrics, data ya production, na ripoti za matukio vinaweza kupinga dhana zinazoonekana kuwa za busara katika msimbo.
- Historia ya maamuzi — Kwa nini mbinu ya sasa ilichaguliwa? Pull requests, mijadala ya usanifu, mbadala zilizokataliwa, na matukio ya awali ndizo zenye jibu.
Repository huwa na nguvu zaidi katika tabaka la tatu. Ina sehemu za mengine, lakini mara chache hutosha kuyawakilisha kikamilifu.
Hili ni muhimu kwa sababu kushindwa kwa programu mara nyingi hujitokeza kwenye mipaka kati ya tabaka. Utekelezaji unalingana na specification iliyopitwa na wakati. Suluhisho linatimiza ticket lakini linakiuka kizuizi cha uendeshaji. Majaribio yanapita kwa sababu yameweka katika msimbo dhana za jana. Msimbo una ulinganifu wa ndani huku data ya production ikifuata muundo ambao hakuna aliyeandika.
Patch iliyo sahihi katika kiwango cha ndani bado inaweza kuwa mabadiliko yasiyo sahihi.
Kile ambacho hazina haiwezi kujibu yenyewe
Fikiria mtumiaji anayehariri hati kisha anatafuta sentensi iliyosasishwa, lakini anaona toleo la zamani kwenye matokeo. “Fanya utafutaji usasishe mara moja” linaonekana kama ombi lililo wazi. Hazina inaonyesha sehemu kadhaa zinazowezekana za kuanzia, lakini haiwezi kubainisha suluhisho sahihi yenyewe.
| Swali | Chanzo kinachowezekana |
|---|---|
| Ni toleo gani la hati linalochukuliwa kuwa la mamlaka? | Hati chanzo na historia ya marekebisho |
| Maandishi ya zamani yamebaki wapi? | Kumbukumbu za usawazishaji, matokeo ya uchimbaji, faharasa ya utafutaji, au kashe |
| “Mara moja” inamaanisha nini kwa bidhaa hii? | Ahadi ya bidhaa au lengo la huduma |
| Je, ruhusa za hati zilibadilika pamoja na maudhui yake? | Ruhusa za chanzo na historia ya ukaguzi |
| Je, matokeo yaliyopitwa na wakati yanahusu mtumiaji mmoja tu, chanzo kimoja, au eneo moja? | Ufuatiliaji wa maombi na vipimo vya uzalishaji |
Msimbo wa utafutaji unaweza kueleza jinsi matokeo yanavyorejeshwa. Haukuelezi kama hitilafu halisi ni kuchelewa kwa usawazishaji, uchimbaji uliopitwa na wakati, ubatilishaji wa kashe, uenezaji wa ruhusa, au matarajio ambayo bidhaa haikuwahi kufafanua.
Tofauti hii huwa muhimu zaidi katika mifumo iliyokomaa. Sehemu inayoonekana kuwa ya kizamani inaweza bado kusaidia mteja wa urithi. Huduma inayoonekana kuwa ya kurudiwa inaweza kutenganisha data yenye mahitaji tofauti ya ruhusa. Ukaguzi unaoonekana kuwa wa ziada unaweza kuwa ndio alama pekee katika kiwango cha msimbo ya tukio la uzalishaji ambalo timu ya sasa haikuwahi kuliona.
Kuondoa ugumu kuna thamani. Kuondoa historia iliyojificha kama ugumu ni gharama kubwa.
Muktadha zaidi bado unaweza kutoa jibu lisilo sahihi
Suluhisho linaloonekana wazi ni kuipa AI nyenzo zaidi: hazina nzima, tiketi zote, kila hati, kila ujumbe, na kila kumbukumbu.
Hilo linatoa ufikiaji, si uelewa.
Vyanzo vinaweza kuwa vimepitwa na wakati, vinakinzana, vya kubashiri, au vimeandikwa kwa hadhira tofauti. Kikao cha kutupia mawazo hakipaswi kuwa na uzito kuliko vipimo vilivyoidhinishwa. Sharti la miezi sita iliyopita halipaswi kubatilisha kimyakimya uamuzi wa bidhaa wa jana. Kumbukumbu ya uzalishaji inapaswa kuhusishwa na toleo, mazingira, na njia ya msimbo iliyoizalisha. Ombi la mteja halipaswi kuchukuliwa kama sharti la jumla bila kukagua upeo wake.
Kwa hiyo, mfumo makini wa muktadha unahitaji zaidi ya urejeshaji. Unahitaji njia ya kufikiri kuhusu:
- Mamlaka: Ni chanzo kipi kinachoruhusiwa kufafanua sharti?
- Ukaribu wa wakati: Ni taarifa ipi ndiyo ya sasa, na ni ipi imepitwa na wakati?
- Asili: Kila dai, kizuizi, au hitimisho limetoka wapi?
- Mahusiano: Ni suala gani, toleo gani, mteja gani, seti gani ya data, na njia gani ya msimbo vinahusiana?
- Ruhusa: Ni vyanzo vipi vinavyoweza kutumika kwa kazi hii na kuonyeshwa kwa mtu huyu?
Muktadha si rundo la tokeni. Ni grafu yenye muda, mamlaka, na mipaka.
Muktadha zaidi unapaswa kutoa ushahidi zaidi, si kujiamini zaidi bila ushahidi.
Kipimo halisi cha kazi ni mabadiliko
Vihariri na zana za uandishi wa msimbo hupangwa kuzunguka faili kwa sababu faili ndizo tunazobadilisha. Timu za uhandisi hupangwa kuzunguka mabadiliko.
Mabadiliko huanza na sababu. Yanakuwa sharti, yanagusa msimbo na data, yanapitia ukaguzi, yanafika uzalishajini, na yanazalisha ushahidi mpya. Hatua hizo zikibaki zimetengana, kila kazi ya baadaye huanza na duru nyingine ya uchimbaji wa historia.
Mfumo wa AI unaofanya kazi kwenye programu halisi unapaswa kufuata mzunguko huo wa maisha.
Kabla ya utekelezaji, unapaswa kutambua ombi, vikwazo vinavyohusika, na vyanzo vyovyote vinavyokinzana. Unapaswa kujua kama unarekebisha hitilafu, unabadilisha tabia inayotarajiwa, au unaanzisha mkataba mpya.
Wakati wa utekelezaji, unapaswa kuunganisha kila uchaguzi wenye maana na ushahidi. Kwa nini moduli hii? Kwa nini mkakati huu wa uhamishaji? Kwa nini kuhifadhi tawi hili? Maelezo hayo yanapaswa kudumu zaidi ya mazungumzo yaliyozalisha msimbo.
Baada ya utekelezaji, inapaswa kuambatisha matokeo ya uthibitishaji, maamuzi ya mapitio, na vikwazo vipya vilivyogunduliwa kwenye mabadiliko hayo. Vinginevyo mtu anayefuata—au kipindi kijacho cha AI—atalazimika kuvigundua tena.
Hii ndiyo tofauti kati ya zana inayoweza kuhariri hazina ya msimbo na mfumo unaoweza kushiriki katika kazi ya uhandisi.
AI inapaswa kupunguza ujenzi upya, si kuondoa uamuzi
Wakati mwingine muktadha bora huwasilishwa kama njia ya kufikia uundaji wa programu unaojiendesha wenyewe. Thamani ya papo hapo si ya kuvutia sana, lakini ina manufaa zaidi: kupunguza gharama ya kujenga upya uhalisia kabla ya kufanya mabadiliko.
AI inaweza kuleta hitaji la awali karibu na msimbo husika. Inaweza kuibua tukio linaloeleza kinga isiyo ya kawaida. Inaweza kuunganisha kipimo kinachoshindwa na toleo lililokibadilisha. Inaweza kuonyesha kwamba vyanzo viwili vyenye mamlaka havikubaliani kabla ya utekelezaji kuanza.
Uwezo huo hauondoi uamuzi wa uhandisi. Unaufanya uwe na taarifa bora zaidi.
Bado mtu anapaswa kuamua ni mabadilishano gani yanayokubalika, kama hitaji limekamilika, na ni kiwango gani cha hatari ambacho toleo linaweza kubeba. Mfumo unapaswa kufanya ushahidi uonekane na hoja ziweze kukaguliwa. Haupaswi kuficha kutokuwa na uhakika nyuma ya kiraka kilichosafishwa vizuri.
Kigezo si “inaweza kuzalisha msimbo?”
Kigezo ni “inaweza kueleza kwa nini hili ndilo badiliko sahihi kwa sasa?”
Kutoka kujua hazina ya msimbo hadi kujua kazi yenyewe
Wasaidizi wa uandishi wa msimbo walianza kuwa na manufaa walipoelewa faili lililo mbele ya msanidi. Ufahamu wa hazina ya msimbo ulikuwa hatua kuu iliyofuata: kupata msimbo unaohusiana, kufuatilia alama, na kutumia mabadiliko katika mradi mzima.
Hatua inayofuata ni ufahamu wa kazi inayozunguka hazina ya msimbo.
Hiyo inamaanisha kuunganisha msimbo na maelezo ya mahitaji yaliyouomba, mazungumzo yaliyoufafanua, ushahidi wa uzalishaji ulioupinga, na uamuzi unaopaswa kukumbukwa baadaye. Pia inamaanisha kuondoa muktadha ambao hauna umuhimu, umepitwa na wakati, au uko nje ya ruhusa za mtumiaji.
Tunapojenga Dvina, hili ni mojawapo ya mawazo tunayorudia mara kwa mara. Kazi haitokei ndani ya faili moja, programu moja, au mazungumzo moja. Maana huishi katika miunganisho kati ya vitu hivyo na katika jinsi miunganisho hiyo inavyobadilika kadri muda unavyopita.
Hazina ya msimbo inabaki kuwa muhimu. Ndiyo chanzo cha ukweli kinachoweza kutekelezwa kuhusu tabia ya mfumo. Ila si chanzo kamili cha ukweli kuhusu dhamira ya bidhaa, uhalisia wa uendeshaji, au kumbukumbu ya shirika.
Hadithi nzima hubadilisha kile kinachojengwa
Ukiwa na msimbo pekee, swali la kawaida ni:
Ni badiliko gani linaloendana na mfumo huu?
Ukiwa na muktadha mpana zaidi, swali linakuwa:
Ni badiliko gani linaloendana na mfumo huu, hitaji hili, historia hii, na wakati huu?
Swali hilo la pili hunasa vikwazo kabla havijageuka kuwa regressions. Huwapa wakaguzi mantiki iliyo nyuma ya utekelezaji. Huwasaidia wanachama wapya wa timu kuelewa kwa nini mfumo unaonekana jinsi ulivyo. Hupa AI nafasi iliyoegemea kwenye msingi: si kama oracle ndani ya mhariri, bali kama mshiriki anayeweza kukusanya ushahidi katika kazi yote.
Repo yako haikuwa simulizi lote kamwe.
Fursa iliyopo ni kujenga mifumo inayoweza kusoma sehemu iliyobaki—na kuonyesha kazi yake.
