Hogy néz ki egy programozó munkája?

Általában reggel 8 és 9 közt érnek be az emberek, én 7:40 körül szoktam bent lenni. 9 órakor van egy stand up meeting, ami fél órás. Ekkor felállunk kör alakba, és mindenki kap három kérdést:

- Mit csináltál tegnap?

- Mit fogsz ma csinálni?

- Van-e bármilyen dolog, ami akadályoz téged a munkádban?

Ez a gyakorlatban úgy néz ki, hogy:

"Nos, én tegnap elkezdtem dolgozni az adatmigrációs jegyen. Tegnap utánanéztem az adatok formátumának, hogy melyik adat milyen más adatokkal áll kapcsolatban, amelyeket esetleg frissíteni kell. Emellett a migrációs program alapjait elkészítettem, képes vagyok kiolvasni az adatbázisból az adatokat. Ma azzal haladok tovább, hogy a program az exportált CSV alapján felül tudja írni az adatbázist. Viszont beszélni kellene még Pistivel az elképzelésem hatékonyságával kapcsolatban, mivel úgy néz ki, hogy milliárdnyi rekordot érint ez a frissítés, és nem volna hátrány, ha a prod rendszer mögötti adatbázist nem terhelné le nagyon erre az időre."

Ezt követően kimegyünk kávézni (én kólázni) a kollégákkal. Megy a beszélgetés és a hülyeség ezerrel, majd nekiállunk a munkának. Úgy 10:30 körül szétnézünk a közeli éttermekben, hogy hol van finom napi menü, majd 11:15-kor elmegyünk kajálni. Ez eltart 12:30-ig. Utána folytatjuk tovább a munkát, én 16:30-ig szoktam bent lenni.

A feladatokat egy Jira nevű jegykezelő rendszeren kapjuk. A cég többi dolgozója, például a tesztelők ide veszik fel a bugokat, feature igényeket, stb. Egy ilyen jegy tartalmazza a probléma/feature részletes leírását, hogy melyik verzióban tapasztalták, melyik verzióban kell készen lennie, ki vette fel a jegyet, ki dolgozik rajta, milyen állapotban van a jegy (felvéve->nyitva->fejlesztés alatt->tesztelés alatt->leszállítva->lezárva). Például így:

Típus: Szoftverhiba (bug)

Felvette: Kiss István

Dolgozik rajta: Nagy Béla

Érintett verzió: 17.3.5

Verzió, amelyben javítva lesz: 17.3.6

Állapot: Fejlesztés alatt

Leírás: A szoftver a jelszavakat SHA-1 algoritmussal hashelve tárolja. Ez ma már nem biztonságos, ezért át kell állni egy biztonságosabb algoritmusra (pl. SHA-512) és sózást is használni kell. Ezt az átállást a felhasználó bejelentkezésekor kell megtenni.

Megjegyzések:

Példa Réka, 2017. 09. 08. 11:25

Az adatbázisban nincs tárolva a jelszó eltárolt hash-ét előállító algoritmus neve. Ezt szintén tárolni kellene, hogy később gördülékenyebben lehessen átállni egy új titkosítási módszerre.

Kocsis Géza, 2017. 09. 08. 12:11

Réka javaslatát meg kellene vitatni biztonsági szempontból. Erről összeírtam egy meetinget 2017. 09. 09. 14:15-től a tárgyalóban. Addig is elő lehet készíteni egy absztrakt megoldást (pl. interfészeket definiálni és azok alapján megírni a működést).

Git verziókezelőt használunk Bitbuckettel. Ha a branch, ami a verziót tartalmazza, mondjuk 17.3.5, és van egy bug report, ami a Jira-ban az XAP-1745 számot kapta, azzal kezdünk, hogy a 17.3.5-ös ágból csinálunk egy új branch-et bugfix/17.3.5/XAP-1745 néven. Megcsináljuk a feladatot, majd automata tesztet futtatunk (amiről screenshot készül) és commit-olunk. Ezt követően egy pull request-et hozunk létre, ami tartalmazza a tesztfuttatásról készült screenshot-ot és egyéb megjegyzéseket. Ezt követően megadjuk az embereket, akiknek a kódot review-olni és tesztelni kell (legalább egy fejlesztő és egy tesztelő átnézi), majd ezek közül, aki szabad, átveszi a jegyet és elkezdi átnézni/tesztelni. Ha minden rendben van, ezek az emberek approve-olják a pull request-et és a csapatvezető merge-eli a branchet a főágba, amiből származtatva lett.

