-
Myslím, že člověka k programování přitahuje primárně vysoká tvůrčí kreativita v tomto oboru. Vývojář má možnost jako meta-tvůrce vytvářet nový virtuální svět (jakýsi svůj “Matrix”) podle jeho takřka „božské“ libovůle. Nejhezčí na tom je, že tento svět bude skutečně takovým, jaký jej stvořitel programátor vytvoří. Časem jsem vypozoroval ještě jedno velké plus: Pokud pominu sociopatické výjimky, […]
-
Seriál: Jak se tvoří čistý kód aneb jak se vyvarovat paskvilům – 8. kapitola: Proč je princip Open Closed důležitý pro agilní techniky
V návaznosti na předešlé články si ukážeme na konkrétním příkladu vztah mezi principem Open Closed a agilními technikami, například SCRUM. Představme si tuto situaci: Analytik-programátor vytvořil a naprogramoval nějakou metodu objektu, pojmenujme tuto metodu objektu jako A. O něco později musí vyvinout druhou metodu někde jinde, pojmenujme ji jako B. Nechť při studiu nové metody […] -
Seriál: Jak se tvoří čistý kód aneb jak se vyvarovat paskvilům – 7. kapitola: Znáte zkratky DRY, ADP, OCP, ISP a PINI?
Při studiu problematiky tvorby tzv. „čistého kódu“ můžete narazit na tzv. principy. Jedná se vlastně o doporučení týkající se návrhu čistého kódu, která by se měla dodržovat. Pro lepší zapamatování a rychlejší komunikaci mezi vývojáři se tyto principy označují zkratkami. Mezi nejznámější (kromě notoricky známé zkratky SOLID) patří také v nadpisu zmíněné zkratky DRY, ADP, OCP, […] -
Použití utility EA Excel Renamer
Problémy u vícejazyčné dokumentace v EA Jako externí konzultant a analytik ve firmách vyvíjejících informační systémy jsem někdy narazil na problémy s jazykovou bariérou. V některých případech byla vyžadována analytická dokumentace projektu jak v češtině, tak současně pro mne vcelku vzdáleném jazyce, například v němčině. Bohužel, na rozdíl od angličtiny jsem se tomuto jazyku nikdy nevěnoval, natož abych jej […] -
Seriál: Jak se tvoří čistý kód aneb jak se vyvarovat paskvilům – 6. kapitola: Ukázka vyčištění špinavého kódu
Na ukázkovém příkladu z předešlého článku si nyní ukážeme konkrétní praktické postupy řešení situací s nečistým kódem. Ukážeme si efektivní použití testů na čistotu kódu a také postup, jak se nečistého kódu zbavit.
-
Seriál: Jak se tvoří čistý kód aneb jak se vyvarovat paskvilům – 5. kapitola: Ještě záludnější příklad na zašpinění vrstvy
V předešlých článcích jsme si na jednoduchém příkladu vysvětlili jednu z nejčastějších chyb, kterou bychom mohli nazvat jako “zašpinění vnitřní vrstvy”. Podstatou této chyby je umístění evidované informace “příliš nízko”. Údaje o Čtenáři mají být ve Čtenáři (vyšší vrstva) a nikoliv v Osobě (nižší vrstva). Tento příklad má svou výhodu ve své jednoduchosti a průzračnosti (což je výhodou pro vysvětlení), ale musím podotknout, že situace bývají v praxi mnohem “záludnější”.
Uveďme si příklad na podobné téma. Zajímavá je statistika tohoto příkladu: Podle mého odhadu asi 90% vývojářů považuje chybné řešení tohoto příkladu za správné…
-
Seriál: Jak se tvoří čistý kód aneb jak se vyvarovat paskvilům – 4. kapitola: Řešení zapůjčování knih
V předešlém článku jsme předložili model se studenty, zaměstnanci, osobami, zaznělo zadání ve smyslu “evidujeme půjčování knih” a otázka byla formulována takto: “Kam umístíme všechny požadované údaje o půjčování – zápůjčky, číslo průkazu, atd., v tomto modelu? Do studenta, do zaměstnance anebo do osoby, když i student i zaměstnanec si mohou půjčovat knihy?”
V tomto článku si ukážeme analyticky čisté a správné řešení.
-
Seriál: Jak se tvoří čistý kód aneb jak se vyvarovat paskvilům – 3. kapitola: Záporný bonus opětovné použitelnosti a zašpinění vnitřní vrstvy
V knize Analytické modelování pomocí UML v praxi (volně ke stažení zde) je uveden jeden názorný příklad vysvětlující určité záludnosti objektového paradigmatu, viz kaptiola 1.3.2, strana 12. Na tomto příkladu si uvedeme jeden z nepříjemných důsledků nedodržování čistoty kódu včetně zajímavé hádanky, která v knize není uvedena.
-
Kdy použít v Use Case Diagramu vztah Extend a kdy Include (část 4)
V této části mini seriálu o interakcích Extend a Include v Use Case Diagramu si ukážeme, jak se tento vztah chápe jako zadání do technologického návrhu a programování.
-
Kdy použít v Use Case Diagramu vztah Extend a kdy Include (část 3)
U jednoho z předešlých článků se objevil jeden natolik důležitý komentář, že jsem se rozhodl odpovědět na něj přímo tímto článkem.
-
Kdy použít v Use Case Diagramu vztah Extend a kdy Include (část 2), příklad na Extend
Tento článek je pokračováním předešlého textu, viz zde. Ukážeme si nyní velmi názorný a vysvětlující příklad na použití vztahu Extend.
-
Kdy použít v Use Case Diagramu vztah Extend a kdy Include (část 1)
V mnoha školeních a konzultacích jsem takřka pokaždé narazil na rozepře mezi vývojáři o nasazení vztahu Extend. Jak se má tento vztah používat správně a korektně?
-
Analytický zápis konfigurace systému s využitím Use Case diagramu a Class diagramu
Nedávno mi přišel mail s tímto textem: Dobrý deň, pán Kravál,
V snahe zužitkovať znalosti získané na Vašom školení analytikov a návrhárov našej firmy sme narazili na jeden problém, možno nás budete vedieť nasmerovať k jeho riešeniu. Náš produkt obsahuje rozsiahlu konfiguračnú stránku, kde je možné veľa vecí zapnúť, vypnúť, nastaviť na jednu z možností, niektoré možnosti majú zmysel, iba keď sú zapnuté iné možnosti apod. Konfigurácia sa ukladá do súboru vo formáte kľúč=hodnota (java properties) Pri behu aplikácie sa hodnoty konfigurácie udržiavajú ako hodnoty inštančných premenných singleton objektu, ostatné časti aplikácie sa na ne dopytujú cez getter metódy. Podľa tejto konfigurácie sa potom produkt správa v rôznych situáciách (scenároch). Niektoré kroky sa podľa nastavenia vynechávajú, niektoré idú jednou z možných ciest apod. Ako toto najlepšie namodelovať? Jediné, čo mi napadlo, je case-om priradiť nejaké activity diagramy, ktoré popisujú logiku (vetvenie, algoritmy) v závislosti od nastavenia. Alebo aj samotné nastavenia modelovať ako triedy a ich atribúty? Ako ich potom previazať so scenármi?
-
Seriál: Jak se tvoří čistý kód aneb jak se vyvarovat paskvilům – 2. kapitola: Anonymita klienta a zavedení vzoru Singleton s inicializací
V jedné z diskusí na našem serveru se objevil odkaz na zajímavý článek, ve kterém se autor snaží vysvětlit, proč je použití vzoru Singleton nepřípustné a proč jsou Singletony tzv. lháři (v originále “Singletons are Pathological Liars”). V tomto článku si blíže rozebereme tuto problematiku z pohledu tvorby čistého kódu.
-
Seriál: Jak se tvoří čistý kód aneb jak se vyvarovat paskvilům – 1. kapitola: Test na záporný bonus
Nedávno jsem zažil jednu klasickou programátorskou situaci. Potřeboval jsem ke své analytické práci naprogramovat drobnou utilitku v C#. Základní zadání bylo jednoduché: Vytvořit Addin do Wordu, který by umožňoval psát velmi efektivně analytické dokumenty za přímé podpory CASE nástroje Enterprise Architect metodou drag and drop. Věděl jsem přesně, co potřebuji, ale vzhledem k nedostatku času […] -
Malý test OOP a Design Patterns
Vyzkoušejte si malý test na OOP a Design Patterns. Po zaškrtnutí všech odpovědí si porovnejte svoje odpovědi s řešením, které se odkryje po stisku tlačítka s nápisem Ukázat správné odpovědi. Test se nikde neukládá a ani výsledky se nikam neposílají.
-
Příklad na zavedení logické vrstvy u technologické aplikace s nasazením vzoru BRIDGE
Při jedné konzultaci ve firmě, která vyvíjí technologické systémy, jsme narazili na zajímavý problém k řešení, který nakonec vedl k doporučení zavést logickou vrstvu aplikace a k použití vzoru BRIDGE.
-
Zajímavý ilustrativní příklad na vyhledávání případů užití pomocí procesní školy
V předešlém článku (viz zde) byl popsán rozdíl mezi prvky typu User Story (zavedené v agilních technikách vývoje) a prvky typu Use Case (zavedené v UML). Současně byl také vysvětlen jejich přímý vztah v souvislosti s vývojem IS.
Následující článek má za cíl ukázat, jak lze rychle a efektivně vyhledávat případy užití procesní školou (BPMN 2.0). Navíc poslouží také jako dobrý příklad na použití prvku v BPMN 2.0 zvaného Parallel Gateway.
-
Zajímavé využití možnosti nastavení stavů a hodnot u případů užití
Scénáře případů užití (Use Case Scenario) vyjadřují posloupnost kroků programu, ať už budoucího zatím pouze navrženého, anebo již implementovaného a nasazeného u zákazníka. Mohlo by se proto na první pohled zdát, že u popisu algoritmu nemá smysl hovořit o nějakých stavech a tedy s tím souvisejícím nastavením hodnot u scénáře případů užití (podobně jako je tomu u objektů).
-
Jak analyticky zdokumentovat formuláře se složitou logikou chování?
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.