R00.qxd
4/21/2009
2:10 PM
Page xv
Elõszó Egy évtizeddel ezelõtt az „újratervezés” (refactoring) kifejezést csak egy maroknyi ember ismerte, leginkább a Smalltalk-közösségben. Nagyszerû látni, hogy egyre többen tanulják meg, hogyan lehet újratervezés segítségével szervezettebbé és hatékonyabbá tenni egy mûködõ kódot, és hogy ennek eredményeképpen sokan már a szoftverfejlesztés elengedhetetlen részének tartják a kódújratervezést. Az üzleti alkalmazások világában élünk, az üzleti alkalmazások fejlesztése pedig jelentõs részben adatbázisok kezelésébõl áll. Az újratervezésrõl írt elsõ könyvemben az adatbázisokat az egyik legnehezebb területként jelöltem meg, mivel ezek újratervezése rengeteg új problémát vet fel, és a helyzetet súlyosbítja az a szomorú tény, hogy az üzleti alkalmazások világában az adatbázis-szakértõket és a szoftverfejlesztõket a kölcsönös meg nem értés és lenézés fala választja el. Részben éppen amiatt tisztelem Scottot és Pramodot, mert – bár különbözõképpen – mindketten keményen dolgoznak azon, hogy lebontsák ezt a falat. Scott írásai az adatbázisokról következetesen igyekeznek betemetni az árkokat, az objektumrelációs leképezésrõl írott munkája pedig rám is nagy hatással volt, amikor az üzleti alkalmazások felépítésérõl írtam. Pramod nevét talán kevesebben ismerik, de õ sem gyakorolt rám kisebb hatást. Amikor együtt dolgoztunk egy projekten a ThoughtWorksnél, azt mondták nekünk, hogy az adatbázisokat lehetetlen újratervezni. Pramod visszautasította ezt a nézetet, és néhány vázlatos ötletet programmá alakítva az adatbázissémát állandó, ugyanakkor ellenõrzött mozgásban tartotta, így az alkalmazásfejlesztõk is fokozatosan építhették fel a kódot. Pramod azóta számos ügyféllel, illetve a ThoughtWorks munkatársaival is megismertette az akkor alkalmazott megoldásokat, így az adatbázisokat – legalábbis nekünk – örökre sikerült levennünk a fokozatos felépítést akadályozó tényezõk listájáról.
R00.qxd
4/21/2009
xvi
2:10 PM
Page xvi
Refactoring – Adatbázisok újratervezése
Ez a kötet két olyan ember tanításait gyûjti össze, akik jó ideje az alkalmazások és az adatok között húzódó senkiföldjén élnek, és akik megmutatják nekünk, hogyan alkalmazhatjuk az újratervezési eljárásokat adatbázisokra. Ha már járatosak vagyunk az újratervezésben, észrevehetjük majd, hogy a legnagyobb különbséget az jelenti, hogy nem csupán a program- és adatszerkezeteket kell módosítanunk, hanem maguknak az adatoknak a folytonos áthelyezését is kezelnünk kell. Ez a könyv megmutatja, hogyan – mégpedig a szerzõk által szerzett tapasztalatok és sebek alapján. Amennyire örülök e kötet megjelenésének, annyira reménykedem, hogy ez csak az elsõ lépés. Miután az újratervezésrõl szóló könyvem megjelent, örömmel láttam, hogy kifinomult eszközök sora kerül a piacra, amelyek automatizálják a különféle újratervezési feladatokat. Remélem, hogy ugyanez fog történni az adatbázisokkal is, és a gyártók olyan eszközöket vesznek fel a kínálatukba, amelyek a sémák és az adatok folytonos áttelepítését mindenki számára megkönnyítik. Addig is, ez a könyv a segítségünkre lesz, hogy megalkossuk a saját eszközeinket, késõbb pedig szilárd alapot nyújt majd ahhoz, hogy az új eszközöket sikeresen használhassuk. – Martin Fowler sorozatszerkesztõ, a ThoughtWorks tudományos vezetõje
Az évek során, amióta szoftverfejlesztõként tevékenykedem, az iparág és a technológia drámai változásokon ment keresztül – a szoftverfejlesztés alapjai azonban mit sem változtak. Szoftvert készíteni soha nem volt nehéz: csak egy számítógépre volt szükség, amelyen megírhattuk a kódot. Jó szoftvert alkotni azonban már nem volt ilyen egyszerû, kiváló szoftvert pedig sokkal de sokkal nehezebb. A helyzet ma sem más. Manapság könnyebb nagyobb, összetettebb szoftverrendszereket építeni, mert a részeket összegereblyézhetjük különbözõ forrásokból, a szoftverfejlesztõ eszközök képességei jelentõsen bõvültek, és lényegesen többet tudunk arról, hogy mi az, ami mûködik, és mi az, ami nem, amikor szoftvert fejlesztünk. A legtöbb program azonban továbbra is törékeny, és az elfogadható minõség elérése komoly erõfeszítésbe kerül. Ennek talán az az oka, hogy nagyobb és bonyolultabb rendszereket készítünk, talán az, hogy a ma alkalmazott eljárásoknak is alapvetõ hiányosságai vannak. E két tényezõ egymásra hatása miatt a szoftverfejlesztés ma is éppen olyan kihívást jelent, mint bármikor. Szerencsére azonban idõrõl idõre új technológiák és eljárások jelennek meg, amelyek a segítségünkre lehetnek. Ezek közül néhány jelentõsen megkönnyíti, hogy valóra váltsuk, amit a munka elején elképzeltünk – az újratervezési eljárások, az agilis fejlesztés módszereivel karöltve, ezek közé a ritka kincsek közé tartoznak, ez a könyv pedig ennek a kiemelt fontosságú irányzatnak az alapjait bõvíti ki. Az újratervezés olyan ellenõrzött eljárás, amellyel biztonságosan javíthatunk a kód felépítésén, anélkül, hogy a viselkedése megváltozna. Bárki megpróbálkozhat egy kód feljavításával, de az újratervezés fegyelmezett és biztonságos (tesztekkel ellenõrzött) módosítást jelent, amely a szoftverfejlesztõk közössége által felhalmozott tudást aknázza ki (az újratervezési eljárásokon keresztül). Amióta Fowlernek a témáról szóló alapmûve megjelent, az újratervezést széles körben alkalmazzák, és számos eszköz jelent meg, amely segít az újratervezésre
R00.qxd
4/21/2009
2:10 PM
Page xvii
Fokozatos adatbázis-felépítés megérett kódrészek megtalálásában, illetve az újratervezési eljárások alkalmazásában. Az alkalmazások adatrétegében ugyanakkor az újratervezési módszerek alkalmazása sokkal nehezebbnek bizonyult. Amint a könyvbõl kiderül, ennek kétségkívül kulturális okai is vannak, de az is hozzájárul, hogy eddig nem voltak világosan körülírt eljárások és újratervezési módszerek, amelyeket az adatrétegre alkalmazhattunk volna. Ez igazán sajnálatos, mivel ha az adatok szintjét rosszul tervezzük meg, az szinte mindig problémákat okoz a magasabb szinteken is, és a rossz felépítés rendszerint láncreakciószerûen továbbterjed, ahogy hasztalanul próbáljuk stabilizálni az imbolygó alapokat. Ezen kívül az, hogy képtelenek vagyunk fokozatosan fejleszteni az adatréteget – akár a változtatástól való félelem, akár a változtatás szükségességének tagadása miatt –, lehetetlenné teszi a rá épülõ rétegek feljavítását is, és megakadályozza, hogy a lehetõ legjobb szoftvert állítsuk elõ. Pontosan ezek a problémák teszik ezt a mûvet oly fontossá: most már megvannak azok a rendszerezett eljárások, amelyeket alkalmazva fokozatosan javíthatunk ennek a létfontosságú területnek a felépítésén. Nagy izgalommal vártam ennek a könyvnek a megjelenését, és remélem, hogy a hatására elkészülnek azok az eszközök, amelyek megkönnyítik a kötetben leírt eljárások alkalmazását. A szoftveripar manapság a nyílt forrású programok elterjedésének és ezzel párhuzamosan az együttmûködésen alapuló fejlesztési modellek elfogadásának köszönhetõen izgalmas idõket él meg. Az olyan projektek, mint az Eclipse Data Tools Platform, természetes gyûjtõhelyei azoknak, akik érdeklõdnek az adatbázis-újratervezést segítõ eszközök életre hívása iránt. Remélem, hogy a nyílt forrás közössége komoly erõfeszítéseket tesz majd ennek az álomnak a valóra váltása érdekében, mert a lehetséges haszon hatalmas: a szoftverfejlesztés magasabb szintre léphet, ha az adatbázisok újratervezése éppen olyan szokványos és széles körben alkalmazott megoldás lesz, mint az általános újratervezés. – John Graham, az Eclipse Data Tools Platform projektvezetési bizottságának tagja, a Sybase, Inc. vezetõ mérnöke
Az adatbázisokkal foglalkozók közössége sok szempontból teljesen lemaradt az agilis szoftverfejlesztés forradalmáról. Míg az alkalmazásfejlesztõk a keblükre ölelték az újratervezést, a tesztvezérelt fejlesztést és az egyéb olyan eljárásokat, amelyek a fokozatosságot a szoftverfejlesztés kívánatos és hatékony megközelítésének tartják, az adatszakértõk jórészt figyelemre sem méltatták az irányzatot, vagy egyenesen elzárkóztak tõle. Egy nagy pénzügyi szolgáltatásokat nyújtó intézmény alkalmazásfejlesztõjeként ez már a pályafutásom elején világossá vált a számomra. Akkoriban az irodám éppen a programozók és az adatkezelõk csapata között helyezkedett el, és gyorsan megtanultam, hogy bár csupán néhány méter választotta el õket egymástól, a két csoport munkakultúrája és munkafolyamatai jelentõsen eltérnek egymástól. Ha egy ügyfél kért valamit a fejlesztõcsapattól, az a kód valamilyen mértékû újratervezését, újraírását és agresszív tesztelését jelentette. Egy ugyanilyen kérés az adatbázisokkal foglalkozó csapathoz egy formális módosítási kérelem benyújtásával járt, amelyet számos szinten el kellett fogadtatni, mielõtt akár a séma
xvii
R00.qxd
4/21/2009
xviii
2:10 PM
Page xviii
Refactoring – Adatbázisok újratervezése
módosításának megkezdésére sor kerülhetett volna. A hivatalos eljárás nehézkessége állandó fejfájást okozott mind a programozóknak, mind az ügyfeleknek, a rendszer mégis fennmaradt, mert az adatbázisokkal foglalkozó csapat nem ismert más utat. Ma azonban meg kell tanulniuk, hogyan csinálhatják másképp, ha bírni akarják a folyamatosan élesedõ üzleti versenyt. Az adatkezelõk közössége sem kerülheti el, hogy valamilyen módon átvegye a programozók által már alkalmazott agilis fejlesztési módszereket. Az Adatbázisok újratervezése felbecsülhetetlen értékû forrásmû, amely megmutatja az adatbázisokkal foglalkozó szakembereknek, hogy miként léphetnek magasabb szintre, és hogyan alkalmazkodhatnak biztonságosan a változásokhoz. Scott és Pramod megmutatják, hogy az apró, ismétlõdõ újratervezések miként eredményeznek jobb felépítést, és hogy ez miként teszi lehetõvé, hogy az adatbázis-rendszergazda elkerülje azt a hibát, hogy a teljes felépítést elõre megtervezi, és ehelyett az alkalmazással együtt fejlessze tovább a sémát, ahogy fokozatosan egyre jobban megérti, hogy az ügyfélnek mire is van szüksége. Félreértés ne essék, az adatbázisok újratervezése nem könnyû. Még egy olyan egyszerû módosítás, mint egy oszlop átnevezése is továbbterjed az egész sémában, hatással van annak objektumaira, a keretrendszerre és az alkalmazásrétegre, ezért az adatgazda számára kivitelezhetetlen feladatnak tûnhet. Az Adatbázisok újratervezése olyan gyakorlati eljárásokat vázol fel, amelyek pontosan azt mutatják meg a professzionális adatgazdáknak, hogy miként alkalmazhatják az agilis fejlesztési módszereket az adatbázisok megtervezésére és fejlesztésére. Scott és Pramod figyelmet fordítanak azokra az apró részletekre, amelyek lehetõvé teszik az egyes adatbázis-újratervezési megoldások tényleges megvalósítását, és bebizonyítják, hogy azok igenis kivitelezhetõk, kikövezve az utat a bemutatott eljárások széles körû alkalmazása felé. Itt az ideje, hogy minden adatszakértõ a tettek mezejére lépjen: olvassa el ezt a könyvet, ölelje a keblére a változásokat, és hirdesse az igét, hogy az adatbázis-fejlesztés hatékonyságának kulcsa az adatbázisok újratervezése. – Sachin Rekhi programmenedzser, Microsoft Corporation
A rendszerfejlesztés világában két eltérõ kultúra létezik: az objektumközpontú (objektumorientált, OO) fejlesztõké, akik a Javát és az agilis szoftverfejlesztés elveit követik, és a relációs adatbázisokat fejlesztõké, akik a gondos mérnöki tervezést és a szilárdan felépített relációs adatbázisokat istenítik. Ez a két csoport eltérõ nyelvet beszél, más-más konferenciákra jár, és ritkán ápol beszélõ viszonyt a másik csoporttal. A szakadás sok cég informatikai részlegében is tisztán megfigyelhetõ: az OO-fejlesztõk arra panaszkodnak, hogy az adatbázis-fejlesztõk begyöpösödött konzervatívok, akik képtelenek lépést tartani a gyors változásokkal, míg az adatszakértõk ostobának tartják a Java-fejlesztõket, akiknek fogalmuk sincs, hogy mit kezdjenek egy adatbázissal.
R00.qxd
4/21/2009
2:10 PM
Page xix
Fokozatos adatbázis-felépítés Scott Ambler és Pramod Sadalage azon ritka emberek közé tartozik, akik mindkét világban otthonosan mozognak. Az Adatbázisok újratervezése: Fokozatos adatbázis-felépítés olyan könyv, amelyet az adatbázisok tervezésérõl, de az objektumközpontú fejlesztõk szemszögébõl írtak. Ennek eredményeképpen a kötetet mind az objektumközpontú programozók, mind a professzionális relációsadatbázis-fejlesztõk haszonnal forgathatják: az elõbbieknek segít, hogy az agilis kódújratervezési eljárásokat az adatbázisok területén alkalmazzák, míg az utóbbiaknak betekintést nyújt az objektumközpontú fejlesztõk gondolkodásmódjába. A kötet számtalan ötletet és megoldást ismertet, amelyek segítségével javíthatunk az adatbázisaink felépítésének színvonalán, és kifejezetten arra összpontosít, hogy miként oldhatunk meg olyan valós helyzeteket, amikor egy adatbázis már létezik, de rosszul tervezték meg, vagy amikor a kezdeti adatbázisterv nem eredményezett megfelelõ modellt. Ambler és Sadalage könyve több szinten is eléri a célját. Elõször is, a lövészárkokban küzdõk gyakorlati útmutatóként használhatják. Emellett azonban gondolatébresztõ értekezés is arról, hogy miként olvaszthatjuk egybe az objektumközpontú és a relációkban gondolkodó megközelítést. Kívánom, hogy minél több rendszertervezõ tegye magáévá a szerzõk elveit, és ismerje fel, hogy egy adatbázis több, mint egy olyan hely, ahová osztályok maradandó példányait tehetjük. – Dr. Paul Dorsey, a Dulcian, Inc. és a New York Oracle Users Group elnöke, a J2EE SIG tagja
A Szerzõkrõl Scott W. Ambler szoftverfejlesztési tanácsadóként dolgozik, és Toronto közelében él. Alapítója és gyakorlatvezetõje az Agile Modeling (AM, www.agilemodeling.com), az Agile Data (AD, www.agiledata.org), az Enterprise Unified Process (EUP, www.enterpriseunifiedprocess.com) és az Agile Unified Process (AUP, www.ambysoft.com/unifiedprocess) metodológiákat népszerûsítõ webhelyeknek, és számos könyv – többek között az Agile Modeling (John Wiley & Sons, 2002), az Agile Database Techniques (John Wiley & Sons, 2003), a The Object Primer (harmadik kiadás, Cambridge University Press, 2004), a The Enterprise Unified Process (Prentice Hall, 2005) és a The Elements of UML 2.0 Style (Cambridge University Press, 2005) – szerzõjeként vagy társszerzõjeként szerzett nevet magának. Scott ezenkívül a Software Development folyóirat (www.sdmagazine.com) szerkesztõjeként is tevékenykedik, és a legkülönbözõbb nemzetközi konferenciákon (Software Development, UML World, Object Expo, Java Expo, Application Development) tart elõadásokat, illetve mond megnyitó beszédet. Scott a torontói egyetemen szerzett informatikai diplomát, szabadidejében pedig a karate Goju Ryu és Kobudo ágát mûveli.
xix
R00.qxd
4/21/2009
xx
2:10 PM
Page xx
Refactoring – Adatbázisok újratervezése
Pramod J. Sadalage az üzleti alkalmazásfejlesztéssel és -integrációval foglalkozó ThoughtWorks cég tanácsadója. A fokozatos adatbázis-felépítés és az adatbázis-újratervezés megoldásait és eljárásait õ alkalmazta elõször, 1999-ben, amikor egy nagy J2EEalkalmazáson dolgozott az extrém programozás (XP) elveit követve. Azóta Pramod számos projektben alkalmazta ezeket az eljárásokat, írt és elõadásokat tartott a fokozatos felépítésû adatbázisok felügyeletérõl, a fokozatos fejlesztési eljárások követésérõl az adatbázisok területén, valamint ezeknek az eljárásoknak a hatásáról az adatbázisok kezelésére, hogy mindenki számára elérhetõvé tegye ezeket a megoldásokat. Amikor nem dolgozik, feleségével és lányával tölti az idejét, vagy a futótechnikáját csiszolgatja.
R00.qxd
4/21/2009
2:10 PM
Page xxi
Bevezetés Az elmúlt évek során az olyan fokozatos és agilis szoftverfejlesztési módszerek, mint az extrém programozás (XP), a Scrum, a Rational Unified Process (RUP), az Agile Unified Process (AUP) és a szolgáltatásvezérelt fejlesztés (Feature-Driven Development, FDD) viharos gyorsasággal terjedtek el az információtechnológiai iparban. Ha meg szeretnénk határozni, hogy mit nevezünk fokozatos fejlesztésnek, azt mondhatjuk, hogy az olyan módszerek alkalmazását, amelyek természetüket tekintve lépések ismétlésén és egymásra építésén alapulnak, míg az agilis fejlesztés egyszerre épül a fokozatosságra és a szoros együttmûködésre. Az informatikai vállalatok ezen kívül az olyan agilis eljárásokat is egyre szélesebb körben alkalmazzák, mint az újratervezés, a páros programozás, a tesztvezérelt fejlesztés (Test-Driven Development, TDD), illetve az agilis modellvezérelt fejlesztés (Agile Model-Driven Development, AMDD). Ezeket a módszereket és eljárásokat nem elefántcsont-tornyokban, hanem a „lövészárkokban” dolgozták ki, és alulról terjesztették el a szoftverfejlesztõk, ezért nem csoda, hogy hihetetlenül jól mûködnek a gyakorlatban. Refactoring címû alapmûvében Martin Fowler az újratervezést úgy írja le, mint a forráskódon végzett apró változtatást, amely anélkül javít a kód felépítésén, hogy annak jelentését megváltoztatná. Más szavakkal, a kód minõségén anélkül javítunk, hogy hozzáadnánk vagy mûködésképtelenné tennénk valamit. Könyvében Martin arra is kitér, hogy egy adatbázisséma ugyanúgy újratervezhetõ, mint egy alkalmazás forráskódja, ugyanakkor megállapítja, hogy az adatkapcsolások jelentõs mennyisége miatt az adatbázisok újratervezése meglehetõsen nehéz, és ezért úgy döntött, hogy kihagyja a könyvbõl. A Refactoring elsõ kiadása, 1999 óta e kötet szerzõi feltérképezték az adatbázissémák újratervezésének módjait. Eleinte egymástól függetlenül dolgoztunk, és csak az olyan konferenciákon botlottunk egymásba, mint a Software Development (www.sdexpo.com), illetve az olyan levelezõlistákon, mint a www.agiledata.org/feedback.html. Megvitattuk az ötleteinket, meghallgattuk egymás elõadásait, és hamarosan rájöttünk, hogy az általunk kidolgozott
R00.qxd
4/21/2009
xxii
2:10 PM
Page xxii
Refactoring – Adatbázisok újratervezése
eljárások között komoly átfedés mutatkozik. Ezért hát egyesítettük erõinket, hogy megírjuk ezt a könyvet, és megosszuk a tapasztalatainkat, illetve bemutassuk azokat a módszereket, amelyekkel újratervezésen keresztül továbbfejleszthetünk egy adatbázissémát. A könyv példái Java, Hibernate és Oracle kódokat tartalmaznak. Majdnem az összes adatbázis-újratervezési módszer leírásához mellékeltünk magát az adatbázissémát módosító kódot, az érdekesebb újratervezési módszerek esetében pedig bemutatjuk, hogy milyen hatással vannak a Java nyelvû alkalmazáskódokra. Mivel az adatbázisok létrehozási módja különbözõ lehet, alternatív megvalósítási stratégiákat is leírtunk, ha úgy találtuk, hogy az egyes adatbázis-termékek között lényeges különbségek vannak. Egyes esetekben az adott újratervezési megoldáshoz olyan alternatív megvalósításokat is bemutatunk, amelyek olyan, az Oracle-re jellemzõ szolgáltatásokat használnak, mint a SET UNUSED vagy a RENAME TO parancs, és számos kódpéldánk támaszkodik az Oracle COMMENT ON utasítására. Más adatbázis-termékek olyan szolgáltatásokat is nyújtanak, amelyek megkönnyítik az adatbázisok újratervezését, és egy jól felkészült adatbázis-rendszergazda tudja, hogyan használja ki ezeket. (A jövõben pedig az új adatbázisújratervezési eszközök lesznek a segítségünkre.) Emellett igyekeztünk, hogy a Java kód elég egyszerû maradjon ahhoz, hogy gond nélkül átírható legyen C#, C++ vagy akár Visual Basic nyelvre.
A fokozatos adatbázis-fejlesztés elõnyei és hátrányai A fokozatos adatbázis-fejlesztés olyan eljárás, amelynek most jött el az ideje. A fokozatos fejlesztésnél az adatbázissémát nem a projekt elején próbáljuk megtervezni, hanem menet közben építjük fel, hogy tükrözze a megrendelõk által támasztott követelmények változásait. Akár tetszik, akár nem, a követelmények egy projekt elõrehaladása közben mindig változnak. A hagyományos megközelítés tagadja ezt az alapvetõ igazságot, és megpróbálja „kezelni” a változást – ami lényegében a változás megakadályozását jelenti különféle módszerekkel. A korszerû eljárásokat alkalmazó fejlesztõk ezzel szemben üdvözlik a változást, és olyan megoldásokkal élnek, amelyek lehetõvé teszik, hogy a változó követelményekkel lépést tartva fejlesszék tovább a munkájuk eredményét. A programozók ennek megkönnyítésére új fejlesztõeszközöket készítettek, illetve olyan eljárásokat alkalmaztak, mint a TDD, az újratervezés vagy az AMDD – közben pedig ráébredtek, hogy olyan eljárásokra és eszközökre is szükség van, amelyek az adatbázisok fokozatos fejlesztését támogatják. Az adatbázis-fejlesztés fokozatos megközelítésének többek között a következõ elõnyei vannak: 1. A minimumra csökkentjük a pazarlást. A fokozatos, igény szerinti (JIT, just-in-time) fejlesz-
tés révén elkerülhetjük a sorban haladó eljárásokkal együtt járó pazarlást, amennyiben a követelmények megváltoznak. Minden munka, amit egy projekt elején a kö-
R00.qxd
4/21/2009
2:10 PM
Page xxiii
Fokozatos adatbázis-felépítés
2.
3.
4. 5.
6.
vetelmények kidolgozásába, illetve a felépítés és a szerkezeti elemek részletes megtervezésébe fektetünk, hiábavalónak bizonyul, ha az igények késõbb megváltoznak. Ha képesek vagyunk elõre elvégezni ezeket a feladatokat, akkor arra is képesnek kell lennünk, hogy menet közben, az igényekhez igazodva hajtsuk végre õket. Elkerüljük a jelentõs átdolgozás szükségességét. Ahogy az 1. fejezetben látni fogjuk, az elmondottak ellenére a fontosabb kérdéseket – amelyeknek a késõi tisztázása jelentõs átdolgozást vonna maga után – elõzetesen végig kell gondolnunk, tehát szükség lesz némi elõzetes modellezésre – csupán a részleteket nem kell kidolgoznunk. Mindig tudhatjuk, hogyan a rendszerünk mûködõképes. A fokozatos megközelítésnél rendszeresen mûködõképes szoftvert állítunk elõ, még ha azt csak egy próbakörnyezetben állítjuk is üzembe. Ha hetente vagy kéthetente új, mûködõképes változatot készítünk a rendszerbõl, jelentõs mértékben csökkenthetjük a projekt kockázatait. Mindig tudhatjuk, hogy az adatbázisunk felépítése a lehetõ legjobb minõségû. Az adatbázis-újratervezésnek pontosan ez a lényege: a séma felépítésének lépésenkénti javítása. Együttmûködhetünk a programozókkal. A programfejlesztõk fokozatos megközelítéssel dolgoznak – amennyiben az adatszakértõk hatékony tagjai szeretnének lenni a fejlesztõcsapatnak, nekik is ugyanezt a megközelítést kell követniük. Általánosságban csökkentjük a szükséges munka mennyiségét. Lépésenként haladva csak azt a munkát kell elvégeznünk, amire az adott pillanatban tényleg szükség van, nem többet.
A fokozatos adatbázis-fejlesztésnek ugyanakkor számos hátránya is van: 1. Kulturális korlátok nehezítik az alkalmazását. Sok adatbázis-fejlesztõ a sorban haladó megkö-
zelítést részesíti elõnyben a szoftverfejlesztés során, és gyakran ragaszkodik hozzá, hogy a programozás megkezdése elõtt részletes logikai és fizikai adatmodellek készüljenek. A korszerû módszertan elveti ezt a kockázatos és korántsem hatékonynak tartott megközelítést, ami az adatbázis-fejlesztõket magukra hagyja. Ennél is nagyobb gond, hogy az adatszakértõk közösségének számos „szellemi vezetõje” az 1970-es és 1980-as években szerzett hírnevet magának, az 1990-es évek objektumforradalmáról azonban lemaradt, így aztán nem is szerzett tapasztalatot a fokozatos fejlesztés terén. A világ megváltozott, de úgy tûnik, õk nem változtak vele együtt, pedig ahogy a könyvet olvasva látni fogjuk, nem csak hogy lehetséges az adatbázis-fejlesztõk számára, hogy fokozatos, sõt akár agilis módon dolgozzanak, hanem egyenesen ez a követendõ út. 2. A megtanulása jelentõs idõt igényel. Az új eljárások megtanulása idõbe telik, és ez az idõ lényegesen hosszabb, ha az agyunkat át kell állítanunk a soros megközelítésrõl a fokozatosra. 3. Egyelõre kevés eszköz támogatja. Amikor a Refactoring 1999-ben a könyvesboltok polcaira került, az újratervezést még egyetlen eszköz sem támogatta. Csupán néhány évvel késõbb azonban kivétel nélkül minden egyesített fejlesztõkörnyezetben (IDE) megje-
xxiii
R00.qxd
4/21/2009
xxiv
2:10 PM
Page xxiv
Refactoring – Adatbázisok újratervezése
lentek a beépített kód-újratervezési szolgáltatások. Jelen könyv írásának idején még nem léteztek adatbázis-újratervezési segédeszközök, mi viszont minden kódot mellékeltünk, ami az újratervezési megoldások saját kezûleg végrehajtott megvalósításához szükséges. Ugyanakkor az Eclipse Data Tools Project (DTP) már felismerte az adatbázis-újratervezési szolgáltatások beépítésének szükségességét az Eclipse-be, így csak idõ kérdése, hogy az eszközfejlesztõk mikor rukkolnak elõ a termékeikkel.
Agilis fejlesztés dióhéjban Bár ez a könyv nem kifejezetten az agilis szoftverfejlesztésrõl szól, az adatbázis-újratervezés az agilis fejlesztõk egyik elsõdleges eszköze. Egy munkafolyamat akkor tekinthetõ agilisnek, ha eleget tesz az Agile Alliance (www.agilealliance.org) négy feltételének. Ezeknek a feltételeknek – amelyek azt írják elõ, hogy bizonyos területekre helyezzük a hangsúlyt, miközben nem feledkezünk meg más szempontokról sem – a betartása kötelezõ. A jobb oldalon álló tényezõk fontosak, a bal oldalon állók azonban még fontosabbak (például az eljárások és az eszközök fontosak, az emberek és az együttmûködésük azonban még fontosabb). Az agilis fejlesztés négy feltétele a következõ: 1. Az emberek és az együttmûködésük FONTOSABBAK, MINT az eljárások és az eszközök.
A legfontosabb dolog, amit át kell gondolnunk, hogy kik és hogyan dolgozzanak együtt. Ha ezt rosszul alakítjuk ki, a legjobb eszközök és eljárások sem lesznek a segítségünkre. 2. A mûködõképes szoftver FONTOSABB, MINT az átfogó dokumentáció. A szoftverfejlesztés elsõdleges célja, hogy olyan mûködõképes szoftvert alkossunk, amely kielégíti a megrendelõk igényeit. Ugyanakkor a dokumentációnak is megvan a maga szerepe: ha jól írják meg, elmagyarázza, hogy mi a rendszer célja, hogyan épül fel és miként használhatjuk. 3. Az együttmûködés a megrendelõvel FONTOSABB, mint a szerzõdés. Csak a megrendelõk képesek elmondani, hogy mit akarnak. Sajnos ebben ritkán jók – általában nem rendelkeznek kellõ ismeretekkel ahhoz, hogy pontosan leírják a rendszert, elsõre rendszerint tévesen határozzák meg a célt, és ami még rosszabb, idõvel valószínûleg megváltoztatják az elképzeléseiket. Fontos, hogy megállapodjunk a megrendelõkkel, de a szerzõdés nem helyettesíti a hatékony kommunikációt. A sikeres információtechnológiai szakemberek szorosan együttmûködnek a megrendelõkkel, erõfeszítéseket tesznek annak érdekében, hogy kiderítsék, hogy az ügyfeleknek mire van szükségük, és közben tanítják is õket. 4. A változásokhoz igazodni FONTOSABB, MINT egy tervet követni. Ahogy egy rendszer fejlesztése közben elõre haladunk, a megrendelõk elképzelései, az üzleti környezet és a háttértechnológiák is folyamatosan változnak. A változás a szoftverfejlesztés valósága, ebbõl következõen egy projekt csak akkor lehet sikeres, ha úgy közelítjük meg és építjük fel, hogy tükrözze a változó körülményeket.
R00.qxd
4/21/2009
2:10 PM
Page xxv
Fokozatos adatbázis-felépítés
A könyv szerkezete Könyvünk nagy része (a 6. fejezettõl a 11.-ig) az egyes újratervezési módszerek részletes leírásából áll, az elsõ öt fejezet azonban a fokozatos adatbázis-fejlesztés – és különösen az adatbázis-újratervezés – alapvetõ elveit és eljárásait mutatja be. Ezeket a fejezeteket sorrendben célszerû elolvasni: • Az 1. fejezet a fokozatos fejlesztés és az azt támogató eljárások – az újratervezés, az adatbázis-újratervezés, az adatbázisok visszirányú tesztelése, az AMDD megközelítést alkalmazó fokozatos adatmodellezés, az adatbázis-alkotóelemek változásainak nyomon követése és az önálló fejlesztési homokozók szükségességének – alapjait tekinti át. • A 2. fejezet részletesen tárgyalja az adatbázis-újratervezés elveit, és hogy miért bizonyulhat az adatbázis-újratervezés a gyakorlatban olyan nehéznek, emellett pedig lépésrõl lépésre bemutat egy újratervezési példát, egy „egyszerû”, egyalkalmazásos környezetben, valamint egy összetett, többalkalmazásos környezetben is. • A 3. fejezet azokat a lépéseket írja le részletesen, amelyek egy adatbázisséma újratervezéséhez szükségesek, mind egyszerû, mind összetett környezetekben. Az egyalkalmazásos adatbázisok esetében sokkal nagyobb befolyással rendelkezünk a környezet felett, ezért a séma újratervezése lényegesen kevesebb munkát igényel. A többalkalmazásos környezetekben ezzel szemben szükség van egy átmeneti idõszakra, amikor az adatbázis párhuzamosan mind a régi, mind az új sémát támogatja, ami lehetõvé teszi az alkalmazásfejlesztõknek, hogy frissítsék a kódot és telepítsék azt. • A 4. fejezet az adatbázis-újratervezési megoldások gyakorlati megvalósításával foglalkozik. Az újratervezett séma telepítése egy többalkalmazásos környezetben különösen nagy kihívást jelenthet, mert itt több fejlesztõcsapat módosításait kell összehangolni és tesztelni. • Az 5. fejezet az adatbázis-sémák újratervezésének azokat az „ajánlott eljárásait” foglalja össze, amelyeket az évek során a leghasznosabbnak találtunk, valamint néhány olyan ötletet is közzétesz, amelyeket szerettünk volna kipróbálni, de még nem volt rá lehetõségünk.
xxv
R00.qxd
4/21/2009
xxvi
2:10 PM
Page xxvi
Refactoring – Adatbázisok újratervezése
Köszönetnyilvánítás Szeretnénk köszönetet mondani a következõ személyeknek az ennek a könyvnek az elkészítésében nyújtott segítségükért: Doug Barry, Gary Evans, Martin Fowler, Bernard Goodwin, Joshua Graham, Sven Gorts, David Hay, David Haertzen, Michelle Housely, Sriram Narayan, Paul Petralia, Sachin Rekhi, Andy Slocum, Brian Smith, Michael Thurston, Michael Vizdos és Greg Warren. Ezenkívül Pramod hálával tartozik Irfan Shah, Narayan Raman, Anishek Agarwal és a csapat többi tagjának támogatásáért, akik folyamatosan vitatkoztak vele, és akiktõl sokat tanult a szoftverfejlesztés folyamatáról, valamint Martinnak is szeretné megköszönni, hogy rávette, hogy írjon, elõadásokat tartson és általában véve is csináljon valamit a ThoughtWorksön kívül. Emellett köszöni Kent Beck bátorítását, és a munkatársaknak a legkülönfélébb módokon megnyilvánuló segítségét a ThoughtWorksnél, valamint hogy örömmé tették a munkát. Hálával tartozik szüleinek, Jinappának és Shobhának, akik nagy gonddal felnevelték, valamint testvérének, Praveennek, aki gyerekkora óta véleményezte és csiszolgatta Pramod írástudását.
