\


 Sunday, 21 March 2010
Výhody a nevýhody softwarových továren

Emailem jsem dostal zajímavou otázku, jaký je můj názor na softwarové továrny a kde vidím výhody a nevýhody softwarových továren. Odpověď nakonec publikuji i zde – už jen proto, že jsem si při jejím psaní uvědomil, že na továrnu kladu stejné nároky jako na kteroukoli další knihovnu v systému a že výběr softwarové továrny se u mě moc neliší od výběru třeba ORM Frameworku. Nejde o taxativní výčet výhod a nevýhod, ale spíš o volně nahozená témata, která mě za 20 minut psaní příspěvku napadla.

SW továrny jsou jen pokračováním trendu, že nemá smysl vynalézat znovu kolo ani v případě, že by bylo o dvě setiny procenta krásnější než to staré, které je již navržené a hotové. SW továrna říká – namísto opakování chyb svých předchůdců použijte ověřené zkušenosti, osvědčené praktiky, doporučené postupy a již otestovaný kód. Namísto obecného návrhového vzoru nebo vágně popsaného doporučovaného postupu máte k dispozici osvědčenou knihovnu, základní průvodce a odborný polštář, který by měl zabránit, že napácháte v dané oblasti velké množství hrubých bezpečnostních nebo jen s duchem technologie neslučitelných chyb.

Takže výhody:

1) Osvědčená řešení ihned po ruce. Tím se cíl SW faktory moc neliší od obecných frameworků a návrhových vzorů.

2) Není nutné psát infrastrukturní kód přímo v SW firmě (ISV). Je možné se soustředit na problémovou doménu zákazníka a ne na to, jak centrálně publikovat události nebo jak propojit různé pohledy v aplikaci tak, aby spolu dokázaly komunikovat .

3) Pokud stejnou továrnu používáte napříč všemi projekty, je zaučení nového vývojáře na dalším projektu jednodušší a rychlejší.

4) SW továrna používá praktiky osvědčené v dané technologii. Takže odlišně jsou zakódovány původně platformně nezávislá doporučení a všeobecně zaměřené vzory v SW továrně pro ASP.Net a jinak pro Silverlight. Místo popisu obecných návrhových vzorů je již vzor adaptován na konkrétní cílové prostředí.

Nevýhody:

1) Kód nemáte pod kontrolou a musíte se spolehnout, že továrna sama neobsahuje příliš kritických chyb ani otravných chyb s nižší prioritou. To platí o jakékoli abstrakci (frameworku, knihovně), kterou na projektu používáte, ale myslím, že ani v Microsoftu stále nemají SW továrny stejnou podporu jako samotný .Net Framework. A také by měla být známa alespoň orientační roadmapa SW továrny, abyste věděli, kam autoři směřují a jestli jsou si vědomi nevýhod a omezení stávající verze SW továrny. Od továrny, která se ihned po svém uvedení honosí přídomky „experimentální, testovací, zkušební“, bych dal ruce pryč. Jen ti nejodvážnější z nás si dovolí svým zákazníkům za půl roku po zatracení SW továrny jako slepé uličky tvrdit, že musí trochu poštelovat kardiostimulátor výkonného srdce aplikace a že místo plánovaných dvou hodin za přidání dvou vlastností do objednávky zákazník zaplatí dva měsíce migrace na jinou SW továrnu. Nenechal bych se zmýlit tím, že některé firmy pro odvážlivce používající jejich experimentální SW továrny a frameworky razí lichotivý titul „early adopter“ – méně korektní a pravdě bližší překlad z marketingového slovníku totiž zní „natěšený všehoschopný blbec“.

2) Univerzální řešení jako je SW továrna může být pro jednoduché aplikace zabijákem. Více času strávíte integrací aplikace do rámce vynucovaného SW továrnou než psaním obchodní logiky specifické pro aplikaci a důležité pro zákazníka.

3) U některých složitějších aplikací zjistíte, že rámec SW továrny je příliš těsný a vy potřebujete SW továrnu pro svůj projekt upravit nebo rozšířit. Náklady na rozšíření služeb , „hackování“ a ohýbaní SW továrny pro danou problematiku mohou převážit nad výhodami SW továrny. Z velké radosti nad úsporou času v raných fázích projektu, kde byla továrna použita, můžete ještě před dodáním první verze projektu a po pořádném časovém skluzu, vynuceném třeba přepisem částí továrny, které pro výkonnostních testech  nestačí stávajícím požadavkům na projekt, přejít k jadrným kletbám nad šílenou SW továrnou, v níž si úprava jednoho modulu kaskádově vynutí úpravy všech dalších modulů. Místo používání původně slibované elegantní černé skříňky s jednoduchými službami se prohrabujete nevábnými vyhřezlými vnitřnostmi mizerně navržené SW továrny.

