Kuidas ja miks me õpetame mitteinseneridele GitHubi kasutamist lõimes

Thread'is on üks meie põhilisi veendumusi, et tehnoloogia võimaldab suuri muutusi. See on oluline meie toote jaoks, kuid oluline on ka see, kuidas me sisemiselt töötame.

Selle tööviisi tõttu püüame kajastada kõike andmete osas - tooteid, mõõtmeid, stiile, tarnijaid, meie lao asukohti, toetada piletite eraldamist ja palju muud, millele te isegi ei mõtleks.

Kõigi nende andmemudelite puhul on vaja maksta viis ettevõtte jaoks, kes neid andmete säilitamiseks kasutab. See tähendab redigeerimisliideste loomist koos valideerimise, andmebaasi kujundamise ja esiotstarbelise tööga. Sageli pole meil lihtsalt aega selleks teha - uued funktsioonid on kõrgema prioriteediga ja peale selle saab insener värskendada lihtsalt mõnda andmefaili, kui seda vaja on?

Ehkki see on lühikese aja jooksul palju kiirem lahendus, peab insener kontekstist välja lülitama oma töö, jälgima, et väljaanne läheks välja ja veenduma, et midagi valesti ei lähe - see kõik kahjustab tootlikkust. Võib-olla veelgi olulisem: inimesel, kes vajab andmete värskendamist, ei ole enam kogu protsessi omandit ja nad sõltuvad kellegi teise ajakavast.

Lõppkokkuvõttes võib see protsess olla kasulik, et funktsioon kiiresti uksest välja saada, kuid põhjustab pikaajaliselt töötamiseks liiga palju hõõrdumist.

Parem lahendus

Ma mäletan, kui GitHub esimest korda nende veebiredaktori käivitas - mulle ei avaldatud sellest muljet. Miks peaks keegi veebibrauseris koodi muutma? Miks ma peaksin kasutama redaktorit, mis suudaks muuta ainult ühte faili ühe pühendumise kohta? Aastaid hiljem sain aru, et ma pole toimetaja sihtturg.

Thread'is õpetame nüüd regulaarselt insenerimeeskonnast väljuvatele inimestele, kuidas GitHubi veebiliidese kaudu oma andmebaasi anda, et nad saaksid tõhusalt töötamiseks vajalikke andmeid värskendada.

Nüüd on meie põhikoodide andmebaasi kaastöötajaid olnud rohkem kui mittetehnilisi rolle, kui kõigil inseneridel ja töövõtjatel, kes on aastate jooksul oma panuse andnud.

Kas see on töötanud?

Tootemeeskonna insenerina saan keskenduda rohkem oma klientidele kasulike omaduste loomisele ja mõõdikute liigutamisele, selle asemel, et luua rohkem CRUD-liideseid. Samuti on mul võimalik saata A / B-teste kiiremini, kuna sageli võime prooviversiooni sisemised tööriistad vahele jätta, eelistades andmete muutmist andmefailide kaudu. Projekti edastusfaasi jõudes saame selle aja redigeerimisliidestesse panna, kuna meil pole mitte ainult ettekujutust funktsiooni väärtusest, vaid ka paremat ettekujutust sellest, kuidas meie sisemised kasutajad sooviksid liidesed tööle.

Samuti pole see piiratud andmefailidega; paljud saidi thread.com lehed on sisuliselt staatilised HTML-id, sellised lehed nagu meie kohaletoimetamise KKK, tagastamispoliitika või tingimused. GitHubi kasutamist õppides suudab meie operatsioonimeeskond neid ajakohasena hoida ilma abi küsimata. Meie talguliste meeskond on võimeline redigeerima ka meie töökohtade saiti, reageerides igapäevaselt kandidaatidega vesteldes kerkivatele küsimustele.

Kõik see tähendab, et meie meeskonnaliikmetel väljaspool insenerimeeskonda on oma töö üle palju suurem vastutus ja neil on vähem hõõrdumist muudatuste tegemiseks, mis nende kogemuste kohaselt on vajalik.

Kuidas me seda teeme?

Esimene asi, mida me teeme, on GitHubi õpetuste käitamine iga kord ja jälle, kui meil on mõni uus alustaja, keda õpetada. Me katame põhialused, mis on hoidla, võrreldes seda dokumentidega redigeerimise ajaloo Google Docsis, mida tähendab faili loomine ja mis on haru. Räägime neist ainult kõrgetasemelistel viisidel, kuna me ei kata käsuribaliidest meie praeguses õppevormingus üldse.