Fontos megjegyezni, hogy ez egyfajta megközelítés, amit #1 leírt, van ahol sokkal kevésbé van regularizálva az ilyesmi. Ahol jelenleg dolgozok, ott pl ticketing rendszert sem használunk, a különböző projektek nagyvonalú tervezetét táblázatban, a részleteket verbálisan tartjuk számon. Nincs napi szinten számon kérve, hogy ki mit csinált, amíg halad a munka ahogy kell. Általában csak nagyvonalú feladatleírást kapunk (kéne valami ami valamit csinál), a részletek kidolgozása, és megvalósítása ránk van bízva. A munkaidő is rugalmasan van kezelve, újfent, 'amíg haladunk, mindegy' alapon.

Persze ez egy kis létszámú cég, az ilyen helyeken lazábbak szoktak lenni a dolgok. Mondjuk voltam már olyan helyen is, ahol szintén alacsony volt a létszám, mégis nagyon szigorú rendszer szerint dolgoztunk. Helye válogatja.

Nálunk valamivel lazább rendszer van, mint az #1-nél. Heti egy meeting van, ahol beszámolunk, ki hol tart. A feladatok kiosztására TFS-t használunk. Itt kapom meg a bugokat és a taskokat. (bug: javítanivaló, task: új fejlesztés). Ha új fejlesztés van, akkor ahhoz kapok rendszertervet, melyben változó részletességgel le van írva, hogy mit kell csinálni. Tervezőtől függően itt lehetnek adatbázis tervek, képernyőtervek vagy csak 2 mondat arról, hogy pl. kell egy új form, amin a felhasználó jelszót tud változtatni. Ha valami nem világos, akkor beszélek az illetékes tervezővel, ő elmagyarázza. Ha szakmai kérdésem van, akkor megpróbálok pár másodpercet rabolni valamelyik architect életéből. Ha kész vagyok, a TFS-en ezt jelzem és a tervező megnézi. Ha valami még nem tetszik neki, akkor visszadobja, ha minden ok, akkor megy a tesztrendszerbe és a tesztelők letesztelik. Utána a következő frissítéssel kitelepül az éles rendszerbe. Néha van code review, bár egyre ritkább, ez inkább az elején volt, amikor kezdtem a munkát. Ilyenkor az architect lefikázza a kódodat és elmondja, hogy amit leírtál 50 sorban, azt hogy kell egy sorban megírni.

Általában 8-9 között érek be, fél12-fél1 ebéd és fél4-fél5 között megyek haza, munkától és kedvtől függően. Szoktunk tartani két félórás kávészünetet is, délelőtt és ebéd után valamikor. Persze ha van egy kritikus hiba, aminek másnapra működnie kell, akkor előfordul, hogy 8-9-kor is még benn vagyunk vagy otthon este még előszedjük a melót. De ilyen egy évben 2-3 van. Mivel kötetlen a munkaidő, ezért néha otthonról dolgozok, ilyenkor írok reggel egy emailt a projektvezetőnek, hogy ma nem megyek be.

Nálunk sokáig nem volt standup, mostanában kezdtünk visszatérni hozzá, viszont nálunk 10:40-kor van, 10 és 11 között érnek be az emberek kb.

De több csapat van, mindenki máshogy csinálja.

Ticketek vannak jira-ban, viszont szintén a csapat mostanában a github issue trackert használja inkább.

Heti 1x van sprint planning, amikor megtervezzük, hogy a következő héten mikkel kellene foglalkozni kb a ticketek közül.

Juniorként egy kicsit másként fognak telni a napjaid, mint a csapat többi tagjának, feltéve hogy nem egy olyan cégnél dolgozol majd, ahol eleve több a junior, mint a senior.