Z výhod a nevýhod snad vyplývá můj postoj k SW továrnám. SW továrny jsou dalším evolučním stádiem na cestě, jejímž cílem je využít pro danou problematiku osvědčená řešení a postupy, nepsat stále se opakující kód nebo v každém řešení už jen změnou typu klienta (Web, Windows Forms, Silverlight, mobilní aplikace) neprocházet znovu a znovu všechny slepé vývojářské uličky specifické pro použitou technologii. Objevování objeveného ponechme těm, kterým stačí zařvat vítězoslavně heuréka, i když jsou v pořadí stí nebo tisící, kteří stejnou infrastrukturní nebo funkční trivialitu konečně zakódovali rozumným a v životním cyklu projektu dále udržovatelným způsobem.

A samozřejmě si nemyslím, že tohle evoluční stádium je konečné. :)



Sunday, 21 March 2010 11:57:10 (Central Europe Standard Time, UTC+01:00)       
Comments [6]  .NET Framework | Analytické drobky | Návrhové vzory | UML


Sunday, 21 March 2010 12:27:35 (Central Europe Standard Time, UTC+01:00)
Chapes SW factory jen jako marketingovo-hypove jinak pojmenovane SW library anebo vnimas nejaky rozdil?
A jaky?
Sunday, 21 March 2010 12:36:00 (Central Europe Standard Time, UTC+01:00)
Michal: Beru SW factory nejen jako knihovnu, ale také související balík podrobné dokumentace (stále knihovna), průvodců pro nejčastější úkoly, povinného aplikačního rámce a případně validačního kódu pro ověření návrhu a odhalení častých chyb.

A rozdíl hlavní - knihovna je pro mě částí aplikace, která je specializována pro určité úkoly nebo pokrývá jendu vrstvu aplikace apod., hlavně ale nedeterminuje a ani si nevynucuje architekturu a celkový proces výstavby aplikace.
SW factory prorůstá celým systémem a její jednotlivé prvky jsou hlavní opěrné sloupy konstrukce (architektury) aplikace.
Bavíme se ale o ideální SW továrně a knihovně, v praxi jsou hranice neostré.
Thursday, 13 May 2010 21:06:26 (Central Europe Standard Time, UTC+01:00)
A máš nějakou oblíbenou SW factory pro .NET, kterou bys doporučil? Já žádnou neznám a přijde mi to, že v tomhle směru .NET svět dosti pokulhává za Javou, resp. J2EE.

Co jsem koukal na software factories od MS, tak ty IMHO ani neodpovídají Tvé definici SW factory - to jsou jen mírné nadstavby nad konkrétními technologiemi (což nijak nesnižuje jejich přínos).
Friday, 14 May 2010 05:40:44 (Central Europe Standard Time, UTC+01:00)
Augi: Měl jsem na mysli hlavně SW továrny od Microsoftu, i když každá splňuje jen část mého pojetí SW továren.
PRISM
Mobile client software factory

Mírná nadstavba? SW továrna by měla být nastavbou nebo ochranným deštníkem před worst practices rozevřeným nad stávající technologií.

Friday, 14 May 2010 07:58:27 (Central Europe Standard Time, UTC+01:00)
Myslel jsem to tak, že tyhle Microsoftí software factories nesplňují Tvou definici "SW factory prorůstá celým systémem a její jednotlivé prvky jsou hlavní opěrné sloupy konstrukce (architektury) aplikace.". Nebo aspoň tak na mě působí (ale hlouběji jsem se k nim ještě nedostal).
Friday, 14 May 2010 08:38:38 (Central Europe Standard Time, UTC+01:00)
Myslel jsem to tak, že když použiješ třeba PRISM, tak ti Franmework usnadní architekturu, kde na první pohled:

1) Rozeznáš použití Event aggregatoru pro komunikaci mezi jednotlivými částmi aplikace.

2) Aplikace je rozdělena do modulů s metodou Init. (to prorůstá celou aplikací). Jednotná aktivace modulů.

3) Na UI nalezneš regiony.

4) Je použita DI (většinou Unity)

5) Většina doporučení a příkladů u PRISMu tě vede k použití nějaké varianty Presentation modelu (MVVM)

To neznamená, že SW továrna si tohle vynutí, ale když některou část zneužíváš/používáš jinak, většinou se ti hackování tov8rnz nevyplatí. Jinými slovy - stejně jako API platí, že by se mělo v korektních scénářích používat lehce a v nesmyslných těžko, tak stejný princip prostupuje SW továrnu.

Já má napsaný svůj vlastní framework (SW továrna) nejen pro n-vrstvou aplikaci, ale i pro řešení workflow, řízení procesů a mohu vidět, jak lidi, kteří mají na tomto FW napsat další aplikaci, nemají ani potřebu řešit věci jinak, než jak je krok po kroku vedou vysokoúrovňové scénáře v bázových třídách, vzorové příklady i výchozí implementace různých služeb (řízení stavových automatů, definice nového procesu, business rules engine)
Comments are closed.