Co programátory ve škole neučí

9. 4. 2004 | Ondřej Zloský | Recenze | 9999×

Tato kniha není o Linuxu. Není ani o Open Source projektech. Nedozvíte se prakticky nic o tom, jak se má co správně programovat. Přesto by si ji mohl v klidu přečíst každý, kdo naprogramuje víc než nějaký skriptík pro ulehčení své práce.

Co programátory ve škole neučí aneb Softwarové inženýrství v praxi

Kniha z nakladatelství Computer Press od českého autora Petra Palety je o problémech, které provázejí každý větší softwarový projekt. Dozvíme se, jak těmto potížím předcházet, jaké chyby dělají manažeři při vedení programátorského týmu, jak komunikovat s programátory a zjistíme, k čemu se vlastně taková analýza, modelování a všechny ty "nezajímavé" věci okolo programování dělají.

Autor knihy rozhodně není nijak výrazný fanda Linuxu (dokonce se v knize vyskytuje i jedna poměrně zajímavá úvaha o škodlivosti volně šiřitelného software). Mimo jiné byl také členem Microsoft Developer Network, takže veškeré praktické ukázky, které jsou v knížce obsaženy a vůbec většina věcí věnujících se konkrétním programovacím jazykům je o C# nebo .NET, případně Javě. Naštěstí tato kniha opravdu není o programování, ukázek není mnoho, takže ani moc nevadí, že je kniha tak trochu MS like.

Kniha je velmi členitá, celkem je rozdělena do 43 kapitol. Naštěstí je také rozdělena do 10 logických celků plus jeden zajímavý bonus na závěr. Pojďme si to tedy ve stručnosti projít.

První část "Tajemství tvorby softwaru" se snaží přijít na to, proč je programování vlastně tak odlišné od jiné práce. Uvádí seznam nejčastějších problémů a jejich příčin. Dále se dozvíme, v čem dělají školy chybu při přípravě svých absolventů na budoucí praxi. Téma čerstvých absolventů a začínajících programátorů se vůbec vine celou knihou, neboť právě jim a v tomto oboru nezkušeným manažerům je tato kniha určena.

"Jak psát a jak nepsat programy" se zabývá především estetickou stránkou kódu. Ukazuje, jak psát program přehledně, jak psát srozumitelné komentáře a jak docílit rozumné struktury kódu a dat.

Název třetí části "Proč dochází k chybám?" je vcelku výmluvný. Probírají se zde nejčastější příčiny potíží a metodiky, jak těmto chybám předcházet.

Naproti tomu se část "Co s chybami?" zabývá situací, kdy už v programu chyby jsou. Rozebírá, jaké typy chyb se v programech vyskytují a co všechno se dá udělat proto, aby byly nalezeny. Poslední kapitola ukazuje, jak může probíhat revize kódu a dokumentů s projektem spojených.

"Testování aplikace" je název páté části a opět je vcelku jasné, o co půjde. Především jsou to typy a způsoby testování. Rozebírá se zde práce testovacích týmů a způsoby testování a reakcí na chyby v závislosti na stavu projektu.

Zatímco první polovina knihy byla určena spíše programátorům, druhá polovina je zase spíše pro analytiky a manažery. Hned šestá část má název "Řízení softwarových projektů" a zabývá se vývojovým cyklem projektu z hlediska jeho vedení. To znamená jednání s klientem, sepsání smlouvy, analýza projektu a jak vytvořit projektový plán. Nakonec se dozvíme, jak se dají spočítat náklady na projekt a hlavně, jak si pokud možno zajistit nějaký zisk.

Sedmá část "Lidské zdroje a komunikace" nás provede problematikou složení týmu. Jaké typy pracovníků se mohou v našem týmu vyskytnout a také, jak tyto lidi správně vybrat. Dále se tato část zabývá rozdělováním úkolů, motivací zaměstnanců a komunikací uvnitř týmu. Nakonec se ještě dozvíme, jak jednat s klienty, nadřízenými a manažery.

"Metodiky a technologie" nás uvedou do problematiky a výhod nástrojů pro modelování a návrh aplikací. Mimo jiné dobře známý nástroj CASE a vcelku rozšiřující se jazyk pro vizuální modelování UML. Tato část se dále zabývá strukturou aplikace a správnou volbou programovacího jazyka.

Předposlední část "Architektura aplikace" řeší výkonnost aplikace a její použitelnost. Dozvíme se, jak navrhovat uživatelské rozhraní, na co všechno je třeba brát ohled při návrhu databází a jak navrhnovat komunikační protokoly.

Poslední část se jmenuje příhodně "Když projekt běží..." a pojednává o tom, jak probíhá vývoj, když už programátoři pracují, na co si dávat pozor, ale třeba i o tom, jak zabránit, případně minimalizovat, zpoždění celého projektu. Samozřejmě nechybí kapitoly o nasazení a následné správě prodané aplikace.

