Význam správného designu software

Význam správného designu software
« kdy: 30. 01. 2014, 02:06:55 »
Dobry den. Chcel by som sa opytat ci neviete o nejakych materialoch ktore pojednavaju o vyzname spravneho zistovania poziadaviek, designovania, navrhovania, prototypovania a programovania vacsieho projektu? Prakticke vysveltenia toho co sa stane ked sa zanedba niektora faza, jedna sa mi o priklady zo zivota (realne skusenosti), teda nejake pripadove studie o tom ze ake su nasledky toho kedy sa na projekte zacne bezhlavo robit, zisti sa v polke projektu ze velku cast by bolo treba prekodid komplet celu pretoze zakaznik si zapytal novu funkciu. Pripadne sa to v horsom pripade nejako "dolepi" len aby to fungovalo. Viete o neiecom co o tomto pojednava a vysvetluje to zrozumitelne na prikladoch? Dakujem
« Poslední změna: 30. 01. 2014, 19:48:27 od Petr Krčmář »


eswrgewrtewrtw

najdi si neco o waterfallu nebo naopak o modernejsich metodach.

extreme programming, scrum, kanban.....

Waseihou

Záleží na tom, jak velkou aplikace chceš dělat. Pro aplikace typu webová prezentace firmy (a nebo obecně pokud je tým lidí pracující na aplikaci tak do max. 10 lidí...) je lepší použít agilní metodiku a TDD (test driven development) a pak to postupně refaktorovat aby to bylo udržovatelné. Zkušený tým a framework pravděpodobně zajistí dostatečně použitelný design.

Pro velké ERP (objednávky + výroba + doručení etc.) systémy je dobré naplánovat nějakou architekturu a rozdělit systém na moduly které budou přiřazeny jednotlivým týmům. Je třeba rozdělit systém na vrstvy, pořešit perzistenci, MVC a tak dále. Samozřejmě TDD má taky význam, jen je třeba pohlídat určitou kvalitu designu a není možné to patlat jako web na koleně.

Google našel tuto knížečku kterou musíte bezpodmínečně znát pokud hodláte dělat větší enterprise (B2B) aplikaci. Bacha je to z doby kdy ještě nebyly žádné frameworky jako nhibernate atp.:

ftp://ftp.heanet.ie/mirrors/sourceforge/w/we/webtune/Patterns%20of%20Enterprise%20Application%20Architecture.pdf

ERP aplikace se dneska dělají většinou v Javě a nebo C# (lepší pro developery...), tam je třeba podívat se na:

http://www.castleproject.org/ - DI
http://particular.net/nservicebus - Service Bus
http://nhforge.org/ - persistency

A mnoho dalších věcí...

Dobré je že hodně věcí už je dnesk odladěno a nemusíte si je dělat sami na koleně.

lobo

"ake su nasledky toho kedy sa na projekte zacne bezhlavo robit"
bude to drahsie a bude to dlhsie trvat :-)

Waseihou

Bezhlavě kódit má cenu, pokud existuje několik konkurentů a je třeba být první na trhu. Pokud je time to market nejdůležitější, pak klidně to robte "bezhlavě". Ve skutečnosti to nebude tak bezhlavé, pokud už máte nějaké zkušenosti. Pravděpodobně to uděláte "tak jak jste zvyklí", takže zkušení developeři / designéři už budou vědět co dělat i když se bude postupovat relativně rychle. Pokud ale strávíte alespoň týden na nějaké to promyšlení designu / nabušíde prototyp se stuby modulů a servis, tak vás to asi nezabije...

Je design mrtvý?
http://martinfowler.com/articles/designDead.html


Jakub L.

Moje zkušenost je, že při libovolné velikosti je potřeba udělat si analýzu. Bez toho, abych přesně věděl, co klient chce nemá smysl sahat na klávesnici, protože pak stejně zjistím, že to chce jinak...

Jozef

Moje zkušenost je, že při libovolné velikosti je potřeba udělat si analýzu. Bez toho, abych přesně věděl, co klient chce nemá smysl sahat na klávesnici, protože pak stejně zjistím, že to chce jinak...

Uplne suhlasim. Analyza nemusi ist uplne do hlbky, ale je podstatna z hladiska porozumenia co vlastne klient chce...

j

Moje zkušenost je, že při libovolné velikosti je potřeba udělat si analýzu. Bez toho, abych přesně věděl, co klient chce nemá smysl sahat na klávesnici, protože pak stejně zjistím, že to chce jinak...

To je uplne jedno, to zjisti tak jako tak, jediny co je opravdu dulezity, je mit to smluvne podchyceno => rict mu ... "vy ste si schvalili ze to bude scitat a tech chcete aby to jeste nasobilo => + dalsich 30hodin vyvoje"

