Organizace práce vývojářů
Ahoj. Pracuji ve velmi mladé, rozvíjející se firmě s mladým kolektivem (většinou 20 - 25 let), brigádníci a zaměstnanci dohromady. Firma vyrábí vlastní hardware. V týmu 10 lidí vyvíjíme firmware v C/C++, další cca desítka lidí vyvíjí serverové a desktopové aplikace. Dohromady to tvoří systém pro zákazníka. Ve firmě pracuji 6. měsícem a za tu dobu se dalo vypozorovat, že pokulhává organizace práce, dokumentování kódu i celých projektů atp. V některých věcech je slušně řečeno docela nepořádek, což brání efektivní práci. Na zadávání úkolů používáme Redmine, na zdrojové kódy SVN. Ve firmě je zájem toto zlepšit, ale nikdo pořádně neví jak.
Typický problém který nastává - kolega pracuje na části systému, po nějaké době dostane jiný úkol (který víc hoří), případně je nějakou dobu nepřítomen a někdo jiný by měl v jeho práci pokračovat. Ten, kdo práci převezme, má obvykle problém se v tom zorientovat. Firmware je hodně rozsáhlý. Stejně tak pokud přijde někdo nový a má se zapojit. Další problém bývá v testování - nikdo pořádně neví, jak správně testovat. Firmware se dá rozdělit na dvě části. Nízkoúrovňovou - v drtivé většině kód v C, spjatý s konkrétním HW a vysokoúrovňovou - kód v C++, abstraktnější, nezávislý na HW. V poslední době se snažíme C++ kód dokumentovat diagramy a testovat unit testy. Nízkoúrovňový kód se musí debugovat přímo na HW (např. vyčítáním registrů, sledováním signálu na logickém analyzátoru, osciloskopu atp.)
Chtěl bych se zeptat, jaké nástroje by se nám mohly hodit na lepší organizaci a dokumentaci? Je toho spoustu co zlepšovat, jsme v podstatě na začátku. Díky.
Správně napsané unit testy i dobře dokumentují samotný kód (viz behavior driven development).
Chování větších celků by pak měly popisovat testy, které provádějí testeři. Máte vůbec samostatné testery, nebo to testují sami vývojáři?
Děláte code review? Eviduje se kdo a komu to CR dělal?
Máte automatizované buildy? Víte hned, kdy build spadne - zejména když neprojdou testy?
Jo, unit testy nám to zpřehlednily hodně. Když někdo vyvine nějakou komponentu a napíše k ní testy, tak ostatní z toho snadněji pochopí, jak ji použít.
Samostatní testeři zatím nejsou. Je to na vývojářích.
Code review? Velmi neformálně. Tady je určitě velký prostor pro zlepšení.
Automatizované buildy jsou jen pro tu abstraktnější část v C++.
CR dokáže hodně zlepšit povědomí o práci ostatních.
U nás jsem si taky zavedli, že jednou za týden se tak cca na 30-45 minut všichni sejdeme a jeden či více lidí seznamují ostatní s nějakými zajímavými tématy. Může to být třeba to, na čem právě pracují - jaké problémy tam řeší/řešili, jaké slepé uličky při tom objevili atd. Nebo můžou představit nějakou použitou knihovnu, či to může být nějaké obecné téma, třeba jak psát efektivnější kód.
Jednou za dva týdny (máme dvoutýdenní "sprinty") pak představujeme funkcionalitu dokončenou v právě skončeném sprintu. Tam se to ale nepředstavuje z pohledu kódu, ale spíše uživatele. To je zase hodně užitečné pro testery a dokumentaci. Ale i vývojáři se něco dozvědí o částech aplikace, kam se obvykle nedostanou. Tyhle prezentance jsou vlastně i takový malý test, protože následující pracovní den se to prezentuje manažerům.
Pokud jde o testery, tak ty bych rozhodně doporučoval. Mají na aplikaci naprosto jiný pohled, který by vývojáře většinou nenapadl. A co ho nenapadne, to nepokryje. Tester dělá vše pro to, aby tu aplikaci "rozbil", což vývojář nedělá, protože ten naopak rád tvoří.
A v neposlední řadě jsou testeři i živoucí dokumentace celé aplikace. Protože s ní při testování neustále pracují, tak ji většinou velice dobře znají.
Mali by ste mat nejakeho projektoveho managera, ktory vie kto robi co robi a jak to robi. To je vec designu, pripravy. Jakym sposobom sa to popise je potom len na vas, bud len ako dokument slovne, alebo akokolvek graficky. Typicky sa robi dokument akoze specifikacia, kde sa specifikuje ze co nejaky komponent alebo neco/projekt ma robit, a jak.
V tom Redmine by ste to mohli mat rozkuskovane na body ze toto zmenit, hento zmenit, hento pridat, a tym padom jeden bod trva kratko a tda sa odfajfkovavat postupne, a ne ze 1bod na cely projekt, ze to jeden zapne v januari a odfakjuje v decembri :D K tym bodom sa daju potom pripadne dopisovat poznamky ze jak to je spravene a pripadne aj jake subory kvoli tomu menil, predtym nez to odfajkuje, apod. My pouzivame databazovy system na dokumentovanie zmien projektu, kde sa napise ze jaky projekt a co som menil preco som to menil a ktore subory, a nasledne si to vie ktokolvek query-ovat bud podla projektu vsetky zmeny alebo podla suboru apod. U nas je na to upraveny bugzero, ale existuje na to urcite kopa podobnych SW. Prinajhorsom sa to da pisat aj do xls sheetu pre dany projekt. V tom sa da aj vyhladavat potom podla cohokolvek, v ramci toho xls.
Ked niekto ide prec mal by sa dohodnut s tym nasledovnikom, povie mu toto uz je a toto treba dorobit, funguje to tak a tak tam na serveri je specifikacia.
Testy musi definovat ten kto definuje produkt, t.j. zas sme u specifikacie, a to vsetko co tam je napisane musi fungovat tak jak to tam je napisane. Nasledne uz ide len o ludi a o to jak presne tie testy implementuju, a o ich dovtipe ze ci to implementuju tak ze tym skutocne odhalia chyby skor jak zakaznik :)
No a komentare do kodu a celkovo kod by mal byt organizovany tak ze sa v tom niekto vyzna, to je potom len o ludoch. Aj ked checkinujes do SVN tak sa tam pise ze co sa menilo a preco, to tiez neflakat.
Viac neviem :)
P.S. a to co sa pise pri checkinovani do SVN, to tam ten SVN moze automaticky pridat do zdrojaku do hlavicky suboru, kde potom vidis vsetky verzie daneho suboru a u kazdej ten popis zmien co tam dotycny pri checkine do SVN napisal, to tak mate dufam.
Projektoví manažeři jsou dva, ale dělají kromě toho ještě x dalších věci, což IMHO není moc dobře. Jsou často příliš zaneprázdnění. Specifikace jde od nich.
Do Redminu se přidávají drobnější úkoly, požadavky, nahlášené chyby apod.
Když jde někdo pryč, tak by se měl opravdu podělit s ostatními, co (ne)dokončil. Ono to tak většinou je, ale spíše neformálně. Líbí se mi ten průběžný způsob popsaný v článku o Code reviews (reakce na Wikana).
Specifikace je známá a ví se, co to má dělat, ale jde spíš o nějaké rozumné testování dílčích částí, ze kterých je to postavené.
V SVN se dá samozřejmě zjistit, kdo jakou změnu kdy udělal (log, blame).
články na takové téma píše jiří knesl. sám něco vede, taky pořádá školení, pro pražáky to může mít smysl.
Díky za tip.