A Qodo a kapcsolt specifikációk alapján is ellenőrzi a kódot
A Qodo új képessége a pull requestben hivatkozott jegyből a kapcsolt specifikációt is követi, majd az abban szereplő követelményekhez méri a kódot. Így olyan hiányosságokat is jelezhet, amelyek mellett a kód lefordul és a tesztek is sikeresen lefutnak.
- A Qodo a pull requestből a tickethez kapcsolt specifikációkat is követi.
- A kódot a specifikációban szereplő követelményekhez hasonlítja.
- A rendszer a hiányzó fiókszintű jogosultság-ellenőrzést biztonsági problémaként jelezheti.
- Támogatott forrás az Asana, a Confluence, a Notion, a ServiceNow és a JSM Assets.
- A végső döntést a reviewerek hozzák meg a Qodo jelzései alapján.
A ticketen túl is vizsgálja a változtatást
Egy pull request technikailag helyesnek tűnhet, miközben egy fontos követelmény kimarad belőle. A kód lefordulhat, a tesztek sikeresen lefuthatnak, és a megvalósítás megfelelhet a ticket elfogadási feltételeinek. Ha azonban a ticket egy Confluence-ben tárolt specifikációra hivatkozik, a dokumentumban szereplő biztonsági előírás könnyen kimaradhat a kódból.
A Qodo új funkciója ezt a hiányt próbálja kezelni. Ha a pull request egy ticketre mutató hivatkozást tartalmaz, a Qodo beolvassa a tickethez kapcsolt specifikációt, majd annak követelményei alapján ellenőrzi a kódváltoztatást. A cég szerint ezzel a módosítás mögötti több kontextus kerülhet be közvetlenül a kódreview folyamatába.
A specifikáció lehet a fejlesztés szerződése
A Qodo szerint az AI-kódoló ügynökök ismét előtérbe hozták a specifikációalapú fejlesztést. Ebben a munkafolyamatban a csapat először elkészíti a specifikációt, majd az olyan eszközök, mint a Kiro, tervvé, feladatokká és kóddá alakítják azt. A specifikáció így összeköti a csapat szándékát azzal, amit az ügynök megépít.
Ez a kapcsolat azonban csak akkor marad érvényes, ha valaki a kódot is összeveti a specifikációval. A Qodo szerint az ügynökök kihagyhatnak egy szélső esetet, egyszerűsíthetnek egy korlátozást, vagy a teljes követelmény helyett csak a ticket összefoglalója alapján dolgozhatnak. A Kiro-ban specifikációalapú fejlesztést használó csapatoknál a Qodo Kiro Power ugyanebbe a munkafolyamatba illeszti a Qodo review funkcióját.
Egy hiányzó jogosultság is biztonsági hibát okozhat
A Qodo egy tömeges ügyfélrekord-frissítést bemutató példával szemlélteti a működést. A fejlesztő egy Jira-ticketre hivatkozó pull requestet nyit, a ticket pedig egy API-specifikációt tartalmazó Confluence-oldalra mutat. A specifikáció előírja, hogy minden kérésnél ellenőrizni kell, a hitelesített felhasználó ahhoz a fiókhoz tartozik-e, amely a frissítendő rekordokat birtokolja.
A Qodo követi a ticketből a specifikációhoz vezető hivatkozást, és összeveti az abban szereplő követelményeket a kódváltozásokkal. Ha hiányzik a fiókszintű jogosultság-ellenőrzés, a Qodo biztonsági problémaként jelzi azt. Enélkül egy felhasználó más ügyfél adatait is módosíthatná. A követelmény jelen volt a specifikációban, de nem szerepelt a ticketben és a kódban sem.
A Qodo megkülönbözteti a diff alapú és a specifikációalapú ellenőrzést. Az előbbi a hibás kódot keresheti, az utóbbi pedig azt is vizsgálja, hogy a futó kód megfelel-e a szándékolt működésnek.
Több dokumentációs forrásból is dolgozhat
A vállalat szerint a követelmények gyakran több eszköz között oszlanak meg. A ticket leírja a feladatot, egy kapcsolt dokumentum az architektúrát, egy további oldal pedig a rendszer egészére vonatkozó korlátozásokat rögzíti. A Qodo által támogatott specifikációforrások között szerepel az Asana, a Confluence, a Notion, a ServiceNow és a JSM Assets.
A fejlesztőknek így nem kell minden támogató dokumentumot bemásolniuk a pull request leírásába. A részletes specifikációk a dokumentációs eszközben maradhatnak, a ticket pedig hivatkozhat rájuk. A review során a Qodo ezeket a hivatkozásokat is felhasználhatja egy kihagyott korlátozás, hiányzó működés vagy a dokumentált tervezéssel ütköző döntés felismeréséhez. A jelzéseket továbbra is a reviewerek értékelik, és ők döntik el, hogyan kezelik az egyes megállapításokat.
