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í.