Projekti kaitsepiirded: kirjutamine tootmisse
Viimastes artiklites olen rääkinud paarist asjast (salvestatud tegelikuks tootmisse kirjutamiseks), mis aitavad edukat projekti läbi viia:
- Ohud " komisjoni poolt kujundatud "
- Kaalutlused keskkonna loomisel.
Viimane asi, mida ma seni kogetud õppimisega tahan käsitleda, on vanasõnavõtmete säilitamine kirjutamise ja tootmise kuningriigis ja miks see on oluline.
Tootmisse kirjutamine
Tootmisvormi kirjutamise idee võib tunduda mainitute seast kõige dogmaatilisema kaitsepiirdena, sest see on tavaliselt okei neile, kes lahendust loovad ja nad teavad selle toimimise üksikasju.
Teised sidusrühmad tõenäoliselt seda ei tee (aga kui nad seda teevad ja arendusmeeskonnaga on kõik korras, et teised kasutavad selle lahendamiseks versioonihaldust, siis laske käia).
Kellel on tõesti luba seda kraami hallata?
Pidage siiski meeles, nagu selles seerias varem mainitud, viis, kuidas me oma projekte juurutame, on nüüdseks muutunud nii, et meil on sageli pidev juurutamine ja pidev integreerimine.
Ja sageli on need teenused ühendatud lähtekoodihoidlaga, näiteks GitHubiga, ja sõnumsidesüsteemiga (mis võib omakorda olla ühendatud Slackiga, mis minu arvates on kasulik).
Et meeskonnaliikmed oleksid teadlikud sellest, mis ja millal on juurutatud, ning teaksid, kuidas vajadusel koodi hankida (mis pärineb hoidlast, mitte S/FTP kaudu allalaadimisest).
Kui kiirparandust on vaja, peaks protseduur siiski kehtima. Võib-olla on keegi valves ja on olemas protsess, mille käigus kasutatakse hargnemist, ühendamist, märgistamist ja semantilist versiooni.
Sellest olenemata ei ole asi niivõrd selles, kuidas protsess toimib; see, et see on paigas ja et seda järgitakse.
Muidugi pole need asjad paika pandud selleks, et arendust keerulisemaks muuta (kuigi ma saan aru, kuidas see nii võib tunduda). See on vastupidi. See on erinevatel põhjustel:
- et hoida pidevat kasutuselevõttu, tead, pidev,
- integreeritud testid,
- kodeerimisstandardite või koodikvaliteedi pidevaks mõõtmiseks,
- et vältida kauboide kodeerimist,
- ja veel.
Asi pole niivõrd teiste inimeste eemal hoidmises, vaid kui koodi surumise eest vastutavad arendajad, siis kas tõesti peaks kellelgi teisel olema serverile kirjutamisõigus?
Ja see on lõpptulemus: kui töötate meeskonnas, kus teie paigas olevad protsessid võivad teie tehtavat tööd täielikult õõnestada, siis mis on selle protsessi eesmärk ikkagi?
Sest igal hetkel võib keegi teine tulla ja see eirab kõike, mida olete teinud. Sa oled siis vähemalt:
- ummikus muudatuste tõmbamine tõenäoliselt S/FTP kaudu,
- võrrelda seda diferentseerimistööriista abil haruga, mille kallal keegi töötab,
- muudatused ellu viima (lase uurida, miks need tehti),
- ja seejärel naasta nõuete kallale.
See kõlab niimoodi öeldes kirglikult, kuid täpselt nii see juhtub.
Takeaway
Mis on siis viimaste postituste eesmärk? Kui ma peaksin selle võimalikult lühidalt kokku võtma, siis:
Kui tegemist on projektiga, teadke oma kohustusi ja ärge astuge neist välja. Vastasel juhul võite kogu asja rööpast välja lüüa.
See kehtib arendajate, disainerite, klientide, turundajate, projektijuhtide jne kohta. See, kuidas rollid on määratud, ei tea suurt tähtsust (ma pean silmas seda, et tavaliselt on selge, kes peaks olema kes ülaltoodud rollides), kuid ma pean silmas kes on kogu projekti tegelik point isik – projekti omanik.
Ära ole selline.
Ja sõltuvalt sellest, kuidas kõik ülaltoodud toimib, võib projekt olla suhteliselt lihtne igapäevatöö.
Nii palju kui võimalik, kas me ei taha nautida seda, mida teeme