Jako bonus je ke knize přidán test pro uchazeče o místo programátora. Ten se skládá ze šesti otázek z čehož jsou 4 jazykově závislé (dvakrát Visual Basic a dvakrát ASP plus Active-X) a dvě jsou o databázích (návrh a SQL dotaz). Nejsem programátor ve Visual Basicu ani v ASP, nicméně podle autora je na test 50 minut a to bych tedy nechtěl dělat, ani kdybych ty jazyky ovládal. Ale věřím, že jako inspirace velmi dobře poslouží.

Kniha jako taková je vcelku poučná. Nemyslím si, že je úplně pravdivé tvrzení "aneb co programátory ve škole neučí", protože například u nás na škole se předměty věnující se tomuto tématu přednáší. Pravdou ale je, že se to neučí příliš dlouho. V knize je pouze minimum praktických ukázek, jak konkrétně psát programy. O tom to není. Je to o tom, čeho se v praxi držet, a jakých problémů se můžeme vyvarovat, pokud budeme postupy dodržovat. Proto nečekejte, že se podle této knížky naučíte lépe programovat ve smyslu rychlejších algoritmů a šikovnějších konstrukcí. Co se ale naučit můžete, je minimalizovat chybovost svého kódu a zvýšit jeho použitelnost v budoucnu.

Název	Co programátory ve škole neučí aneb Softwarové inženýrství v praxi
Autoři	Petr Paleta
Vydal	Computer Press
ISBN	80-251-0073-1
Datum vydání	2003
Počet stran	329
Doporučená cena	269 Kč / 399 Sk

       

Komentáře

[Karel Zak]

Prave ji ctu a neni to spatna kniha. Prvni prijemnou veci je, ze se nejedna o praklad

Jinak je plna veci ktere nejsou nijak objevne a dokonce jsou bezne zname, ale bohuzel i bezne nepouzivane. Vrele doporucuji lidem co rozhoduji o impementacich, ridi software projekty, nebo delaji na necem vetsim apod.

Urcite i vhodne ctivo pro ty z OpenSource "guru" co "maji CVS v hlave", dokumentaci nepisi, protoze nejlepsi dokumentaci je (nekomentovany) kod a vrchol jejich programatorskeho umeni jsou co nejkratsi konstrukce na co nejmensim prostoru .

[Honza]

podobnych knih existuji na svete uz tisice. Ta (snad) prvni 'The Mythical Man-Month' tusim vysla uz v roce 1975.

Bohuzel se ale za tech 30 let vubec nic nezmnenilo, pomer neuspesnych projektu k celkovemu poctu je porad stejny. A proto je kazdy takova kniha, ktera sugerruje, ze staci pekne vrele komunikovat v projektu aby byl taky nekdy hotov hrebicek do rakve pristiho projektu.

Jen tak pro ilustraci, predstavme si konstrukcni kancelar v automobilove firme. Sedi tam zemedelsly inzenyr, stavar, fyzik a ekonom. Naucime je spravne komunikovat, kreslit vykresy aby vypadaly pekne a vstricne a nechame je konstruovat auto. Kazdy si predstavi, ze to asi nebude fungovat.

Ale v software se to deje bezne. Prosim me kolegy v pristim projektu, aby tu knhu necetli.

[Tom.š Ze.le.in]

Predchozi poznamka mi znela trochu jako

• je to jako Mythical Man Month (MMM)
• kniha dava rady, ktere jsou na nic
• nectete to.

Nevim, jestli to tak bylo mineno, ale pokud se pamatuju, MMM si stalo za to precist, a obsahovala jen popis problemu, zadna udajne zazracna reseni; naopak, tvrdila ze takova neexistuji (no silver bullet). Ja bych MMM rozhodne doporucoval.

[Honza]

dekuji za upresneni, samozrejme je mozno MMM vrele doporucit ke cteni a nema s predkladanym titulem nic spolecneho. Pouzil jsem to pouze jako priklad, jak dlouho se jiz s temi projekty trapime. Ja totiz neznam zadnou alespon tak znamou a starsi publikaci z oboru soft. inzenyrstvi.

jinak ty dalsi dva body, to jste trefil.

[Bedny]

