Parašykite agento užduoties aprašą

Aprašykite pakeitimą, kurį peržiūrėtojas gali įvertinti

„Pridėti klientų eksportą“ palieka kelis atvirus sprendimus. Kas gali eksportuoti įrašus? Kokie įrašai ir laukai įtraukiami? Kas vyksta nepavykus užklausai? Agentas gali užpildyti šias spragas įtikinamais pasirinkimais. Jie vis tiek gali būti netinkami verslui.

Pradėkite nuo naudotojo ir problemos. Tada aprašykite reikiamą veikimą. Įtraukite įrodymus, kurie parodys, ar rezultatas priimtinas.

Aprašas turi mažinti neaiškumą nenustatydamas kiekvieno vidinio projektavimo sprendimo. Nurodykite reikiamą duomenų ribą. Įgyvendinimui leiskite naudoti esamus kodo saugyklos sprendimus, nebent yra priežastis juos keisti.

Naudokite konkretų pavyzdį

Toliau pateiktas išgalvotos klientų aptarnavimo programos aprašas. Tai mokomasis pavyzdys, o ne visa produkcinės sistemos specifikacija.

Rezultatas: Aptarnavimo vadovas gali atsisiųsti klientų sąrašą.
Veikėjas: Dabartinės organizacijos vadovas.
Duomenys: Tik aktyvūs tos organizacijos klientai.
Laukai: Kliento ID, įmonės pavadinimas ir paskyros būsena.
Formatas: UTF-8 CSV su antraštės eilute.
Atmesta užklausa: Grąžinti esamą autorizavimo klaidą.
Tuščias rezultatas: Grąžinti tinkamą CSV tik su antrašte.
Apimtis: Naudoti esamą eksporto maršrutą ir audito sprendimą.
Neįtraukta: Jokių naujų vaidmenų, priklausomybių ar diegimo.
Įrodymai: Leidžiamų, atmestų, tuščių ir kitos organizacijos duomenų užklausų testai.

Šis aprašas nurodo naudingą veikimą ir ribas. Jis taip pat atskleidžia daugiau klausimų. Ar sistema turėtų riboti eksporto dydį? Ar lauke gali būti skaičiuoklės formulė? Kas gali pasiekti audito įrašą? Svarbius klausimus išspręskite prieš įgyvendinimą. Nelaikykite pavyzdžio universaliu kontroliniu sąrašu.

Atskirkite reikalavimus nuo prielaidų

Reikalavimas nurodo veikimą, kurį pakeitimas privalo užtikrinti. Prielaida yra faktas, kurio dar nepatikrinote. Laikykite juos atskirai.

Pavyzdžiui, „naudoti esamą audito sprendimą“ remiasi prielaida, kad tinkamas sprendimas yra. Paprašykite agento jį rasti. Jei kodo saugykloje jo nėra, agentas turėtų pranešti apie trūkstamą priklausomybę prieš kurdamas naują audito sistemą.

Apribojimas gali prieštarauti ir rezultatui. Esamas maršrutas gali būti sąmoningai sukurtas grąžinti visas organizacijas. Agentas turėtų parodyti prieštaravimą ir pasiūlyti ribotą pataisą. Jis neturėtų tyliai pašalinti duomenų ribos ar išplėsti užduoties iki architektūros perrašymo.

Į užbaigimą įtraukite įrodymus

Paprašykite atlikto darbo santraukos, kuri paaiškintų galutinį veikimą, pasikeitusią apimtį ir atliktus patikrinimus. Kur svarbu, reikalaukite tikslių komandų ir rezultatų. Atskirkite sėkmingą patikrinimą nuo to, kurio nepavyko paleisti.

Pull request turi išlaikyti pakeitimo priežastį. Vėlesnis prižiūrėtojas gali matyti kodą be pradinio pokalbio. Pateikite pakankamai konteksto paaiškinti, kodėl eksportas neįtraukia tam tikrų laukų ir kaip užtikrinama prieigos kontrolė.

Google pakeitimų aprašymo gairės yra naudingas šio įrašo orientyras. Aprašymas turi paaiškinti pakeitimą ir jo tikslą. Po peržiūros pataisų suderinkite įrašą su galutiniu įgyvendinimu.

Išlaikykite aprašo apimtį proporcingą

Nedidelei teksto pataisai pakanka trumpo aprašo. Duomenų eksportui reikia daugiau detalių, nes jo klaidos gali atskleisti informaciją. Naujai mokėjimo eigai reikia dar daugiau analizės ir peržiūros.

Aprašo kokybės nematuokite ilgiu. Paklauskite, ar kompetentingas peržiūrėtojas galėtų atskirti teisingą rezultatą nuo klaidingo. Jei du pagrįsti įgyvendinimai skirtųsi svarbiu veikimu, pirmiausia jį patikslinkite.