Kā strādāt ar izstrādātāju pie MI veidotas lietotnes

Lai labi strādātu ar izstrādātāju pie lietotnes, ko izveidojāt ar MI, dodiet viņam kodu Git repozitorijā, vienas lapas kopsavilkumu par to, ko lietotne dara un kāpēc, un skaidri noteiktu uzdevumu ar pabeigšanas definīciju. Vienojieties, kurš maina kurus posmus, lai jūs un MI nepārrakstītu viņa darbu, glabājiet repozitoriju un hostinga kontus savā vārdā un dalieties ar noslēpumiem caur pareiziem iestatījumiem, nevis ziņojumos.

Daudzi cilvēki pirmo lietotnes versiju veido ar MI un pēc tam piesaista izstrādātāju — lai pievienotu maksājumus, labotu kaut ko, ko MI turpina kļūdīgi darīt, veiktu drošības pārskatu vai pārņemtu lietotni, kad tā aug. Ja vēl lemjat, vai vispār pieņemt izstrādātāju, skatiet pieņemt izstrādātāju vai veidot ar MI. Šis ceļvedis pieņem, ka esat izlēmis un vēlaties, lai sadarbība noritētu raiti.

Kad izstrādātājs ir vērtīgs

Biežākie iemesli piesaistīt kādu:

• Problēma, ko MI nevar atrisināt pēc vairākiem skaidriem mēģinājumiem un atcelšanām.
• Riskantas jomas: maksājumi, tiesības, jutīgi dati, datubāzes migrācijas.
• Drošības vai koda pārskats pirms palaišanas vai pirms lielāku klientu uzņemšanas.
• Veiktspēja, kad parādās reāls datplūsmas apjoms.
• Izaugsme: lietotne ir kļuvusi par biznesu un vajag kādu, kas atbild par kodu.

Skaidrība par to, kurš no šiem gadījumiem ir jūsējais, nosaka visu turpmāko.

1. solis: nodrošiniet koda kopīgošanu

Izstrādātāji strādā no Git repozitorijiem. Pirms sazināties ar kādu:

1. Savienojiet projektu ar privātu GitHub (vai līdzīgu) repozitoriju vai eksportējiet to.
2. Pārliecinieties, ka kodā vai vēsturē nav noslēpumu. Skatiet kā droši glabāt API atslēgas.
3. Pārbaudiet, vai projekts darbojas no jaunas kopijas — lūdziet MI uzrakstīt uzstādīšanas soļus.

Uzraksti README izstrādātājam, kas pievienojas šim projektam: ko lietotne dara, tehnoloģiju steks, kā to uzstādīt un palaist lokāli, kādi vides mainīgie nepieciešami (tikai nosaukumi), mapju struktūra un viss trausls vai neparasts.

Ja Git ir jauns, kā lietot Git ar MI veidotu lietotni aptver pamatus.

2. solis: uzrakstiet vienas lapas uzdevumu

Izstrādātājs nav sēdējis jūsu tērzēšanas vēsturē. Iedodiet viņam kontekstu vienā lapā:

• Ko lietotne dara, kam un cik cilvēku to izmanto.
• Kas ir vissvarīgākais — plūsmas, kurām nekad nedrīkst pārtrūkt.
• Zināmās problēmas un to, ko jau esat mēģinājis.
• Uzdevums un to, kā zināsiet, ka tas ir pabeigts.
• Ierobežojumi: budžets, termiņš, lietas, ko nedrīkst mainīt.

Labā „pabeigšanas definīcija” ir pārbaudāma: „Pieteicies lietotājs var samaksāt par ikmēneša plānu ar Stripe Checkout, plāns parādās viņa konta lapā, un atceļot klientu portālā, viņš tiek pārcelts zemākā plānā perioda beigās.” Nevis „sakārtot maksājumus”.

3. solis: droši piešķiriet piekļuvi

• Kods: pievienojiet viņu kā līdzstrādnieku repozitorijā. Kad darbs ir sācies, nesūtiet ZIP failus turp un atpakaļ.
• Veidotājs: ja jūsu MI lietotņu veidotājs atbalsta komandas dalībniekus, uzaiciniet viņu darbvietā, kurā ir tikai šis projekts.
• Noslēpumi: pievienojiet tos sava hostinga iestatījumos vai dalieties caur paroļu pārvaldnieku. Nekad neielīmējiet atslēgas e-pastā vai tērzēšanā.
• Testa konti: izveidojiet tos ar testa datiem, nevis dalieties ar savu pieteikšanos.
• Ražošanas dati: tikai tad, ja viņam tie patiesi vajadzīgi, un tikai to, kas nepieciešams.

Glabājiet repozitoriju, domēnu un hostinga kontus savā vārdā. Pievienojiet cilvēkus; nenododiet kontus.

4. solis: vienojieties, kurš ko maina

Lielākais berzes avots ir divas puses — jūs ar MI un izstrādātājs — kas vienlaikus maina vienu un to pašu kodu. Izvēlieties noteikumu:

