Kuanzisha uhandisi wenye kiasi na mtiririko bora wa uthibitishaji kwa Agent wa uandishi wa msimbo kwa kutumia lean-mode

lean-mode ni nini

lean-mode ni SKILL.md inayolenga Agent wa uandishi wa msimbo. Lengo lake si “kuandika msimbo mchache kadiri iwezekanavyo”, bali kumpa Agent vigezo vilivyo wazi vya kumsaidia kujibu maswali mawili ya kihandisi:

1. Je, msimbo unaoonekana kuwa salama unastahili kuandikwa, kama vile uthibitishaji, try/catch, tabaka la uondoaji wa utegemezi, mantiki ya dharura au mfumo wa ziada wa usalama?
2. Kwa nini ujenzi na majaribio ya sasa ni ya polepole, na tunawezaje kufupisha mzunguko wa uthibitishaji usio na ufanisi hadi kwenye upeo unaofaa?

Faili ya ujuzi iko katika skills/lean-mode/SKILL.md, na hutumia frontmatter ya kawaida, yaani name, description pamoja na maudhui ya Markdown. Haitegemei mwenyeji maalum; Agent yeyote anayeunga mkono makubaliano ya SKILL.md anaweza kuitumia.

Matatizo makuu inayolenga kutatua

Katika vipindi virefu vya uandishi wa msimbo, modeli huwa na mielekeo miwili ya kimfumo: uandishi wa msimbo wa kujilinda kupita kiasi na mizunguko ya uthibitishaji isiyo na ufanisi.

Uandishi wa msimbo wa kujilinda kupita kiasi

Mifano ya kawaida ni pamoja na kurudia ukaguzi wa thamani tupu kwenye data ya ndani inayoaminika, kutumia kunasa makosa kuficha chanzo kikuu, kuunda mapema uondoaji wa utegemezi kwa utekelezaji mmoja, na kuendelea kuongeza mantiki ya dharura bila kuthibitisha chanzo cha tatizo. Msimbo unaweza kuonekana kuwa “salama” zaidi, lakini kwa kweli unaweza kuongeza gharama ya matengenezo na kubadilisha kushindwa kulicho wazi kuwa thamani ya kosa ambayo ni vigumu kufuatilia.

Mizunguko ya uthibitishaji isiyo na ufanisi

Mifano ya kawaida ni pamoja na kuendesha ujenzi kamili mara kwa mara, kutumia clean tena na tena, kuzima michakato ya kudumu, kuendesha majaribio yote kila wakati, na kuacha amri iliyoonekana kukwama ikisubiri kwa muda mrefu. lean-mode hudhibiti tabia hizi kwa kanuni sita: kutumia tena michakato, utekelezaji wa nyongeza, udhibiti wa upeo, mpangilio wa utekelezaji, marudio ya miito na udhibiti wa muda wa kuisha.

Data za kiasi katika README zimetokana na kipindi kimoja kirefu cha kazi katika mradi wa Java na Gradle wenye takriban mistari 20k. Zinalenga tu kuonyesha kuwa tatizo lipo kwa kweli, na hazipaswi kuchukuliwa kuwa kipimo cha sekta kinachotumika kwa modeli au miradi yote.

Uwezo mkuu

