“Feature complete” is not the same as “production ready.”
In Release It!, Michael T. Nygard shows you how to design and architect your application for the harsh realities it will face. You’ll learn how to design your application for maximum uptime, performance, and return on investment.
Mike explains that many problems with systems today start with the design:
“It’s disconnected from the real world. It’s the same as cars designed solely in the cool comfort of the lab—they look great in models and CAD systems, but don’t work well in the real world. You want a car designed by somebody who knows that oil changes are always 3,000 miles late; that the tires must work just as well on the last sixteenth of an inch of tread as on the first; and that you will certainly, at some point, stomp on the brakes while you’re holding an Egg McMuffin in one hand and a cell phone in the other.”
With a combination of case studies and practical advice, Patterns to follow and Anti-Patterns to avoid, Release It! will help you manage the pitfalls that cost companies huge amounts of time and money each year.
http://www.pragprog.com/titles/mnee
Vélemények és összefoglaló: http://www.ayende.com/Blog/archive/2007/11/04/Release-It.aspx
A linkek tartalmának véleményeket és mondhatom hogy teljes mértékben egyetértek
velük.
A szörnyű az, hogy olyan dolgokat mond, amit teljesen adják magukat és mindenki
tudja ha egy ha egy picit is utánagondol, de mégis olyan kevesen alkalmazzák a
gyakorlatban. Nygard minden tanácsát valódi háborús történetekkel támasztja
alá. Garantáltan nem kitaláltak, mert némelyikkel én is találkoztam és még a
kliensek reakcióit is pontosan ugyan azok voltak. (Csak uniformizálódik az
emberiség!)
Első rész a stabilitás kérdésével, a második a kapacitással foglalkozik. Mindkét
részt valós történettel kezdi, ami rávilágít, hogy milyen mértékű gondokat
okozhat akár csak a legegyszerűbb dolog is. Majd elmondja hogyan ne
csináld és végül a hogyan csináld dolgokat.
A harmadik részben a tervezés fontosságát hangsúlyozza. Például egy RPC alapú
remote kapcsolat nagyon egyszerű és adja magát, de ha a skálázhatóság
problémát okoz, akkor egy bonyolultabb struktúra (pl. messaging) jobb megoldás
lehet. Ekkor a végrehajtás aszinkron és minden mehet a maga ütemében. A rendszer
nem fog leállni. Persze meg kell találni a helyet, mert ahol közvetlen user
interakció van ott ez nem a legjobb, mert lassú válasznál még a gyors, bukott
válasz is jobb. De amikor egy external rendszerrel kell kommunikálni, ahol a tevékenység
nem válaszigényű ott csak rakj le egy üzenetet és a másik komponens a maga
idejében elkészíti a dolgokat.
Sajnos minden terve elmondható, hogy a fejlesztés elején kell meglépni, mert
akkor olcsó eleve úgy felépíteni a rendszert, később csak jóval nagyobb
költségekkel lehetséges. A stabil és jó kapacitású terv költsége ugyan az. Az
implementáció lehet költségesebb, de a végeredmény számít.
A war-story-kból ráirányította a tekintetemet olyan technológiákra, amik segíthetik
az életem. Megtudtam hogy milyen információkat lehet kinyerni a java ThreadDumpokból.
Meg úgy egyáltalán, hogyan kell ilyen készíteni. Rámutatott a JMX hasznára, ami
nekem eddig egy picit ködös dolog volt. Egy nagyon jó és érdekes példát adott
az Objservation (REF: Fowler) (nem Observer) minta alkalmazására.
Rámutatott, hogy a külső rendszerekkel kapcsolódva milyen dolgokat kell
folyamatosan figyelni és hogyan lehet ezen ingrációs pontok gondjait lekezelni.
Na persze ne feledjük a sessionöket. Azok száma és mérete megöli a
rendszereket. Könnyű azt mondani, hogy csak sessionbe "cachelem" az
adatokat, de ha sok session van, akkor olcsóbb újra lekérdezni, mint azzal
küzdeni, hogy nincs elegendő memória az application servernek, amiért nem tud
olyan volumenű lekérdezést kiszolgálni. (BDW itt egy cikk,a mit érdemes szintén elolvasni)
A leglogikusabb leggyengébb láncszem elv is adja magát, de Én magamtól egyszer
sem gondoltam erre, csak, akkor, ha már nem volt más lehetőség. De most már
jobban a gondolataim előterében vannak.
Fail fast. Lassú válasz rosszabb, mint a pokol. Ha gyorsan válaszold még akkor
is ha hiba van, akkor legalább le tudod kezelni.
Összegyűjtött egy csokorra való tesztelési tippet is, hogy hogyan lehet
tesztelni a rendszerek hibatűrőségét.
De igazából a webfejlesztéstől és adatbáziskezeléstől kezdve mindenre vannak
ötletek és tippek a könyvben. Csupa olyan dolog, amin el lehet gondolkodni.