+ (velmi dulezite ;D) je dobre si predem overit, ze to vsechno co "neni zadny problem", opravdu lze realizovat. Osobni zkusenosti ... na zakazce se vyresilo 98% "problematickych" casti ... a pak se skoncilo ( po 3/4 roce) na tom, ze jaksi ona verze SW neumi to, co umely vsechny verze pred ni ... a co se povazovalo za zcela samozrejme. A samo, tato "nepatrna" zmena nebyla popsana v zadnem changelogu.


Suhlasim so vsetkym co tu bolo povedane no ja sa pytam ci existuje nejaka literatura co toto vysvetluje prakticky. Asi takou formou ze: Alica spravila analyzu dokladne preto teraz nema problem implementovat to co chce zakaznik a jej kod vyzera takto. Bob nemal dokladnu analyzu preto jeho kod vyzera teraz takto a ma problem implementovat to co chce zakaznik. Cielova skupina by mali byt studenti ktori nemaju s vyvojom softwareu v praxy prakticky ziadne skusenosti, a toto by im malo pomoct ukazat naco je analyza (a vsetky dalsie fazy potrebna). Dakujem

txt

Suhlasim so vsetkym co tu bolo povedane no ja sa pytam ci existuje nejaka literatura co toto vysvetluje prakticky. Asi takou formou ze: Alica spravila analyzu dokladne preto teraz nema problem implementovat to co chce zakaznik a jej kod vyzera takto. Bob nemal dokladnu analyzu preto jeho kod vyzera teraz takto a ma problem implementovat to co chce zakaznik. Cielova skupina by mali byt studenti ktori nemaju s vyvojom softwareu v praxy prakticky ziadne skusenosti, a toto by im malo pomoct ukazat naco je analyza (a vsetky dalsie fazy potrebna). Dakujem
např. http://www.objects.cz/kniha_am/kniha_am.php

Sten

Moje zkušenost je, že při libovolné velikosti je potřeba udělat si analýzu. Bez toho, abych přesně věděl, co klient chce nemá smysl sahat na klávesnici, protože pak stejně zjistím, že to chce jinak...

U větších projektů ani to nemusí pomoct, protože zákazník nebo implementátor často zjistí zásadní problém až za tvorby. Proto existují systémy jako SCRUM.

Ovrscout

Tak něco konkretne pro tenhle účel nemám. Většina knížek se spíše zabývá tím jak se to má/může dělat než proč. Občas se najde kapitola o porovnání různých metodik ale přímo to co jste chtěl to není. Možná by to chtělo spíše hledat nějakou studii , seminární práci nebo článek. Zkuste prolistovat začátky knih pojednávající o vývojových metodikách, nebo o manažerském řízení projektů http://knihy.cpress.cz/rizeni-projektu-v-it-d2.html - nečetl jsem.
Možná by se dalo i něco načerpat z http://knihy.cpress.cz/dokonaly-kod.html ale to už je asi hodně střelba od boku. Už jsem to trestuhodně dlouho nečetl tak si moc jist nejsem jestli je tam z tohoto pohledu něco použitelného. Přímo asi nic.

Z předchozích příspěvků mi tak trochu splývá dohromady "analýza požadavků-zadání" a "návrh programu". Podle mne jsou to z tohoto pohledu více-méně oddělené kroky. I když vývoj samozřejmně může iterovat a výsledek jednotlivých kroků nemusí být úplný ani definitivní (a ani správný). Obecně chyba v analýze-zadání má potenciál napáchat větší škody. Přesto bych tyto dvě části oddělil a zvažoval samostatně z hlediska jejich nákladů,rizik a způsobů provedení(např podrobnost,udržovatelnost,znovupoužitelnost)

Například se přílišná předběžná(bez smlouvy) analýza nemusí vyplatit pokud není zakázka realizovaná - zráta času=paněz.
Nebo pokud se zakázka nerealizuje a získá ji konkurent=dvojitá ztráta - protože i když konkurent nebude mít vaši analýzu v ruce, tak zákazník s kterým jste ji prováděl už bude daleko lépe vědět co chce a nová analýza pak nezabere tolik času a bude pravěpodobně přesnější. Ale třeba špatný návrh sw může v extrémním narazit na to že se můsí předělat protože se v něm danná funkcionalita nedá použitelně udělat. Tím chci říci že obě fáze můžou mít katastrofální následky.
Všchno se dá samozřejmně řešit ale záleží na konkrétní situaci,objemu práce, ... .

Třeba se tohoto tématu někdo chytí a napíše článek.
Nebo nejlépe dva. Jeden z obchodně-politického hlediska a druhý z programátorsky-technického :)
Nakonec by to mohlo na malou brožurku vydat.

Waseihou

Udělejte nějaký odhad jak dlouho to bude trvat a kolik to bude stát a výsledek vynásobte třemi.