• Thibitisha mara moja tu kwenye mpaka wa uaminifu: Anza kwa kujibu “null hii imetoka wapi”, ili kuzuia data inayoaminika kuingia kwenye mfumo kisha kukaguliwa tena na tena katika tabaka mbalimbali.
• Epuka kuficha chanzo kikuu: Kuwa mwangalifu unapofanya catch irudishe null, false, mkusanyo tupu au thamani sifuri, kwa kuwa hii inaweza kubadilisha kosa lililo wazi kuwa kosa gumu zaidi kulibaini.
• Dhibiti uondoaji wa utegemezi wa mapema: Kiolesura chenye utekelezaji mmoja tu, kilichoundwa kwa sababu tu kinaweza kubadilishwa baadaye, si lazima kiunde mpaka thabiti wa upanuzi.
• Rekebisha chanzo kikuu kwanza: Kuongeza mantiki ya dharura kunamaanisha kuwa chanzo kikuu hakijatatuliwa kikamilifu. Dharura inapohitajika, eleza umiliki wa tatizo, masharti ya kuiondoa na ushahidi uliothibitishwa.
• Lingamisha ukubwa wa mabadiliko na mabadiliko ya tabia: Unapoongeza zaidi ya mistari 50 ya msimbo, ripoti kwanza jumla ya mistari, mistari inayohusu uthibitishaji na mantiki ya dharura, pamoja na gharama halisi ya kutokuandika msimbo huo.
• Jibu maswali matatu kabla ya kuandika msimbo wa usalama: Je, tatizo linaweza kutokea kweli, mtumiaji ataathirikaje likitokea, na gharama ya kutoliandika ni nini? Swali lolote lisiloweza kujibiwa linamaanisha usiongeze msimbo bado.
• Fupisha mzunguko wa uthibitishaji: Toa mbinu ndogo za uthibitishaji kwa mifumo saba ya ujenzi: Gradle, Maven, Go, Node na TypeScript, Rust, Python na .NET.
• Ruhusu hitimisho la “hakuna haja ya kubadilisha”: Lengo ni kutatua tatizo, si kulazimisha kutoa msimbo, wala kuimarisha kwa ziada maeneo ambayo mtumiaji hajaomba.
• Toa mchakato wa kukagua msimbo uliopo: Kwanza pima msongamano, kisha kagua faili zilizo mbaya zaidi, amua moja baada ya nyingine kama logic iondolewe, ihamishwe juu au ibaki, na wasilisha jedwali la matokeo kwa mtumiaji kabla ya kubadilisha.

Kuhusu msimbo wa kujilinda, ujuzi huu hutoa mifano ya kinyume katika Java, Go, TypeScript na Python, ili kumsaidia Agent kutambua matatizo ya aina moja yanayojificha nyuma ya sintaksia tofauti.

Kusakinisha lean-mode

Njia ya kwanza: Kuvuta kutoka URL

Ikiwa mwenyeji anaunga mkono kuleta ujuzi kutoka URL, kwa mfano ukurasa wa ujuzi wa Vantaloom, unaweza kubandika moja kwa moja anwani ya hazina. Mwenyeji ataipata faili ya ujuzi katika skills/lean-mode/.

https://github.com/Timefiles404/lean-mode-skill

Njia ya pili: Kunakili kwenye eneo la kazi

Kwanza kloni hazina, kisha nakili saraka ya ujuzi kwenye eneo linalotakiwa na mwenyeji. Unapotumia makubaliano ya eneo la kazi la Vantaloom, endesha:

git clone https://github.com/Timefiles404/lean-mode-skill.git
cp -r lean-mode-skill/skills/lean-mode <eneo_lako_la_kazi>/.vantaloom/skills/

Ikiwa mwenyeji anatumia saraka za ujuzi za mtindo wa Claude, nakili kwenye .claude/skills/:

cp -r lean-mode-skill/skills/lean-mode <eneo_lako_la_kazi>/.claude/skills/

Njia ya tatu: Kuunda ujuzi mwenyewe

Unda ujuzi mpya kwenye mwenyeji, kisha bandika maudhui kamili ya skills/lean-mode/SKILL.md kutoka kwenye hazina. Usiondoe frontmatter iliyo juu, kwa kuwa mwenyeji hutumia description iliyomo kuamua wakati wa kupakia ujuzi.

Mtiririko wa msingi wa matumizi

Baada ya kusakinisha, lean-mode hutegemea zaidi maelezo ya ujuzi kuingizwa kwenye muktadha inapohitajika. Inapaswa kuanzishwa Agent anapojitayarisha kuongeza uthibitishaji, kunasa makosa, tabaka la uondoaji wa utegemezi, mantiki ya dharura au mfumo wa ziada wa usalama, au anapokuwa tayari ameendesha ujenzi na majaribio mara kadhaa katika mzunguko mmoja.

Tukio la kwanza: Kuamua kama uthibitishaji mpya unahitajika

1. Kwanza tafuta chanzo cha data na uthibitishe kama imetoka kwenye ingizo la nje, mpaka wa kiolesura au chanzo kingine kisichoaminika.
2. Angalia kama kizuizi hicho tayari kimethibitishwa kwenye mpaka wa uaminifu.
3. Jibu kama tatizo linaweza kutokea kweli, mtumiaji ataathirikaje, na gharama ya kutoweka uthibitishaji ni nini.
4. Data ikishaaminika baada ya kuingia ndani, usiongeze tena uthibitishaji wa wakati wa kuendesha wa aina hiyo katika kila tabaka.

Kwa mfano, Agent anapotaka kuongeza Objects.requireNonNull kwenye mbinu kadhaa za ndani, hapaswi kuongeza msimbo huo kwa sababu tu parameta “kinadharia inaweza kuwa null”. Anapaswa kwanza kufuatilia chanzo halisi cha null na kuamua kama uthibitishaji tayari umekamilika kwenye mpaka.

