Popis architektury

Nedávno jsem se dostal k jednomu projektu, na němž tým vývojářů s menšími obměnami pracuje přes tři roky.

A už dlouho jsem se necítil tak hloupě, jako právě u tohoto projektu.

Proč?

Protože, abych pochopil celkovou architekturu, musel jsem studovat zdrojový kód. Na začátku jsem dostal krátký briefing, od mimořádně sdílného programátora, jehož nejdelší věta se skládala z pěti slov.

Když jsem se zeptal, zda mají k dispozici nějakou dokumentaci, pomocí níž bych se s celým projektem seznámil, začali se hýkavě smát.

Dovedete si asi představit, že to celé vedlo k naprosté frustraci a vyčerpání. Hodiny strávené studiem kódu, jež měnil styly a sémantiku téměř s každou třídou, byly naprosto ubíjející. Nicméně se mi podařilo do kódu proniknout a podařilo se mi svůj úkol splnit.

Po dokončení práce jsem přešel na jiný projekt, a musím přiznat, velmi rád.

Nedokumentovat kód je obecně špatná věc. To víme všichni. Jenže zároveň dokumentovat kód je strašně otravná věc a pro vývojáře naprosto nedůstojná a pokud to jen trochu jde, nedělá se to. Ne nadarmo se říká, že nejlepší programátor je programátor líný. A chtěli byste po takovém člověku, aby dokumentoval kód. Našel v sobě zbytečky vyjadřovacích schopností a popsal význam, chování a příklady použití třídy, kterou navrhl za pět minut, ale dokumentací by měl strávit půl hodiny.

Nemyslitelné.

Na jednu stranu je to dobře. Tedy, částečně dobře. Umění je rozhodnout, kdy kód dokumentovat a do jaké míry a kdy ne. Nepředpokládám, že u malé utility aplikace byste vytvářeli dokumentaci na dvacet stran.

U složitějších aplikací je potřeba mít alespoň popsanou rámcovou architekturu a její důležité části, například ty, u kterých se při implementaci vyskytly problémy a bylo je potřeba řešit konkrétním způsobem.

U vysloveně složitých aplikací je potřeba dokumentovat a to velmi důsledně. Vy, kteří tak nečiníte, mnoho štěstí, řítíte se do pekel.

Věřte mi, sám jsem tam už několikrát byl.

Vývoj v PHP a v C# .NET framework

V době, kdy jsem se prokousával C# a přecházel jsem z PHPka, jsem byl strašně nešťastnej. Nebylo to C# nebo .NET nebo ASP.NET, bylo to ve mně. Bylo pro mne strašně složité začít přemýšlet opravdu objektově a jelikož jsem se učil PHP sám, a nikdy jsem neměl k ruce zkušenějšího kolegu, který by mne správně směřoval a případně poradil, naučil jsem se PHP "tak nějak".

Pak jsem v PHP objevil třídy, které když se dívám dozadu, pro mne byly jako jakési helpery. Něco jako namespace a v něm zapouzdřené funkce. V žádném případě se nedalo hovořit o OOP.

Jenže hlava programátorská, bez zpětné vazby, bývá hlava namyšlená. A tak jsem si začal myslet, že v PHP umím. C# a hlavně .NET framework mě hodně rychle vyléčil.

Šok, jinak se to popsat nedá. První dva měsíce jsem tápal jako tele. Dělal jsem chyby při návrhu a dostal jsem k ruce senior programátora, který toho moc nenamluvil a hlavně pro něj bylo nepochopitelné, že bych objektově psát neuměl.

Zase špatný start, ale nedal jsem se. Začal jsem hledat po netu. Prohlížel příklady. Dostával do sebe první návrhové vzory a pokoušel se je používat. Po nějakém roce bylo ze C# a .NET líp, mnohem líp.

Paradoxně však došlo k něčemu úplně jinému, stal se ze mě mnohem lepší vývojář v PHP. Ano, paralelně jsem pokračoval na projektech v PHP i v .NETu.

A ASP.NET se mi zhnusil.

Nějak jsem nikdy nedokázal přijmout web forms. Prostě to není moje krevní skupina. Respektuji tento přístup, ale nechtějte, abych dle něho vyvíjel. Prostě ten bastl v HTML kódu, aby fungovalo jakési pseudo-event-handling programování na webu nejsem schopen zkousnout.

V PHP jsem si zamiloval Zend framework a MVC architekturu. Něco podobného se chystá v ASP.NET, tak jsem zvědav, jak to dopadne. Zatím mi to vypadá hodně sympaticky. Třeba se k vývoje v ASP.NET zase vrátím.

Každopádně, .NET framework je super na desktop aplikace a aplikace pro mobilní zařízení. Tam si nemůžu stěžovat a nic jiného bych nepoužíval.

Nette a Zend - co je víc?

Nemám rád hype.

Nemám rád nekonečné diskuze o ničem.

..ale prostě si nemůžu pomoct.

Zhruba před rokem jsem se rozhodl vytvořit si jakousi základnu pro informační systém. Takovou základnu, kterou by bylo možné jednoduše rozšiřovat o funkcionalitu specifickou pro každého svého klienta.

Nebudu zastírat, že má inspirace se nacházela především ve Windows Sharepoint Services 3.0, kdy osobně pro mne je to vývojová platforma v .NET. V .NET už bych nepsal žádný informační systém bez WSS3.0, ale o tom jindy.

Předpoklady byly tehdy jasné:

- chci si vyvinout aplikaci za použití šikovného frameworku

- má to být PHP

...a tak začalo hledání a zkoušení... a zase hledání a zase zkoušení, zklamání nebo nadšení a zase zklamání. Nejvíc bylo ubíjející se vždy naučit základy daného frameworku a vyzkoušet si na vlastních příkladech složitost implementace.