Nagy eséllyel fogsz kapni egy mentort vagy valakit, akit zavarhatsz a kérdéseiddel és aki naponta 2-3 alkalommal rád néz, hogy mennyire tudtál haladni a feladatoddal. Ennek a célja, hogy nagyon korán észrevegyék, ha rossz irányba indulsz el egy feladat megoldása során, ami egyébként elég gyakori a junioroknál. Tipikus hiba, hogy bonyolultan oldják meg a rájuk bízott feladatokat. Ne lepődj meg, ha többször újrairatják veled ugyanazt a feladatot, persze kapsz majd iránymutatást is, hogy inkább merre indulj. Az tuti, hogy nem lesz számodra olyan aprólékosan lebontva egy feladat, hogy csak egy class-t kelljen bepöccinteni a helyére. Neked kell rendelkeznek azzal a képességgel, hogy egy összetett problémát kisebb részproblémákra tudj bontani. Ami még előfordul kezdőknél és harapunk érte:

- Nem oldják meg a problémát teljes egészében, hiába van leírva nekik. Konkrétan a megoldásuk nagy részben lefedi a feladatot, de kihagynak edge case-ket.

- Nem próbálják ki, amit csináltak. Sokszor el sem indul a program a módosításaikkal, exceptionnel elszáll valami triviális hiba miatt.

- Nem tesztelik le kézzel, amit csinálnak. Ne kelljen már pingponzni a tesztelő és a fejlesztő között.

- Nem tesztelik le automata tesztekkel, amit csinálnak. Eleve nem automatán tesztelhető kódot írnak.

Amúgy egy átlagos nap a csapatunk életéből:

Nagy nehezen beesik mindenki 9 és 10 között. Ekkor daily standupot tartunk, ahol mindenki elmondja mivel hogyan haladt, kell-e segítség és mit fog ma csinálni. A megoldandó feladatokat jira-ban követjük. Amikor egy jira ticket beesik a csapathoz, akkor valami nagyon felszínes leírást kapunk arról, hogy mit szeretne a kliens. Mivel az utóbbi években leépítették a business analysteket a projektekről, ezért valamelyik fejlesztő átnézi a feladatleírást, összegyűjt rengeteg kérdést majd e-mailben, chaten vagy telefonon megbeszéli a részleteket a klienssel, hogy pontosabb képet kapjunk. Később a részleteket átbeszéli a csapat egy meetinget, heti két alkalommal, majd fejlesztésre késznek nyílvánítjuk. Ha valaki már jól átnézett jira ticketet kap, akkor nekiállhat kódolni. Mivel a BA részhez hasonlóan erős tendencia mutatkozik a tesztelők leépítésére is, ezért a fejlesztők írják az automata teszteket is (nem csak unit test szinten).

Napközben egy csomó más meetingen kell még részt venni. Mi olyan alkalmazásokat fejlesztünk, ami egy bazi nagy pipeline közepén ül, így a legtöbb módosítás esetén kommunikálni kell földrajzilag máshol dolgozó csapatokkal, akik az előttünk és utánunk csücsülő appokat tutujgatják, nehogy összeboruljon a pipeline valami új feature-től.

Ha valami olyat kér a kliens, ami időigényes vagy jelentős refactorálást igényel, akkor egy ember alaposan átnézi mely részeket kéne átírni, majd egész csapatos brainstorming meetinget tartunk, ahol átnézzük, hogyan lehetne a legegyszerűbben a legkisebb kockázat mellett implementálni a megoldást. Bár az egész csapat belekotyoghat, valójában megvan az az 1-2 ember csapatonként (általában 7+ év tapasztalat, de nincs spéci rangjuk, mint architect vagy ilyesmi), akik a helyes irányba lökik a többieket, mert amúgy mezítlábas seniorok hajmeresztő ötleteket dobnak be ilyenkor.

Van még egy csomó részlet, ami nem annyira érdekes számodra kezdőként (demo, release magnagement, branching strategy stb). Ha érdekel olvass utánna a scrumnak, agile developmentnek.

A mire gyúrjak kérdésre meg röviden: Figyelj a részletekre, ne okozz bugokat, tudj angolul a külföldi kollágákkal és a klienssel beszélni, tanuld meg használni az OOP-t és design patterneket, mert nagyon sokan nem tudják alkalmazni, csak sacc kb van valami képük az egészről.