Tukio la pili: Kushughulikia makosa

Agent anapojitayarisha kunasa kosa na kurudisha thamani chaguo-msingi, anapaswa kwanza kuthibitisha kama hatua hiyo itaficha chanzo kikuu. Miundo ifuatayo inahitaji ukaguzi wa karibu:

catch (...) {
    return false;
}

Lengo si kukataza kunasa makosa yote, bali kuepuka kubadilisha kushindwa kunakoweza kufuatiliwa kuwa false, null, matokeo tupu au thamani sifuri isiyo na muktadha. Biashara inapohitaji kweli kushuka kwa utendaji, bado tathmini kulingana na masharti ya kipekee katika ujuzi.

Tukio la tatu: Kutathmini tabaka la uondoaji wa utegemezi

Ikiwa kiolesura kina utekelezaji mmoja tu kwa sasa, na sababu pekee ya kukiunda ni “huenda kikabadilishwa baadaye”, Agent anapaswa kusimama na kuchunguza mpaka halisi wa mabadiliko. lean-mode haikatai uondoaji wa utegemezi, bali inapinga kuunda tabaka za kati mapema bila hitaji la sasa na mpaka thabiti.

Tukio la nne: Kufupisha ujenzi na majaribio

1. Tumia tena mchakato wa ujenzi uliopo inapowezekana, na epuka kuanzisha upya mchakato mzima bila sababu.
2. Hifadhi bidhaa za nyongeza; usiendeshe clean kwa mazoea.
3. Anza kwa amri ndogo ya kuunganisha tu, kukagua moduli husika tu au kuendesha jaribio moja tu.
4. Uthibitishaji mdogo ukifaulu, panua hatua kwa hatua hadi majaribio ya moduli au majaribio kamili.
5. Dhibiti marudio ya miito na epuka kuendesha amri ileile tena bila mabadiliko ya msimbo.
6. Weka muda unaofaa wa kuisha kwa amri zinazoweza kukwama, na baada ya kushindwa chambua kwanza chanzo kikuu cha awali.

Maudhui kamili ya ujuzi katika README yanaonyesha mzunguko mdogo wa uthibitishaji wa “endesha hii moja tu” kwa mifumo saba ya ujenzi. Katika matumizi halisi, badilisha mifano hiyo kwa amri halisi zinazoweza kutekelezwa moja kwa moja katika mradi wako.

Kukagua msimbo uliolindwa kupita kiasi

lean-mode inajumuisha mchakato wa ukaguzi wa “pima kwanza, kisha ondoa”, unaofaa kwa miradi iliyokusanya kiasi kikubwa cha uthibitishaji, mantiki ya dharura au mantiki ya kuficha makosa.

1. Tafuta na pima: Tumia mifumo ya utafutaji katika kiambatisho kulingana na lugha, kisha hesabu idadi na msongamano wa mifumo husika.
2. Punguza upeo wa ukaguzi: Kagua faili 5 zilizo na mkusanyiko mkubwa zaidi wa matatizo, badala ya kuanza kwa ukaguzi wa hazina nzima.
3. 分類 kila kipengee: Weka kila sehemu ya logic katika kundi la “ondoa”, “hamisha juu” au “acha”. “Hamisha juu” kwa kawaida humaanisha kukusanya uthibitishaji kwenye mpaka halisi wa uaminifu.
4. Ripoti kwanza, kisha badilisha: Mkabidhi mtumiaji jedwali la ukaguzi ili achague; usifanye uondoaji mkubwa bila uthibitisho.
5. Thibitisha kwa mafungu: Baada ya kubadilisha, tumia upeo mdogo wa ujenzi na majaribio, kisha panua kulingana na matokeo.

Mchakato huu unasisitiza uonekano, chaguo na uwezekano wa kurejea nyuma, badala ya kugeuza “kupunguza msimbo wa kujilinda” kuwa urekebishaji mwingine mkubwa usiodhibitiwa.

Kubinafsisha SKILL.md

SKILL.md yenyewe ni Markdown na inaweza kuhaririwa moja kwa moja. Aina tatu zifuatazo za ubinafsishaji zina thamani kubwa zaidi.

Kubadilisha amri za uthibitishaji wa mradi