A pak bum!

Zend Framework stál přede mnou majestátně, perfektně zpracovaná dokumentace, obrovská podpora, obrovská komunita. Bylo jasno.

A musím říct, že čím víc jsem do Zend Framework pronikal, tím víc jsem si ho zamilovával. Když hoši psali tenhle framework, opravdu přemýšleli a mnohdy jsem se od nich naučil něčemu novému.

A tu jsem začal registrovat zprávy o Nette frameworku. Přišlo velké nadšení. Čistý, český PHP framework? Co víc si přát.

Začal jsem po očku sledovat jeho vývoj. A čím víc jsem ho začal sledovat, tím víc mi něco připomínal, něco, co už dobře znám. V čem už nějakou dobu vyvíjím.

Ano, začal mi připomínat Zend.

A čím víc to sleduji, tím víc mi ho připomíná.

Je to špatně? Ale vůbec ne. Který je lepší? To záleží na úhlu pohledu. Nejlepší je, vyzkoušet oba frameworky na malé webové aplikaci a uvidíte sami, co vám víc sedne. Má to velkou výhodu, jakmile proniknete do jednoho, v tom druhém to naleznete podobně.

U mne je jasno v několika věcech:

- Zend má delší historii

- Zend má větší podporu

- Zend má větší komunitu

- Zend má lepší dokumentaci

- Zend se rozvíjí daleko rychleji

- Zend tu bude ještě za pár let, o Nette to říct nedokážu

Pro mne je tedy vybráno, ale vy se rozhodněte sami. Nette je dobrý framework, a ačkoliv jsem do něj nepronikl úplně, věřím, že bych si na něj zvykl a používal ho rád.

Týmu okolo Nette držím palce, ačkoliv být na jejich místě, možná bych se pustil do něčeho jiného.

Testování vlastního kódu

Někteří programátoři zastávají názor, že jejich kód by měl testovat tester. Ano, to je sice pravda, ale pokud je programátor na projektu, u kterého jsou radikálně sníženy náklady (a k tomu v nastávající finanční krizi bude docházet neustále), měl by si vývojář otestovat svůj kód sám, podle svého nejlepšího vědomí a svědomí.

Jenže ono je to lenosti. Nikomu se nechce testovat, je to strašně nudná práce a mnohdy časově opravdu náročná. Navíc to pak působí tak, že vývojář na pozici senior vytvářel kód mnohem déle, než jeho standard kolega.

Je potřeba, aby takový vývojář dal svému nadřízenému (ve většině případů je to manažer týmu nebo projektu) jasně najevo, že svůj kód během vývoje otestoval v nějkém rámci hodin.

Upřímně, senior programátor, který netestuje svůj kód NENÍ senior programátor. Ale pohodlný vývojář, který chce vypadat, že umí strašně rychle programovat.
Programování není o rychlosti, je o přemýšlení a o předcházení problémů. Vývojář, který si svědomitě otestuje to, co napsal, a který mi tak v důsledku ušetří spoustu peněz při nacházení a opravě chyb (eliminuje - respektive výrazně redukuje náklady na testera a opravu chyb), takový vývojář je ve firmě k nezaplacení.

Některým programátorům urvat koule je málo

Opakovaný kód

Privátní statické metody v místech, kde nemají co dělat (kontrakt WCF služby, pomocné metody typu "vrať mi, kolik je a plus b")

Plochá objektovost

Kopírovaný kód (psal jsem sice výš, ale tohle je opravdu tak špatný dělat...)

Sémantika. Nazvat proměnnou "promenna_1", "promenna_2"

Absence smysluplných komentářů. Mám-li kód: "var result = a + b;" a u něj komentář: "Sčítáme proměnnou 'a' a 'b' do výsledku 'result'

A teď si představte, že nejde o žádného junior programátora, ale člověka, co má certifikaci Solution Developera a programuje víc než deset let.

Takovým nechat urvat koule je málo - a pokud to není ve vaší moci, alespoň je vyhoďte. Neuvěřitelným způsobem totiž dokážou zatěžovat váš tým.
Proč? Je jedno, že ten kód napráskali během jednoho člověkodne, když vás pak oprava chyby, kterou dostane na starosti jiný programátor stojí těch člověkodnů několik.

JavaScript frameworky

Čistě subjektivní příspěvek, mám velmi dobrou zkušenost s YUI.

V některých případech však bývá YUI kanónem na vrabce. I když i zde máte volbu, nemusíte natahovat na klienta tuny JS, abyste změnili barvu jednoho divu, prostě natáhnete z YUI jen tolik, co skutečně potřebujete. Ti co znají, tak vědí.

Nicméně, výbornou alternativou, ale taky se bavíme o lower-based JS frameworku je http://jquery.com/
Nejen, že se s ním skvěle pracuje a zaučíte se během jednoho dne, ale hovoří pro něj i fakt, že ho zvolila firma Microsoft jako jeden z frameworků, který hodlá podporovat ve svém Visual Studiu.

Jestli máte svůj lepší, hezčí, oblíbenější - neberu vám to. Pokud s ním jste efektivní. U mne byste však museli znát minimálně jeden z těchto dvou.

Pokud zapomenete heslo

Každý zapomínáme a hlavně za delší dobu působnosti na netu si vytvoříte několik různých e-mailových účtů, a samozřejmě po nějaké době zapomenete heslo. Potom, například při migraci nastavených mail účtů v Outlooku úpíte, protože heslo sice uložené máte, ale skrývá se za hvězdičkama.

Pomůže: http://www.nirsoft.net/utils/astlog.html