Nedávno jsme v jedné bratislavské firmě uskutečnili 2-denní workshop, jehož cílem bylo zlepšit postupy prací na analytických dokumentech. Během této konzultace jsme řešili několik zajímavých problémů. Jeden z nich považuji za natolik zajímavý, že jsem se rozhodl o něm napsat tento článek.
Účastníci našich školení a konzultací velmi často položí otázku: „Kdy a jak zahájit vyhledávání analytických tříd“? Jednoduchá šalamounská odpověď by mohla znít: „Jakmile to bude možné, protože je to pro další vývoj výhodné“. Tato odpověď je sice pravdivá, ale není nám příliš užitečná, protože sama o sobě nedefinuje přesný okamžik na časové ose vývoje a tedy neurčuje signál k vyhledávání tříd.
Zkusme tedy tento okamžik kdy a jak začít vyhledávat třídy definovat přesně.
Při in-house školení ve firmách anebo v rámci veřejných školení velmi často řešíme příklady přinesené přímo účastníky školení jako součást konzultace. Několikrát se mi stalo, že jsem přitom identifikoval stále tutéž opakující se chybu a proto bych se tady o ní rád tak trochu rozepsal. Dopředu musím podotknout, že se jedná o chybu velice častou a záludnou, protože souvisí s častou záměnou názvu případu užití s aktivitou v daném případu užití.
Vždy mne potěší, když se nad články resp. příspěvky na tomto webu rozproudí diskuse a velice rád na ně také odpovídám. Proto mne potěšilo, když jsem po vydání předchozího článku s názvem O jedné časté a velmi nepříjemné chybě při zadávání prací analytikovi obdržel zajímavý mail s reakcí na tento článek. V tomto článku předkládám tento mail a následně mou odpověď i s příkladem.
Nedávno jsem se v jedné SW firmě v Čechách při školení zaměřené na analytické modelování v UML setkal s chybným postupem při zadávání prací analytikovi. Na tento problém jsem narazil již ve vícero firmách a protože jej považuji za dost závažný, pojednávám o něm zde ve formě článku.
Obdržel jsem nedávno mail, z něhož cituji následující pasáž:
U nás ve firmě se topíme ve vývoji, tj. topíme se v problémech, které popisujete v některých svých článcích. Chtěl bych některé věci změnit a snažím se si udělat jako základ v problematice trošku jasno… Pak zvažuji nějaká školení, ale nejdříve chci něco nastudovat…
S tímto problémem jsem se setkal opravdu často. Praxe ukazuje, že ve firmě je třeba věnovat se postupům vývoje SW a pokud se tento “vývoj vývoje” neřídí správným směrem (anebo se řídí sám), nastávají v SW firmě velké problémy.
Velice mi to připomíná situaci u dřevorubců, kteří nechtějí ztrácet čas ostřením seker. Protože velmi spěchají, tak se nechtějí takovou drobností, jakou je ostření seker, ani na chvíli zdržovat, a tak usilovně “buší” do dřeva stále tupějšími nástroji … A světe div se, práce jde stále pomaleji a pomaleji.
V předešlé části článku bylo pojednáno o požadovaných znalostech analytika z oblasti technologií a základních pojmů z OOP:
Kromě těchto nejzákladnějších znalostí by měl analytik znát navíc i některé ze vzorů Design Patterns. Důvodem je ta skutečnost, že některé z těchto vzorů mohou samy svou konstrukcí nabídnout řešení návrhu IS již na analytické úrovni. Při využití vzorů se řešení v analytické rovině navrhne pomocí vztahu Generalizace jak v CLASS MODELU, tak v USE CASE MODELU.
V této části článku bude uveden přehled těch vzorů, které by analytik (resp. každý vývojář) měl znát a o nichž by měl vědět nejen to, jak fungují, ale také jak a kdy se používají.
Velmi často se při školeních zaměřených na návrh SW pomocí OOP a UML ozve někdo z pléna účastníků a položí otázku, zda má analytik umět programovat a pokud ano, tak do jaké míry a do jaké hloubky. Právě tomuto problému je věnován následující článek.