Nemohu nereagovat na tak arogantní výlev. Pan Paleta zemrel tak mlád právě proto, že věnoval celý svůj život studiu progrmátorství a softwarového inženýrství. To je nepředstavitelně náročné. Vše co v knize píše vychází pouze a jenom ze zkušeností, které získával při vývoji všch možnách projektu ve všech možných kolektivech. Jeho zkušenosti v řízení projektů, ať už vlastních krabicových nebo zakázkových byly ohromné. Jeho chování někdy připomínalo zatvrdlého dítěte, kterému se někdo snaží sebrat jeho nejoblíbenější hračku. Ale to nemělo nic společného s tím, jak vysoce kvalifikovaný pro práci na svojí pozici byl, díky čemuž si mohl dovolit napsat tuto knihu. Mluvím tak, protože jsem měl tu čest a mohl jsem s ním několik let pracovat. Bohužel už tomu tak nikdy nebude. Knihu jsem ukázal jen několika málo lidem v mém současném kolektivu hodně zkušených lidí a všichni ji přijali. Víte proč? Protože kniha má hlavu a patu a ten kdo ji psal, používal pravidlo číslo jedna, používal hlavu. Lituji vás i vaše kolegy v příštích projektech.

[falken]

Naprosto souhlasím. Není mnoho knih, které bych přečetl jedním dechem od začátku do konce. U téhle se mi to povedlo a v duchu jsem si při čtení často vzpoměl na "Softwarové projekty" pana McCarthyho; i tato kniha je velmi hezky napsaná. Radost mi opravdu zkazila až zadní obálka... Většina věcí i informací v dnešním světě je pouze zbytečný balast. Tím je i spousta knih napsaných s produktovým manuálem v ruce, v horším případě ještě špatně přeloženým. Někdy se mi zdá, že se mi tato knížka tak líbila právě proto, že bohužel stále nepracuji jako programátor, ačkoliv se považuji za schopného tuhle práci dělat - ovšem bez vzájemné arogance, machrování, falešného chytráctví a podle určitých pravidel ... tedy možná právě podle Vašich rad, pane Paleto. Uvažoval jsem celý život hodně podobně a možná proto mne strašně překvapilo, že už autor této hezké a užitečné knížky již nic podobného nenapíše. Nechce se mi ani tušit proč, ale vidím za tím právě tuhle aroganci a nebetyčnou blbost dnešního světa, ve kterém "úspěšní a šťastní" jsou hlavně neschopní vykukové, podvodníci a manipulátoři. Číst Vaši knížku pane Paleto byla opravdu veliká radost a moc mi to opět vrátilo chuť do práce a do života vůbec. Jednou bych chtěl pracovat i s pomocí Vašich znalostí na nějakém pro lidi opravdu užitečném software. Díky!

[Stepan]

Ctu to na zadni strane publikace - to opravdu zemrel tak mlady?

[Melkor]

Kdyby autor udrzel nervy na uzde a odpustil si obcasne MS PR (s prominutim) kecy, tak by se dalo souhlasit snad se vsim. I tak si myslim, ze alespon par myslenek mi v hlave zustane a pri dalsim pojektu ...

[falken]

Na tomhle serveru je to asi kacířská myšlenka, ale podle mne je MS docela skvělá firma a otevřeně se rád přiznám, že mám rád Windows a když se nebudu snažit být "in", tak celkem vše co pochází z MS je docela fajn; i většina programátorských knížek z MS pressu je podobně skvěle napsaná chytrými a "srandovními" autory , třeba Joefrey Richter a jeho inside informace o Win32 jsou super (i když už řádově přesahují moji mozkovou kapacitu . Prostě si myslím, že JE docela umění rozvíjet operační systém "za pochodu" tak, aby navenek vypadal pořád skoro stejně a uměl spouštět i ty nejstarší rozumě slušně napsané programy pro DOS a přitom "uvnitř" překopávat architekturu k něčemu dokonalejšímu. Zatím nejdokonalejší a nejvíc "sexy" Windows se vejdou do pár set kB, úplně stejně jako linux (WinCE.NET; Na MS se mi líbí evoluce, i když si mohou klidně dovolit jakoukoliv revoluci. Opravdu statečný revolucionář je ale SUN. JAVA je geniální nápad a možná i díky handrkování s MS se sami připravili o možnost uvést dle "pravidla třetí verze" jeho "killer" podobu. Nevím do jaké míry je to košer, ale první dvě verze .NETu a C# vlastně pro MS vydupal z prachu někdo jiný... Ale o to snad ve finále nejde; chceme přeci všichni mít lépe a radostněji hotovo )

mono rulez!

[Pavel]

právě to čtu. Jsem ve třetině a o pravdu v této době nic nového. Jen mě udivuje co dělá na abclinuxu recenze knihy, kde autor napíše, že přikázat open source hloupým politikem do institucí je cosi naprosto odporujícího zdravému rozumu (str 26). Dále označit while (*s++ = *t++) (str. 80) jako "trik" kopírování řetězce je snad špatný vtip. Každý ví, že strcpy nemá cenu optimalizovat, protože tato fc je již naprosto zoptimalizována na danou instrukční sadu CPU.