Badilisha amri za jumla katika sehemu ya saba ziwe amri halisi zinazoweza kutekelezwa katika mradi wa sasa za “kuunganisha tu” na “kuendesha jaribio moja tu”. Amri inayoweza kunakiliwa na kutekelezwa moja kwa moja mara nyingi hudhibiti tabia ya Agent vizuri zaidi kuliko kanuni ya jumla.

Kurekebisha mifumo ya utafutaji

Rekebisha kanuni za utafutaji katika kiambatisho kulingana na mtindo wa msimbo wa mradi. Kwa mfano, mradi wa Java unaweza kutumia Guava Preconditions, au ukatumia zaidi Objects.requireNonNull. Mifumo ya utafutaji inapaswa kuendana na msimbo halisi.

Kurekebisha msongamano wa marejeo

Ujuzi huu hutumia uthibitishaji mmoja kwa kila mistari 200 hadi 500 kama marejeo ya uzoefu, lakini huo si kiwango cha jumla. Msongamano unaofaa wa uthibitishaji hutofautiana kati ya kichanganuzi, mpaka wa itifaki na CRUD ya biashara; urekebishe kulingana na hatari ya kikoa na chanzo cha data.

Mapendekezo ya matumizi ya juu

• Hifadhi pia hali za kipekee kwenye muktadha: Vigezo vya ujuzi huu ni kanuni za mwongozo, si theoremu. Usibakize kauli rahisi kama “usiweke uthibitishaji” au “usitumie catch” pekee.
• Mtaka Agent aripoti muundo wa mabadiliko: Anapoongeza zaidi ya mistari 50, mwambie aeleze wazi jumla ya mistari, mistari ya uthibitishaji na mantiki ya dharura, pamoja na gharama ya kutotekeleza logic hiyo.
• Panua upeo wa uthibitishaji hatua kwa hatua: Anza kwa faili husika, jaribio moja au moduli, kisha nenda kwenye upeo mpana wa majaribio ili kila mabadiliko yasianzishe ujenzi kamili.
• Eleza mantiki ya dharura kwa ushahidi: Mantiki ya dharura inapolazimika kubaki, hifadhi chanzo mahususi cha tatizo, matokeo ya uthibitishaji na masharti ya kuiondoa baadaye. Usitumie kauli zisizoweza kuthibitishwa kama “baadhi ya mazingira yanaweza kushindwa”.
• Chukulia “kutobadilisha” kuwa matokeo halali: Tatizo likitatuliwa na logic iliyopo, au msimbo mpya usipokuwa na faida iliyo wazi, Agent aruhusiwe kusema moja kwa moja kuwa hakuna mabadiliko yanayohitajika.

Mipaka ya uwezo na zana za hiari

lean-mode hubadilisha mielekeo ya modeli, si uwezo wa modeli. Haiwezi kuilazimisha modeli kuacha kuandika aina fulani ya msimbo; inaweza tu kuweka vigezo kwenye muktadha wakati unaofaa. Kwa hiyo inasaidia, lakini si dhamana.

Pia si kichanganuzi tuli, na haitasoma au kuchanganua msimbo kiotomatiki. Ukaguzi katika kiambatisho unahitaji Agent kuendesha mwenyewe amri husika za utafutaji na kufanya uamuzi kulingana na matokeo.

Programu-jalizi ya hiari ya Vantaloom yenye jina hilohilo huweka kanuni zilizofupishwa kwenye muktadha unaobadilika wa kila mzunguko, na hutoa maelezo ya mwisho ya matokeo ya zana pamoja na zana ya lean_review. Programu-jalizi hutoa vikumbusho endelevu, huku ujuzi ukitoa vigezo kamili. Hata bila kusakinisha programu-jalizi, ujuzi huu unaweza kutumika kwa kujitegemea.

Hazina ya mradi inaweza kutazamwa kwenye lean-mode-skill kwenye GitHub, na inatumia leseni ya MIT.

Hitimisho

Thamani ya lean-mode haiko katika kupunguza msimbo kimakanika, bali katika kuhakikisha kila uthibitishaji, ushughulikiaji wa makosa, uondoaji wa utegemezi, mantiki ya dharura na amri ya uthibitishaji inaweza kueleza sababu yake. Baada ya kusakinisha, kuibinafsisha kwa amri halisi za mradi, mifumo ya utafutaji na msongamano wa hatari kunaweza kumsaidia Agent wa uandishi wa msimbo kuzingatia zaidi chanzo kikuu na kujenga mzunguko mfupi na wa kuaminika zaidi wa mrejesho wa kihandisi.