Projektin suojakaiteet: tuotantoon kirjoittaminen
Muutamassa aiemmassa artikkelissa olen puhunut parista asiasta (säilytetty tuotantoon kirjoittamista varten), jotka auttavat onnistuneen projektin toteuttamisessa:
- Vaarat " komitean suunnittelemassa "
- Ympäristön luomiseen liittyviä näkökohtia .
Viimeinen asia, jonka haluan käsitellä tähän mennessä kokemaani oppimiseen, on sananlaskujen avaimien säilyttäminen kirjoittamisen valtakuntaan tuotantoon ja miksi sillä on merkitystä.
Kirjoittaminen tuotantoon
Ajatus tuotannolle kirjoittamisesta saattaa tuntua mainituista dogmaattisimmalta suojakaiteelta, koska se on yleensä ok niille, jotka rakentavat ratkaisua ja he tietävät sen toimivuuden yksityiskohdat.
Muut sidosryhmät eivät todennäköisesti tee sitä (mutta jos he tekevät niin ja kehitystiimi on kunnossa, että muut käyttävät versionhallintaa tämän hoitamiseen, niin tee se).
Kenellä todella on lupa hallita näitä asioita?
Muista kuitenkin, kuten aiemmin tässä sarjassa mainittiin, tapa, jolla otamme käyttöön projektejamme, on nyt muuttunut niin, että meillä on usein jatkuva käyttöönotto ja jatkuva integrointi.
Ja usein nämä palvelut on kytketty lähdekoodivarastoon, kuten GitHubiin, ja viestijärjestelmään (joka puolestaan voi olla kytkettynä Slackiin, jota pidän hyödyllisenä).
Jotta tiimin ihmiset ovat tietoisia siitä, mitä on otettu käyttöön ja milloin, ja he tietävät, kuinka saada koodi (joka on arkistosta, ei lataamalla sitä S/FTP:n kautta) tarvittaessa.
Kun hotfix-korjausta tarvitaan, menettelyn pitäisi silti olla käytössä. Ehkä joku on päivystyksessä, ja on olemassa prosessi, jolla käytetään haaroitusta, yhdistämistä, taggausta ja semanttista versiointia.
Siitä huolimatta, kyse ei ole niinkään siitä, kuinka prosessi toimii; se on, että se on paikallaan ja että sitä seurataan.
Tietenkään näitä asioita ei ole asetettu kehittämään monimutkaisempaa (vaikka ymmärrän kuinka se saattaa tuntua siltä). Se on päinvastoin. Se johtuu useista syistä:
- pitääkseen jatkuvan käyttöönoton, tiedättehän, jatkuvana,
- integroidut testit,
- mittaamaan jatkuvasti koodausstandardeja tai koodin laatua,
- estämään cowboy-koodauksen,
- ja enemmän.
Kyse ei ole niinkään muiden ihmisten pitämisestä poissa, mutta jos koodin työntäminen on kehittäjien vastuulla, pitäisikö kenelläkään muulla todella olla kirjoitusoikeus palvelimelle?
Ja se on ydin: Jos työskentelet tiimissä, jossa käytössäsi olevat prosessit voivat heikentää tekemäsi työtä, mikä on prosessin tarkoitus?
Koska milloin tahansa joku muu voi tulla mukaan ja tämä jättää huomioimatta kaiken, mitä olet tehnyt. Olet silloin ainakin:
- juuttunut siihen, että muutokset on vedettävä todennäköisesti S/FTP:n kautta,
- vertaa sitä erotustyökalulla haaraan, jolla joku työskentelee,
- toteuttaa muutokset (selvitä miksi ne on tehty),
- ja palaa sitten työhön vaatimusten parissa.
Se kuulostaa hektiseltä, kun sen niin ilmaistaan, mutta juuri niin tapahtuu.
Takeaway
Joten mikä on viimeisten viestien tarkoitus? Jos minun pitäisi tiivistää se mahdollisimman ytimekkäästi, se:
Kun kyse on projektista, tunne vastuusi äläkä astu niiden ulkopuolelle. Muuten vaarana on, että koko homma suistuu.
Tämä koskee kehittäjiä, suunnittelijoita, asiakkaita, markkinoijia, projektipäälliköitä jne. Sillä, miten roolit on nimetty, ei ole paljoakaan väliä (tarkoitan, yleensä on selvää, kenen pitäisi olla kuka yllä olevissa rooleissa), mutta tarkoitan kuka on koko projektin todellinen pistehenkilö – projektin omistaja.
Älä ole tällainen.
Ja riippuen siitä, kuinka kaikki edellä mainitut asiat etenevät, projekti voi olla suhteellisen yksinkertainen sarja päivittäistä työtä.
Niin paljon kuin mahdollista, emmekö halua nauttia siitä, mitä teemme