Kaip tobulinti DI sukurtą programėlę jos nesugadinant

Norėdami tobulinti DI sukurtą programėlę jos nesugadinant, keiskite vieną dalyką viename raginime, patikrinkite jį peržiūroje ir prieš judėdami toliau išsaugokite kontrolinį tašką. Aprašykite, ką matote, o ne tai, ką, jūsų manymu, daro kodas, planuokite didelius pakeitimus prieš juos kurdami, o kai pakeitimas nepavyksta, grįžkite prie paskutinės veikiančios versijos, o ne prašykite DI taisyti savo pataisymą.

Pirmoji programėlės versija dažnai susikuria per kelias minutes. Sunkiausia yra penkiasdešimtas pakeitimas, kai kiekvienas naujas raginimas gali sugadinti tai, kas jau veikė. Šis vadovas — tai ciklas, kuris to neleidžia.

Tobulinimo ciklas

1. Pasirinkite vieną pakeitimą. Viena funkcija, viena klaida, vienas puslapis.
2. Aprašykite jį pagal tai, ką naudotojas mato ir daro.
3. Didelius pakeitimus pirmiausia suplanuokite. Paprašykite plano, perskaitykite jį, tada kurkite.
4. Patikrinkite rezultatą peržiūroje — pakeitimą ir su juo susijusius srautus.
5. Išsaugokite kontrolinį tašką arba commit.
6. Kartokite.

Kiekvienas žingsnis egzistuoja tam, kad pakeitimai liktų maži ir grįžtami.

1 žingsnis: laikykite trumpą sąrašą

Prieš raginant, užrašykite, ką norite pakeisti, pagal svarbą. Tai neleidžia išsiųsti vienos pastraipos su dešimt norų vienoje žinutėje ir suteikia būdą pasakyti „ne dabar“ idėjoms, kurios iškyla viduryje darbo.

Jei pakeitimas didelis, suskaidykite jį. „Pridėti komandų paskyras“ tampa: sukurti komandas, pakviesti narį, perjungti tarp komandų, apriboti duomenis dabartinei komandai. Kiekvienas yra atskiras raginimas. Vartotojo istorijų rašymas yra geras būdas tai padaryti.

2 žingsnis: aprašykite, ką matote

DI negali matyti jūsų ekrano, nebent jam pasakysite. Nurodykite konkrečius dalykus ir pasakykite, kas turėtų įvykti:

Kainų puslapyje telefone Pro kortelės mygtukas nukirstas dešinės krašto. Desktop išdėstymą palikite tokį patį; ekranuose, mažesniuose nei 640px, sudėkite korteles viena po kitos ir padarykite mygtukus per visą plotį.

Palyginkite tai su „kainų puslapis atrodo blogai mobiliajame“. Pirmąjį galima padaryti ir patikrinti vienu kartu; antrasis kviečia perdaryti dizainą, kurio neprašėte.

Ekrano nuotraukos padeda. Jei jūsų kūrimo įrankis priima vaizdus, pridėkite vieną ir apibraukite problemą.

3 žingsnis: planuokite prieš didelius pakeitimus

Bet kam, kas liečia kelias programėlės dalis — naują duomenų modelį, mokėjimus, naudotojų vaidmenis —, prašykite plano prieš bet kokį kodo keitimą:

Dar nekeiskite kodo. Noriu, kad naudotojai priklausytų komandoms ir matytų tik savo komandos projektus. Suplanuokite pakeitimą: kurios lentelės, puslapiai ir API maršrutai keisis, kas nutiks esamų naudotojų duomenims ir kokia tvarka tai kurtumėte.

Perskaitykite planą. Jei jis klaidingas, plano taisymas kainuoja daug mažiau nei kūrimo atšaukimas.

4 žingsnis: pasakykite, kas negali keistis

DI įrankiai kartais „sutvarko“ dalykus, apie kuriuos neprašėte. Apsaugokite tai, kas veikia:

Pridėkite datos filtrą užsakymų lentelei. Nekeiskite lentelės stulpelių, stiliaus ar eksporto mygtuko.

Taisyklėms, galioms visur — prekės ženklo spalvos, tono balsas, „niekada neištrinti duomenų be patvirtinimo“ —, įrašykite jas į projekto pastabų failą ar žinių nustatymą, kurį DI skaito kiekvieną kartą, o ne kartokite.

5 žingsnis: tikrinkite daugiau nei patį pakeitimą

Po kiekvieno raginimo patikrinkite:

• Patį pakeitimą. Ar daro tai, ko prašėte, darbalaukyje ir telefone?
• Kaimynus. Dalykus tame pačiame puslapyje ir srautus, kurie naudoja tuos pačius duomenis.
• Kritinį kelią. Registracija, prisijungimas, pagrindinis veiksmas, mokėjimas. Trisdešimties sekundžių peržiūra po kiekvieno didelio pakeitimo sugauna daugumą pažeidimų anksti.

