Vzhledem k tomu, že se jedná o první teamový projekt na VUT FIT (3. semestr), tak si myslím, že spíše než popis tvorby interpretu by se hodilo mým nástupcům pár rad o tom, jak pracovat v teamu. Jedná se totiž o něco zcela diametrálně odlišného, než na co jste byli zvyklí doposud. Ať už jste v prvních dvou semestrech programovali na fakultě cokoli, tak stačilo dodržet zadání a základní programátorské zvyky a s projekty nebyly problémy (tedy byly, ale to se týkalo spíše technického hlediska).
Jak tedy projít IFJ? V první řadě si sežeňte kvalitní team. Nejlépe do toho jděte s lidmi, které znáte a o kterých víte, že na tom projektu budou opravdu pracovat. Pokud budete míst smůlu a zbyde na vás banda nespolehlivých „vocasů“, tak je jedno, jak dobří jsou to programátoři. S tímto projektem neuspějete. Viděl jsem na vlastní oči, jak team celkem dobrých programátorů ještě tři týdny před odevzdáním projektů plánoval a jen povídal o tom, že „za pár dní se do toho pustíme“ a týden před konce začali a zjistili, že je čeká tolik problémů, že nemají šanci. Nakonec dostali tak málo bodů, že jim to nestačilo ani na zápočet.
Další, co je potřeba udělat, tak je zvolit si vedoucího teamu. Pokud nechcete práci navíc a nevěříte si na to, tak do toho ani nejděte. Mohlo by to dopadnout špatně. Na druhou stranu pokud o sobě víte, že jste spolehlivý, věříte si a nechce se vám další rok IFJ opakovat, tak s chutí do toho. Lepší je mít více práce a starostí a mít jistotu, že se bude doopravdy pracovat, než toto místo přenechat někomu, kdo ani neumí komunikovat s lidmi, jeho spolehlivost se blíží nule a chce tuto pozici jen proto, že si myslí, že se bude moci ulívat. Pokud vás povede takový člověk, tak je šance na úspěšné odevzdání projektu mizivá a i toto se už pár teamům stalo.
Co se také nesmí podcenit je začátek prací. Co nejdříve si v teamu rozdělte úkoly. Pokud jste vedoucí a znáte svůj team, vezměte si tužku a papír a udělejte rozpis toho, co kdo bude dělat. Abych se přiznal, tak tato práce mi trvala skoro dvě hodiny. Musel jsem si prostudovat strukturu programu/projektu zhodnotit obtížnost jednotlivých částí a poté se rozhodnout co komu přidělit. Tuto část se opravdu nevyplácí podceňovat a prodiskutovat s ostatními. U rozdělování prací zohledněte také charakterové vlastní, časové možnosti a schopnosti lidí v teamu a zeptejte se, kdo by si, co přál dělat. Pokud je v teamu někdo, kdo rád odkládá povinnosti, tak mu dejte práci, která se dá dělat už od začátku, a dohlížejte na něj. Když máte někoho schopného, dejte mu těžší část, pokud někdo studuje další školu a nemá moc času, nechte ho dělat dokumentaci a testovací skripty. A pokud opravdu chcete mít přehled o tom, jak se projekt vyvíjí, tak si jako vedoucí vezměte na starost programování syntaktického analyzátoru. Vzhledem k tomu, že se v tomto projektu jedná o syntaxí řízený překlad, tak budete mít přehled opravdu o všem. Od parseru až po interpret a datové struktury.
Syntaktická analýza je obecně nejtěžší a nejkomplexnější část projektu a skládá se ze dvou částí. Rekurzivního sestupu, kde se implementuje gramatika a vše se řídí a vyhodnocování výrazů, které je s první částí úzce propojeno. Pokud si zvolíte syntaktickou analýzu, tak vřele doporučuji dát vyhodnocování výrazů někomu, s kým jste v neustálém kontaktu. Nejlépe, pokud s vámi bydlí přímo na koleji/bytě. Bude určitě často konzultovat a měnit spoustu věcí.
Pokud vám jde projet +- zdárně a už budete pomalu končit (blíží se termín odevzdání), ověřte si, že člověk, který pracuje, na interpretu ví, co dělá a jak to navázat na syntaktickou analýzu. Ono je totiž poměrně nepříjemné 3-4 dny před odevzdáním, že člověk, který má na starosti interpret se inspirovat projekty z minulých let do té míry, že výsledek jeho práce není ve vašem projektu zrovna dvakrát použitelný. Potom vás totiž čekají 3 dny zavřených na kolejích (4 lidi) a pracujících do 5 do rána. A toto je opravdu zabijácký způsob „dokončování“ projektu.
V takovémto nasazení se opravuje, buší kód a vymýšlí, jak to jen jde a na takové věci, jako korektní uvolňování paměti už nezbývá moc času. A všichni víme, jak to je s C. Navíc u takového složitého projektu je velice obtížné udělat korektní uvolnění paměti. Naštěstí někdo v teamu (myslím, že spolubydla) dostal nápad udělat garbage collerctor. A on to je opravdu hodně dobrý nápad. Trvalo mi jen hodinku – dvě než jsem naprogramoval vlastní GC a výsledek… „no leaks are possible“. Tedy naprosto elegantní zabití hromady much jednou ranou.
A ještě jedna užitečná rada:
Udělejte si automatické testovací skripty a vyčleňte jeden výkonnější NB nebo server k nepřetržitému testování u ladění programu. V tak složitých programech stačí změnit jednu řádku kódu, o které si myslíte, že nic neovlivní a za pár hodin se divíte, jak tam vznikla nějaká skrytá chyba, která tam předtím nebyla.
Good luck/Have fun pro mé nástupce v dalších letech. ;-)
Dokumentace:
https://docs.google.com/open?id=0BzEavpv8QogcMmRiNWU0NzYtY2M2YS00YzI1LWE0MzgtNzhjNzZiMjk1ZTRj
Download project: https://docs.google.com/open?id=0BzEavpv8QogcZGExOWM2NmEtMWRjMS00NTkzLTlkYmYtNjc3YmQzMGIzODRl
2 komentáře:
Díky, skvělé shrnutí. Určitě se příští rok bude hodit, stejně jako se letos hodilo shrnutí semestru prvního.
Jen ještě doplňující dotaz k IFJ – jak velké jsou týmy pro skupinový projekt? A rozdělení do týmů je čistě záležitostí studnetů, pokud jsem to ze článku dobře pochopil?
PS: Když koukám do kódu interpretu, co to vůbec psalo za patlala? Vůbec to k ostatním částem nezapadá ;-)
Teamy jsou 4-5 lidí. Studenti si je sestaví jak chtějí. Pokud to nejde, tak budeš přiřazen k někomu jinému zřejmě.
Interpret... To dělal kámoš, co se s tím moc nepáral a podle mě se celkem dost inspiroval v minulých letech a bez komentářů je to celkem nečitelné. :-D
Okomentovat