Neatkarīgi no izvēles: ielādējiet jaunāko kodu pirms katras uzdevumu sesijas un veiciet lielas izmaiņas atzaros, ko otrs cilvēks var pārskatīt.

5. solis: sazinieties rakstiski

• Ziņojiet par problēmām ar soļiem, sagaidāmo un faktisko rezultātu. Skatiet kā uzrakstīt labu kļūdu ziņojumu.
• Glabājiet lēmumus vienā vietā: problēmu sarakstā, kopīgā dokumentā vai pull request komentāros.
• Lūdziet katrā pull request skaidri izskaidrot izmaiņas.
• Vienojieties, cik bieži tiksieties.

6. solis: pārskatiet viņa darbu

Lai pārskatītu darbu, nav jālasa kods. Pārbaudiet:

• Tas dara to, ko teica uzdevums, priekšskatījumā vai pārbaudes kopijā.
• Nekas cits nav salūzis — palaidiet savas kritiskās plūsmas.
• Viņš izskaidroja, ko mainīja un kāpēc.
• Kodā nav parādījušies noslēpumi.

Padziļinātai pārbaudei kā pārskatīt MI ģenerētu kodu sniedz kontrolsarakstu, kas darbojas arī cilvēka rakstītam kodam. Varat arī lūgt savam MI veidotājam izskaidrot izstrādātāja pull request vienkāršos vārdos.

7. solis: skaidri nosakiet īpašumtiesības

• Repozitorijs, hostings, domēns un trešo pušu konti paliek jūsu.
• Pirms darba sākuma īpašumtiesības uz viņa rakstīto kodu noformējiet rakstveidā. Jautājumos par līgumiem pārbaudiet vietējos noteikumus vai konsultējieties ar speciālistu.
• Kad darbs beidzas, noņemiet viņa piekļuvi un nomainiet visas atslēgas, ko viņš redzējis.

Piemēru uzdevumi

Izstrādātājs pēdējā pull mainīja norēķina kodu. Izskaidro vienkāršos vārdos, ko viņš mainīja, un vai kaut kas cits lietotnē no tā ir atkarīgs.

Uzskaiti šīs lietotnes daļas, kas ir vissarežģītākās vai riskantākās, lai varētu pateikt izstrādātājam, uz ko koncentrēties pārskatā.

Nododu maksājumus izstrādātājam. Turpmāk nemaini failus zem src/payments vai maršrutus /api/billing. Ja izmaiņai tie ir vajadzīgi, pasaki man.

Biežākās kļūdas

• Nav uzdevuma. Izstrādātājs maksātās stundās mēģina atšifrēt, ko jūs gribējāt.
• Neskaidrs darba apjoms, piemēram, „salabo kļūdas” vai „padari gatavu ražošanai”.
• Abi rediģē vienlaikus bez iepriekšējas ielādēšanas, tad zaudē darbu konfliktos.
• Savu konta dalīšana vai atslēgu ielīmēšana tērzēšanā.
• Konti izstrādātāja vārdā, kas apgrūtina šķiršanos.
• Aizmirst noņemt piekļuvi un nomainīt atslēgas pēc darba.

Kontrolsaraksts

• Kods atrodas privātā repozitorijā manā vārdā, bez noslēpumiem.
• README izskaidro uzstādīšanu; vienas lapas uzdevums izskaidro lietotni un darbu.
• Uzdevumam ir pārbaudāma pabeigšanas definīcija.
• Piekļuve ir caur līdzstrādnieku uzaicinājumiem, noslēpumi caur iestatījumiem vai paroļu pārvaldnieku.
• Esam vienojušies, kurš ko maina, un es ielādēju pirms uzdevuma.
• Darbs tiek pārskatīts pret uzdevumu un kritiskajām plūsmām.
• Īpašumtiesības ir rakstveidā; piekļuve ir noņemta un atslēgas nomainītas, kad darbs beidzas.

Darbs ar izstrādātāju Mythex

• Uzaiciniet viņu darbvietā. Īpašnieki var uzaicināt neierobežotu skaitu līdzstrādnieku bez maksas par vietu; dalībnieki strādā ar darbvietas projektiem. Izmantojiet atsevišķu darbvietu, lai viņš redzētu tikai šo projektu. Kredīti publicētām lietotnēm tiek izrakstīti darbvietas īpašniekam. Skatiet Uzaicinājumi.
• GitHub sinhronizācija un eksports (Pro). Savienojiet repozitoriju un sūtiet/ielādējiet izmaiņas vai eksportējiet projektu bez noslēpumiem. Skatiet GitHub, export, and import.
• Kopīgojiet priekšskatījuma saiti, lai parādītu darba gaitā esošu darbu kādam bez Mythex konta; pēc tam to dzēsiet.
• Ask režīms atbild uz jautājumiem par kodu, to nemainot — noderīgi, lai saprastu izstrādātāja izmaiņas.

Ja izstrādātājs lietotni palaidīs citur, skatiet kā eksportēt un pašmitināt MI veidotu lietotni.

Jautājumi