Jei kas nors ne taip, aprašykite tiksliai — žr. kaip parašyti gerą klaidos pranešimą.

6 žingsnis: grįžkite atgal vietoj kaupimo

Kai pakeitimas ką nors sugadina, o pirmasis pataisymas nepadeda, sustokite. Kiekvienas papildomas „pataisymas“ statomas ant sugedusios būsenos, o problemos kaupiasi.

Vietoj to:

1. Grįžkite prie paskutinės veikiančios versijos (kontrolinio taško ar Git commit).
2. Išsiaiškinkite, kas raginime buvo neaiškaus.
3. Bandykite dar kartą mažesniu arba aiškesniu prašymu.

Tas pakeitimas sugadino juodraščių išsaugojimą. Grįžau atgal. Šį kartą: pridėkite tik automatinio išsaugojimo indikatorių, kaip tekstą antraštėje. Nekeiskite, kaip išsaugomi juodraščiai.

7 žingsnis: žinokite, kada kurti iš naujo tinka

Kurti iš naujo nuo nulio reiškia išmesti daug veikiančių detalių. Tai verta tik tada, kai:

• Produkto idėja visiškai pasikeitė.
• Pagrindinė struktūra nebepalaiko to, ko dabar reikia — pavyzdžiui, ji buvo sukurta kaip statinė svetainė, o dabar reikia paskyrų ir duomenų bazės.
• Projektas dar arti tuščio.

Kai kuriate iš naujo, surašykite, ką išsaugoti: pavadinimą, spalvas, tekstus, dalis, kurios patiko naudotojams.

Pavyzdiniai raginimai

Prieš tęsdami, apibendrinkite, kaip programėlė veikia dabar: puslapius, saugomus duomenis ir tai, ką manote esant trapu.

Noriu pridėti pasikartojančius užsakymus. Kokia mažiausia versija būtų naudinga? Pasiūlykite ją kaip tris atskirus pakeitimus, kuriuos galime daryti po vieną.

Peržiūrėkite paskutinius tris pakeitimus, ar kas nors galėjo sugadinti atsiskaitymo srautą. Dar nekeiskite.

Dažnos klaidos

• Dešimt prašymų viename raginime. Kai kurie atliekami, kai kurie pusiau, o jūs nežinote, kurie.
• Neaiškus grįžtamasis ryšys. „Neveikia“ ar „padaryk geriau“ sukelia spėliones.
• Niekada netikrinami kaimynai. Pakeitimas bendrame komponente sugadina tris kitus puslapius.
• Pataisymų taisymas. Jei jau keturi raginimai gilyje prie klaidos, grįžkite atgal.
• Konteksto kartojimas kiekvieną kartą vietoj nuolatinių taisyklių projekto pastabose.
• Kūrimas iš naujo, kai įstrigote. Dauguma „pradėkime iš naujo“ momentų iš tikrųjų reiškia „grįžkime dviem žingsniais atgal“.

Kontrolinis sąrašas

• Vienas tikslas viename raginime.
• Aprašau, ką matau ir ko turėtų būti.
• Dideli pakeitimai gauna planą prieš bet kokį kodą.
• Pasakau, kas negali keistis.
• Po kiekvieno pakeitimo tikrinu jį, jo kaimynus ir kritinį kelią.
• Išsaugau kontrolinį tašką arba commit po kiekvieno veikiančio pakeitimo.
• Kai pataisymas nepavyksta, grįžtu atgal, o ne kraunu pataisymus.
• Nuolatinės taisyklės gyvena projekto pastabose, kurias DI skaito kiekvieną kartą.

Tobulinimas Mythex

Mythex sukurtas aplink šį ciklą:

• Planavimo, kūrimo ir klausimų režimai. Planavimas aptaria metodą prieš redaguojant; Klausimai atsako nekeičiant kodo; Kūrimas atlieka pakeitimą. Žr. Pokalbis.
• Kontroliniai taškai. Po kiekvieno sėkmingo ėjimo Mythex išsaugo Git kontrolinį tašką; Grįžti į šį tašką atšaukia. Taip pat galite redaguoti ankstesnę žinutę ir Atmesti ir siųsti iš naujo, kad išbandytumėte kitokį raginimą nuo to taško. Žr. Tobulinkite nekurdami iš naujo.
• Žinios. Projekto nustatymai → Žinios laiko nuolatines pastabas, kurių agentas laikosi kiekvienoje žinutėje.
• /test leidžia agentui po didelio pakeitimo peržiūroje paspaudinėti kaip naudotojui.

Mažesni prašymai taip pat kainuoja mažiau kreditų. Patys raginimai aptariami kaip rašyti raginimus DI programėlių kūrimo įrankiams; kai kas nors sugenda, — kaip derinti DI sukurtą programėlę.

Klausimai