Kaip dirbti su kūrėju su DI sukurta programėle

Kad gerai dirbtumėte su kūrėju programėlėje, sukurtoje su DI, duokite jam kodą Git saugykloje, vieno puslapio apibendrinimą apie tai, ką programėlė daro ir kodėl, bei aiškiai apibrėžtą užduotį su baigtumo apibrėžimu. Susitarkite, kas keičia kurias dalis, kad jūs ir DI neperrašytumėte jo darbo, saugyklą ir talpinimo paskyras laikykite savo vardu, o paslaptis dalinkitės per tinkamus nustatymus, o ne žinutėmis.

Daug kas pirmąją programėlės versiją sukuria su DI, o tada pasikviečia kūrėją — pridėti mokėjimų, ištaisyti tai, ką DI nuolat sugadina, patikrinti saugumą ar perimti programėlę augant. Jei dar sprendžiate, ar apskritai samdyti, žr. samdyti kūrėją ar kurti su DI. Šis gidas daro prielaidą, kad jau nusprendėte ir norite, kad bendradarbiavimas vyktų sklandžiai.

Kada kūrėjas verta

Dažniausios priežastys pasikviesti žmogų:

• Problema, kurios DI neįveikia po kelių aiškių bandymų ir atšaukimų.
• Rizikingos sritys: mokėjimai, leidimai, jautrūs duomenys, duomenų bazės migracijos.
• Saugumo ar kodo peržiūra prieš paleidimą ar prieš prisiimant didesnius klientus.
• Našumas, kai ateina tikras srautas.
• Augimas: programėlė tapo verslu ir reikia žmogaus, kuris atsako už kodą.

Aiškumas, kuris iš šių atvejų jums aktualus, nulemia viską, kas toliau.

1 žingsnis: perkelkite kodą į vietą, kurią galima bendrinti

Kūrėjai dirba iš Git saugyklų. Prieš susisiekdami su kuo nors:

1. Prijunkite projektą prie privačios GitHub (ar panašios) saugyklos arba jį eksportuokite.
2. Įsitikinkite, kad paslapčių nėra nei kode, nei istorijoje. Žr. kaip saugoti API raktus.
3. Patikrinkite, ar projektas paleidžiamas iš švarios kopijos — paprašykite DI parašyti diegimo žingsnius.

Parašyk README kūrėjui, prisijungiančiam prie šio projekto: ką daro programėlė, technologijų rinkinį, kaip ją įdiegti ir paleisti lokaliai, kokių aplinkos kintamųjų reikia (tik pavadinimai), aplankų struktūrą ir viską, kas trapu ar neįprasta.

Jei Git jums naujas, kaip naudoti Git su DI sukurta programėle aprašo pagrindus.

2 žingsnis: parašykite vieno puslapio užduoties aprašymą

Kūrėjas nesėdėjo su jumis prie pokalbio istorijos. Perduokite kontekstą viename puslapyje:

• Ką daro programėlė, kam ir kiek žmonių ja naudojasi.
• Kas svarbiausia — srautai, kurie niekada neturi sugesti.
• Žinomos problemos ir ką jau bandėte.
• Užduotis ir kaip žinosite, kad ji baigta.
• Apribojimai: biudžetas, terminas, dalykai, kurių nereikėtų keisti.

Geras „baigtumo apibrėžimas“ yra patikrinamas: „Prisijungęs naudotojas gali apmokėti mėnesinį planą per Stripe Checkout, planas rodomas jo paskyros puslapyje, o atšaukus prenumeratą klientų portale jis pereina į žemesnį planą laikotarpio pabaigoje.“ Ne „sutvarkyk mokėjimus“.

3 žingsnis: suteikite prieigą saugiai

• Kodas: pridėkite jį kaip saugyklos bendradarbį. Kai darbas prasidėjo, nesiųskite ZIP failų pirmyn ir atgal.
• Kūrimo įrankis: jei jūsų DI programėlių kūrimo įrankis palaiko komandos narius, pakvieskite jį į darbo sritį, kurioje yra tik šis projektas.
• Paslaptys: pridėkite jas savo talpinimo paslaugos nustatymuose arba dalinkitės per slaptažodžių tvarkyklę. Niekada neįklijuokite raktų į el. laišką ar pokalbį.
• Testinės paskyros: sukurkite jas su testiniais duomenimis, o ne dalinkitės savo prisijungimu.
• Gamybiniai duomenys: tik jei jam tikrai reikia, ir tik to, ko reikia.

Saugyklą, domeno ir talpinimo paskyras laikykite savo vardu. Pridėkite žmones; nepatikėkite jiems paskyrų.

4 žingsnis: susitarkite, kas ką keičia

Didžiausias trintis šaltinis — dvi šalys, jūs su DI ir kūrėjas, keičiančios tą patį kodą tuo pačiu metu. Pasirinkite taisyklę:

