Jau vairāk nekā piecus gadus es profesionāli rakstīju kodu. Pirmos četrus gadus es nekad nerūpējos par savu piesaistes pieprasījumu (PR) lielumu. Tomēr pagājušajā gadā es pārgāju no masveida PR iesniegšanas ar tūkstošiem izmaiņu rindu uz to sadalīšanu mazākos, vieglāk pārvaldāmos. Šīs maiņas priekšrocības ir bijušas milzīgas, un šajā emuārā es dalīšos ar šīm priekšrocībām. Saskaņā ar , vilkšanas pieprasījums ir: GitHub Izvilkšanas pieprasījums ir priekšlikums apvienot izmaiņu kopu no vienas filiāles citā. Izvilkšanas pieprasījumā līdzstrādnieki var pārskatīt un apspriest ierosināto izmaiņu kopu, pirms viņi integrē izmaiņas galvenajā kodu bāzē. Būtībā piesaistes pieprasījums ir sadarbības veids; mums jādara viss iespējamais, lai uzlabotu šo sadarbību. Viena efektīva metode, kā uzlabot šo sadarbību, ir samazināt PR. Nav universālas definīcijas, lai atšķirtu mazu un lielu PR. Nepietiek ar paļaušanos tikai uz mainīto rindu skaitu, jo automātiski ģenerēts kods un testi var palielināt rindu skaitu. Kad es šajā rakstā atsaucos uz maziem PR, es domāju lielāka PR sadalīšanu vairākos mazākos, loģiski saskaņotos PR. Katram mazākajam PR ir jābūt atsevišķam, apvienojamam un izvietojamam. Es neatbalstu mākslīgu sadalīšanu, piemēram, PR sadalīšanu divās daļās, no kurām vienā ir viss kods, bet otrā - tikai testi, jo šī pieeja nedod nekādu labumu, par kuru es dalos tālāk. Efektīvas atsauksmes: Palūdziet programmētājam pārskatīt 10 koda rindiņas, viņš atradīs 10 problēmas. Palūdziet viņam izpildīt 500 rindiņas, un viņš teiks, ka tas izskatās labi. Lai gan šis citāts ir humoristisks, tajā ir patiesība. Ikviens ir aizņemts ar savu darbu, un, kad jūs lūdzat kādam pārskatīt PR, jūs būtībā pieprasāt viņam laiku. Lai pārskatītu PR, recenzentam ir jāmaina konteksts no sava darba, un, ja pārskatīšana aizņem daudz laika, viņam var būt grūti atgriezties pie sava darba, kas var ietekmēt viņu motivāciju un apņemšanos veikt pārskatīšanu. Mazākus PR, kuru pārskatīšana aizņem tikai aptuveni 20–30 minūtes, ir daudz vieglāk risināt, salīdzinot ar tiem, kas var aizņemt 2–3 stundas. Turklāt lielāki PR bieži noved pie nepilnībām, jo mūsu uzmanība spēj izturēt tikai tik daudz, un lēkšana starp daudzām izmaiņām vienā PR var būt mulsinoša. Mana pieredze liecina, ka mazāki PR parasti saņem labākas atsauksmes un rada jēgpilnākas dizaina sarunas. Ātrākas atsauksmes: Šobrīd es domāju pievienot savu PR savam testamentam, ja tas joprojām tiks pārskatīts pēc manis prombūtnes. Ilgāki PR prasa no recenzentiem ievērojamu laika ieguldījumu, tāpēc viņiem ir mazāka iespēja pievērst uzmanību — it īpaši, ja tie nav saistīti ar ļoti iedarbīgām funkcijām. No otras puses, mazie PR tiek pārskatīti ātri, jo tie prasa mazāk recenzenta laika un ir mazāk traucējoši. Šis pārskatīšanas ātrums var būt izšķirošs, lai ievērotu projekta termiņus; Esmu redzējis, ka projekti tiek aizkavēti, jo vecākie recenzenti nevarēja atvēlēt laiku masveida PR (lai gan tas var notikt ar maziem PR, risks pēc būtības ir lielāks ar lieliem PR). Mazāks pārstrādājums: Liela PR pārstrāde pēc dizaina izmaiņām ir kā klāja krēslu pārkārtošana uz kuģa, kuru tikko pabeidzāt būvēt... un pēc tam to nogremdēt. Mēs visi esam pieredzējuši situācijas, kad kāds PR pārskatīšanas laikā saprot, ka cits dizains būtu bijis labāk apkopjams un drošāks nākotnei, un mums ir jāpavada papildu laiks, lai pārstrādātu PR, pamatojoties uz jauno dizainu (lai neteiktu, ka viņi bija pilnībā iedomājušies ar dizainu, kas sākotnēji tika ieviests :p). Tas ir ļoti dabiski, jo dažreiz lietas kļūst skaidrākas, tiklīdz redzat, ka tās ir rakstītas kodā, un jūs sākat pamanīt aspektus, kurus, iespējams, esat palaidis garām projektēšanas posmā. Izmantojot lielus PR, tā var būt nopietna problēma, jo jums ir jāpārstrādā daudzi elementi, bet ar mazākiem PR ir vieglāk veikt izmaiņas. Vēl svarīgāk ir tas, ka ir mazāka iespēja pārstrādāt, jo recenzenti, visticamāk, identificēs problēmas agri un risinās tās sākotnējā PR, ļaujot turpmākajiem PR balstīties uz jaunajiem dizainiem. Labāka pārbaude: Mazāki PR sniedz labumu arī jums kā PR autoram. Tie palīdz pakāpeniski pārbaudīt mazākas izmaiņas, nevis pārbaudīt visu projektu vienā piegājienā. Pārbaudot mazākas izmaiņas, tiek nodrošināta pilnīgāka katra sistēmas komponenta pārbaude, tādējādi radot mazāk ražošanas kļūdu. Tas attiecas gan uz automātiskajām pārbaudēm, gan manuālo testēšanu, ko veicat jūs vai īpaši kvalitātes nodrošināšanas inženieri. Turklāt mazāki PR samazina iespējamību, ka testa gadījumi netiks izlaisti, jo varat koncentrēties uz ierobežotu darbības jomu, nevis visu sistēmu. Pārbaudījumu rakstīšana? Tā izklausās pēc Future Me problēmas. Esmu redzējis, ka izstrādātāji (arī es agrāk) vilcinājās rakstīt automatizācijas testus, jo tiek ieguldīts laiks bez tūlītējas, “redzamas” funkcijas/produkta vērtības. Mazāki PR samazina šo berzi, ierobežojot nepieciešamo testu skaitu un to rakstīšanai pavadīto laiku. Vienkāršāka atkļūdošana: Neatkarīgi no tā, cik rūpīga ir jūsu pārbaude, ražošanas kļūdas notiks! Iespēja atkļūdot kļūdu ražošanā ir ļoti svarīga, jo ražošanas kļūdas tieši ietekmē lietotājus, uzņēmumu vai abus. Ar lieliem PR arī izmaiņu virsmas laukums ir liels, tāpēc tas aizņem laikietilpīgu un sarežģīti atrast problēmu galveno cēloni. No otras puses, mazāki PR satur mazāk koda un tādējādi padara atkļūdošanu daudz ātrāku. Mazu izmaiņu atkļūdošana ir kā drukas kļūdas atrašana; lielo izmaiņu atkļūdošana ir kā enciklopēdijas korektūra. Funkciju pakāpeniska izvietošana: Visbeidzot, mazāki PR ir noderīgi arī jūsu produktu vadītājam un lietotājiem. Izmantojot mazus PR, jūs varat nepārtraukti virzīt sistēmas daļas uz ražošanu, kas palīdz iegūt agrīnu atgriezenisko saiti no lietotājiem un ļauj agrīni koriģēt kursu, ja nepieciešams. Agrīnas atsauksmes izlaišana ir kā piecu ēdienu maltītes gatavošana, neko nepagaršojot — jūs vienkārši cerat, ka tā nav katastrofa. Mazo sabiedrisko attiecību priekšrocības ir daudzas, un iepriekš minētie punkti ir vieni no ietekmīgākajiem, ko esmu pieredzējis personīgi. Ja esat saskāries ar citām mazu PR priekšrocībām vai izaicinājumiem ar lielākiem, ko es neesmu apskatījis, komentējiet savus ieskatus. Es ceru, ka šis raksts motivēs jūs pieņemt mazākus PR. Ja jūs jau esat iesaistījies, es ceru, ka tas pastiprinās šīs prakses vērtību. Paldies, ka izlasījāt, līdz nākamajai reizei, turpiniet kodēt un esiet zinātkārs!