Järgmisena uurime, kuidas redigeerida faili GitHubi veebiliideses, kuidas kirjutada manustamissõnumit, mis on tõmbetaotlus ja mida tähendab Jenkinsi ehituse oleku aruandlus.

Lõpuks palume mittetehnilistel toetajatel valida insener, kes on saadaval Slackis, et vajutada liitmisnuppu, kui ehitamine on roheline.

Probleemid, millega oleme kokku puutunud

Kokkuvõttes leiame, et see on meeskonnale tervikuna tohutu võit. Plaanime koolitusi jätkata ja julgustada kasvama panustades ka uusi panustajaid, kuid oleme oma toimimisprotsessi pisut muutnud.

Esiteks oleme GitHubi rolle ja lukustatud harusid kasutanud, et vältida juhuslikke juhtumisi meistriks saamist. Inimeste jaoks, kes pole versiooni juhtimisega ja eriti harudega nii tuttavad, pole GitHubi veebiliides eriti selge, millal toimub üleandmine harule või uuele harule. Threadis töötab meie peaharu pidevalt, ilma et oleks vaja käsitsi sekkumist, mille tulemuseks oli mitu kohustust välja minna, mis saidi purustas ja seisakuid põhjustas.

Nagu kõigi seisakuprobleemide puhul, juhtisime 5 viit süütuid ja mõistsime, et kuigi tagantjärele võinuksime need probleemid enne kasutuselevõttu toimuvate ühikatsetustega kinni püüda, ei saaks me tõenäoliselt kõike ja seega kaitstud harude tutvustamine koodide ülevaatamise soodustamiseks oli kerge. viis probleemi lahendamiseks.

Teiseks, mõnevõrra vastusena sellele probleemile, oleme hakanud kirjutama üksuseteste, mis kontrollivad lihtsalt andmefailides sisalduvate andmete mõistust või kontrollivad, kas kõik meie Django mallifailid parsivad edukalt kehtivate mallidena. Eriti andmefailide puhul poleks need tavaliselt midagi, mida me eeldaksime testimiseks, kuid kuna soovime, et failid oleksid inimeste jaoks, kes koodi ei tunne, redigeeritavaks, on neist abi lihtsate vigade leidmisel. .

Lõpuks, kuna me kasutame oma andmefailide jaoks tavaliselt Pythoni, leidsime, et süntaks pole eriti intuitiivne ja seetõttu on vaja harjumist. Selle probleemiga tegelemiseks on meil kirjalik dokumentatsioon, mis on pisut üksikasjalikum kui siis, kui see oleks kirjutatud insenerile. Ka see dokumentatsioon on repos ja igaüks saab seda redigeerida, seetõttu soovitame inseneridel, kes pole insenerid, õpitud juhiseid värskendada ja täpsustada ning õpetada üksteisele saidi teatud osi redigeerima.

Edasi liikuma

Peame seda katset õnnestunuks ja jätkame seda lähitulevikus. Kui kavandame andmefailide redigeeritavuse, proovime lisada failidesse üksikasjalikud juhised, sealhulgas kopeeritavad / kleepitavad näited.

Proovime juba teha proovitõrgete jaoks informatiivseid tõrketeateid, kus on täpsustatud, kuidas saaksime parandada, kuid testi väljundi tõlgendamise keerukuse tõttu ei paljasta me Jenkinsi praegu mittetehnilise meeskonna liikmetele, ehkki nad tehniliselt suudavad logige sisse ühekordse sisselogimisega. See on võib-olla järgmine võimalus, mida peame panustamiskogemuse parandamiseks pakkuma, ja midagi, mida võiksime proovida järgmiste uute juhendajate seas, kes õpivad läbi.

Lõpetuseks soovitaksin kõigil arendajatel uurida, kas teie ettevõtetes on võimalusi saada mittetehnilisi meeskonnaliikmeid teie koodialustesse panustama. Mõlemal poolel on tootlikkusele eeliseid, meeskondade vahel on rohkem empaatiat ja tööl on suurem vastutustunne nende jaoks, kes enam ei looda, et arendajad nende jaoks muudatusi teeksid. Vähendatud hõõrdumine tähendab ka lühemaid tagasisidetsüklit, mis võib olla muudetav selle jaoks, mida teised saavad oma tööga saavutada, ja seda kõike ilma liideste redigeerimise jaoks kulutatavate suurte kuludega.