Tj. doba a cena kterou řeknete zákazníkovi = 3 x doba a cena vámi odhadnutá.

Realita "magickou trojku" již mnohokrát potvrdila. U jednoduchých věcí násobíme 1.5, u středních 2 a u složitých 3...

Čím více času strávíte analýzou, tím blíže může být tato "magická konstanta" jedničce. Ale nezapomeňte že analýza je také práce a někdo ji musí zaplatit. Nejdříve proto smlouvu se zákazníkem aby vám zaplatil analýzu...

Třeba se tohoto tématu někdo chytí a napíše článek.
Nebo nejlépe dva. Jeden z obchodně-politického hlediska a druhý z programátorsky-technického :)
Nakonec by to mohlo na malou brožurku vydat.

Vedel by som si nieco podobne predstavit formou serialu tu na roote ;)

Waseihou

Re:Význam správného designu software
« Odpověď #14 kdy: 30. 01. 2014, 21:28:11 »
Jinak původní otázka co jsem pochopil nebyla ohledně toho jak to řídit, ale ohledně designu. Čas x návrh jdou obvykle proti sobě a proto je třeba hledat kompromisy, to je to čím tyto věci souvisí. Přijde manažer a řekne: "Trochu ten kód pročistěte a zavřete to, musíme to doručit už zítra!" a pak v kódu zůstanou prasárny kvůli kterým v budoucnu přibude práce, protože kód bude hůře udržovatelný.

Ale - u velkých projektů je významné procento kódu, na který se sáhne třeba jednou za dva roky. Kvalitní design dělá kód složitější, protože klade větší nároky na opici (pardón, na toho kdo to udržuje...) která nemusí vědět ani nic o tom že je dobré snažit se o znovuvyužití existujícího kódu. V praxi stejně můžete narazit na plánování typu "Tak zkopírujeme zdroják téhle obrazovky a trochu to změníme...".

Z hlediska byznysu není důležité jestli je kód čistý, ale že ona nová obrazovka dá v čas vědět že se třeba něco nemá vyrábět a tím že se výroba včas zastaví se ušetří značné prostředky, případně že nová funkcionalita umožní vyrobit co nejmíň v rámci legálních a smluvních limitů a tak uspokojit co největší počet zákazníků továrny, případně naopak pokud má továrna málo objednávek tak vyrábět co nejvíc v rámci existujících objednávek aby se maximalizoval zisk. A nejlépe mezi těmi dvěma situacemi dynamicky přecházet v závislosti na aktuální situaci která se třeba během roku mění...

U designu platí, že čím větší abstrakce, tím je může být pro ostatní složitější pochopit o co jde. Ale ani v případě relativně jednoduché abstrakce není zajištěno že nedojde k duplikaci kódu. A tak i když má třída reprezentující množinu řádků v databázi metodu na hledání záznamů podle hodnoty v nějakých sloupečcích, tak stejně se vždycky najde někdo kdo o tom neví a udělá si vlastní hledání, obvykle for přes prvky kolekce pomocí iterátoru. To se děje ve starých projektech kde podobné featury nebyly součástí jazyka a tak někdo naprogramoval vlastní framework ale neudělal k němu programovou dokumentaci bo na to nebyl čas ani peníze a nově příchozí pak nehledali, jestli tam na to něco není. Zvláště pak pokud nestandardní konstrukce v headeru zabily IntelliSense které se ani nedostalo k definici třídy a manažeři nedovolili refaktorovat několik stovek souborů protože to přece není bug nahlášený zákazníkem...

No každopádně u velkého projektu je klíčové rozdělit jej na několik modulů a definovat mezi nimi rozhraní, pak na modulech může pracovat vícero týmu relativně nezávisle na sobě. Je dobré pokud je nějaký modul do něhož se nacpe obecná programová funkcionalita nesouvisející s byznysem (helper classy v C#, generické algoritmy, perzistence č atp.) a ostatní moduly se pak zabývají jen svojí doménou. V takovém modulu pak je třeba implementován "kalendář s vodotryskem a splachovadlem", ten se pak nakonfiguje v byznys modulu aby u objednávek zobrazoval "blikající vodotrysk bez splachovadla" a skladníkovi co řídí nakládání zboží na kamiony "malý agregovaný vodotrysk co blikne jen při použití splachovadla". V byznys modulech se pak řeší jen byznys-logika, tudíž co udělat když si zákazník továrny v půli výroby uprdne, nikoliv už jak to zobrazit či pořešit technicky. Oddělení byznys logiky je kapitola sama pro sebe, je dobré vyvarovat se tomu aby taková logika byla v grafických komonentách...

No a hodně dalších věcí. V praxi stejně přijde někdo kdo to nedodrží a opice se na to vyserou, zvláště pokud je moc neplatí tak udělají jen tolik aby to fungovalo...