Kad ir ką pasirinktumėte: prieš kiekvieną užklausų sesiją atsisiųskite naujausią kodą, o didelius pakeitimus darykite šakose, kurias kitas asmuo gali peržiūrėti.

5 žingsnis: bendraukite raštu

• Pranešdami apie problemas nurodykite žingsnius, tikėtinus ir faktinius rezultatus. Žr. kaip parašyti gerą klaidos aprašymą.
• Sprendimus laikykite vienoje vietoje: užduočių sekoje, bendrame dokumente ar pull request komentaruose.
• Paprašykite, kad kiekviename pull request paaiškintų pakeitimus paprasta kalba.
• Susitarkite, kaip dažnai tikrinsitės.

6 žingsnis: peržiūrėkite jo darbą

Peržiūrėti darbą nereikia skaityti kodo. Patikrinkite:

• Ar daro tai, ką nurodė užduotis, peržiūros ar testinėje kopijoje.
• Ar nieko kito nesugadino — paleiskite kritinius srautus.
• Ar paaiškino, ką pakeitė ir kodėl.
• Ar kode nėra paslapčių.

Giliau pažvelgti padės kaip peržiūrėti DI sugeneruotą kodą — kontrolinis sąrašas tinka ir žmogaus rašytam kodui. Taip pat galite paprašyti savo DI kūrimo įrankio paaiškinti kūrėjo pull request paprastais žodžiais.

7 žingsnis: išlaikykite aiškią nuosavybę

• Saugykla, talpinimas, domenas ir trečiųjų šalių paskyros lieka jūsų.
• Prieš darbą raštu susitarkite dėl nuosavybės į jo parašytą kodą. Sutarties klausimais pasitarkite su vietinėmis taisyklėmis ar konsultantu.
• Baigus darbą panaikinkite jo prieigą ir pakeiskite visus raktus, kuriuos jis matė.

Pavyzdinės užklausos

Kūrėjas pakeitė atsiskaitymo kodą paskutiniame pull request. Paaiškink paprasta kalba, ką jis pakeitė ir ar kas nors kitas programėlėje nuo to priklauso.

Išvardyk šios programėlės dalis, kurios sudėtingiausios ar rizikingiausios, kad galėčiau pasakyti kūrėjui, kur sutelkti peržiūrą.

Perduodu mokėjimus kūrėjui. Nuo šiol neliesk failų src/payments ar /api/billing maršrutų. Jei pakeitimui jų reikia, pasakyk man vietoj to.

Dažnos klaidos

• Nėra aprašo. Kūrėjas mokamas valandas spėlioja, ko norėjote.
• Neaiški apimtis, pavyzdžiui „ištaisyk klaidas“ ar „padaryk paruoštą gamybai“.
• Abu redaguoja tuo pačiu metu be atsisiuntimo, tada darbas prarandamas konfliktuose.
• Dalijimasis savo prisijungimu ar raktų įklijavimas į pokalbį.
• Paskyros kūrėjo vardu, todėl sunku nutraukti bendradarbiavimą.
• Pamiršta panaikinti prieigą ir pakeisti raktus po darbo.

Kontrolinis sąrašas

• Kodas yra privačioje saugykloje mano vardu, be paslapčių.
• README paaiškina diegimą; vieno puslapio aprašas paaiškina programėlę ir užduotį.
• Užduotis turi patikrinamą baigtumo apibrėžimą.
• Prieiga suteikiama pakvietimais, paslaptys — per nustatymus ar slaptažodžių tvarkyklę.
• Susitarėme, kas ką keičia, ir prieš duodamas užklausą atsisiunčiu pakeitimus.
• Darbas peržiūrimas pagal aprašą ir kritinius srautus.
• Nuosavybė įrašyta raštu; baigus darbą prieiga panaikinama ir raktai pakeičiami.

Darbas su kūrėju Mythex platformoje

• Pakvieskite jį į darbo sritį. Savininkai gali pakviesti neribotai bendradarbių be mokesčio už vietą; nariai dirba su darbo srities projektais. Naudokite atskirą darbo sritį, kad jis matytų tik šį projektą. Kreditai publikuotoms programėlėms nurašomi darbo srities savininkui. Žr. Invites.
• GitHub sinchronizavimas ir eksportas (Pro). Prijunkite saugyklą ir įkelkite/atsisiųskite arba eksportuokite projektą be paslapčių. Žr. GitHub, export, and import.
• Bendrinkite peržiūros nuorodą, kad parodytumėte darbą eigoje kam nors be Mythex paskyros; baigę ją ištrinkite.
• Ask režimas atsako į klausimus apie kodą jo nekeisdamas — naudinga suprasti kūrėjo pakeitimus.

Jei kūrėjas programėlę paleis kitur, žr. kaip eksportuoti ir savarankiškai talpinti DI sukurtą programėlę.

Klausimai