Joel on Software

Joel on Software   Joel, szoftverekről

 

További "Joel on Software" cikkek magyar nyelven

További "Joel on Software" cikkek angol nyelven

E-mail a szerzőnek (angol nyelven)

 

Fájdalommentes funkcionális specifikáció - 1. rész: De miért is fáradnál?


Szerző: Joel Spolsky
Fordította: Plesz Gábor
2000. oktober 02.

Amikor a Joel teszt először feltűnt, az egyik legérzékenyebb pontjaként minden olvasó a specifikáció készítését jelölte meg. Azt jelezték, mindenki tudja, hogy el kéne készíteni, de senki sem teszi.

Miért nem akarnak az emberek követelménykatalógust (a továbbiakban: specifikáció) írni? Az emberek azon az alapon ugorják át ezt a lépést, hogy időt spórolnak. Úgy tesznek, mintha a követelménykatalógus valami luxus lenne, amit a NASA űrkomp-tervező mérnökök vagy azok használhatnak, akik gigászoknak, például állami biztosítótársaságoknak dolgoznak. Rossz kezdés. Legelőször is, kihagyni a specifikáció írását a létező legnagyobb szükségtelen kockázatvállalás, amit egy szoftver projektben tehetsz. Olyan hülyeség, mint nekivágni egy inggel a hátadon a Mohave sivatagnak azt remélve, hogy ott majd úgy is "fúj a szél". Programozók és szoftvermérnökök, akik specifikáció nékül vágtak kód írásába, azt gondolják, hogy úgy is cool programozók, csípőből lőnek. De nem. Valami szörnyen terméketlenek. Rossz kódot írnak, gyenge minőségú terméket készítenek, ez óriási kockázattal fenyeget, ami teljességgel indokolatlan.

Én hiszek benne, hogy bármilyen nem triviális projekt (több mint egy hétig tart, vagy több mint egy programozó dolgozik rajta) esetében, minden esetben több időt áldozol és gyengébb minőségű kódot készítesz, ha nincs specifikációd. Elmondom azt is, hogy miért.

A legfontosabb szerepe a specifikációnak a program tervezése. Akkor is, ha egymagadban dolgozol a programon, és a specifikációt kizárólag a saját szórakoztatásodra írod - nagyon részletesen leírni, hogyan működik a program - arra fog kényszeríteni, hogy megtervezd a programot.

Látogassunk meg két elképzelt programozót két különböző cégnél. Speedy Gonzales a Roham Banán Szoftvernél, sosem ír specifikációt. "Specifikáció? Nekünk semmi szükségünk bármiféle büdös specifikációra." Ugyanekkor Mr Rogers a Pontosan Rendben Szoftver Vállalatnál visszautasít minden kódírást, amíg szőröstül-bőröstül nem specifikálta. És ők még csak kettő a temérdek képzeletbeli barátomból.

Speedy és Mr. Rogers ugyanazon dolgozik: arra van megbízásuk, hogy visszafelé irányú kompatibilitást készítsenek a saját programjuk 2.0-s változatához.

Speedy úgy határoz, hogy a legjobb út a visszafelé irányú kopatibilitás eléréséhez egy átalakító program írása, ami simán átkonvertálja az állományokat 1.0-ról 2.0-ra. Elindul a nagy durranás. Ír, ír, ír. Klikety, klikety, klatty. A merevlemez felpörög. A por felszáll. Kb 2 hét múlva van egy tűrhető konvertálóprogramja. De Speedy vevői elégedetlenek. Speedy kódja arra kényszeríti őket, hogy mindehol egyszerre átálljanak az új verzióra. Speedy legnagyobb vevője, a Kettévágott Dada RT, visszautasítja az új szoftver megvásárlását. A Kettévágott Dadáknak arra van szükségük, hogy a 2.0-s verzió az 1.0-s verzió állományain átalakítás nélkül tudjon dolgozni, anélkül hogy konvertálná őket. Speedy úgy dönt, hogy hogy ír egy visszafelé konvertáló programot, amit beköt a Mentés menüpontba. Ez okoz egy kis összevisszaságot, mert ha 2.0-s tulajdonságokat használsz, akkor úgy néz ki, mintha működne, egészen addig, amíg el nem mented 1.0-s változatú állományba. Csak ekkor jössz rá, hogy a fél órája használt tulajdonságok nem nagyon működnek a régi formátumú állományba mentve. Tehát a visszafelé konvertáló program újabb két hetet visz el, ellenben nem túl elegánsan működik. Eltel idő 4 hét.

Lássuk Mr. Rogert a Pontosan Rendben Szoftvernél (bizalmasan, "Preszoft"), ami egyike az eleve úgy szervezetteknek, hogy visszautasítja a kódolást, amig nincs meg a specifikáció. Elszúr ugyanazon az úton, amin Speedy jár, kb 20 percet a visszirányú kompatibilitás tervezésével, és kap egy specifikációt, ami kb. így néz ki:

  • Ha egy olyan állományt nyitunk meg, ami a termék régi verziójában készül, az állományt át kell alakítani az új formátumra.

A specifikációt megmutatja a vevőjének, aki a következőket mondja: "Egy pillanatra álljunk meg! Nem akarunk mi mindenkit egyszerre átállítani 2.0-ra!" Így aztán Mr. Rogers egy kicsit tovább gondolkozik, és helyrehozza a specifikációt a következőképpen:

  • Egy régebbi változattal készített állomány megnyitásakor az állomány az új formátumra kell alakítani a memóriában. Amikor ezt az állományt mentjük, lehetőséget kell adni a felhasználónak, hogy visszaalakítsa a régi formátumra.


További 20 perc telt el.


Mr. Roger főnöke, nézegetve az objektumrajzait, rátalált még egy problémára. Így aztán egy kicsit más szerkezetet javasol.

  • A kódot két felülettel kell létrehozni: V1 és V2. V1, ami tartalmazza az első verzió tulajdonságait, és a V2, ami örökléssel származik a V1-ből, hozzáadva az új tulajdonságokat. Na most V1::Mentés megoldja a visszafelé irányú kompatibilitást, míg V2::Mentést lehet minden új dologra használni. Ha megnyitjuk a V1 állományt, és megpróbáljuk használni a V2 funkciókat, akkor a program már időben tud figyelmeztetni, hogy vagy úgy döntesz, hogy átalakítod az állomány az új formátumra, vagy hagyod az új funkciók iránti próbálkozásokat.

további 20 perc telik el.

Mr. Rogers zsörtölődik. Ez az újraszervezés el fogja venni 3 hetét az eredetileg tervezett 2 hét helyett! De megoldja a vevő összes problémáját, ráadásul elegáns módon, így aztán megy és csinálja.

Mr. Roger összes eltelt ideje: 3 hét és 1 óra. Speedy eltöltött ideje: 4 hét, de Speedy kódja nem olyan jó.

A történet erkölcsi tanulsága: kitalált pédával bármit tudsz bizonyítani. Hoppá! Nem, ez nem az, amit mondani akartam. A történet erkölcsi tanulsága az, hogy ha emberi nyelven tervezed a termékedet, több lehetőséget kipróbálni, felülvizsgálni, és javítani a terveken csak néhány percet vesz el. Senki nem érzi magát rosszul attól, ha a szövegszerkesztőjéből egy bekezdést törölni kell. De ha a termékedet programnyelven tervezed, az iteratív tervezés hetekig tart. És ami még rosszabb, az a programozó, aki csak két hetet is valamilyen kód írásával tölt, aminek problémamentesen csatlakoznia kell ehhez a kódhoz, fogalma sem lesz, hogy mit rontott el. Speedy-t vevői vagy főnöke közül senki sem tudja meggyőzni, hogy kidobja a csodálatos konvertáló kódot, akkor sem, ha nem a legjobb szerkezetű. Az eredmény az, hogy a végső termék inkább egy kompromisszum az eredeti rossz terv és az ideális terv között. Az, hogy "a legjobb terv, ami csak létezhet, de már megírtuk az összes kódot, és nem akarjuk kidobni." Nem hangzik olyan jól, mint az, hogy "A legjobb terv. Pont."

Tehát ez a specifikáció írásának az egyes számú oka. A kommunikációra fordított idő megspórolása pedig a kettes számú. Ha specifikációt írsz, akkor egyszerűen csak azt kell kifejezni, hogyan fog a program feltételezhetően működni. A csapatban mindenki elolvashatja a specifikációt. A minőségbiztosítási munkatársak elolvassák, és már tudják is, feltételezhetően hogyan fog működni, és tudják azt is, mit kell ehhez tesztelni. A marketingesek a ködös és bizonytalan tájékoztatóik írásához használják, hogy kihányhassák a weboldalra a még meg sem született termékről. Az üzletemberek félreértik, természetfölötti fantáziával kiforgatják, hogy a termék meg fogja gyógyítani a kopaszságot, a bibircsókot és a kövérséget, de ezt beveszik a befektetők, így minden rendben is van. A fejlesztők elolvassák, így aztán megtudják, milyen kódot is kell írniuk. A vevők elolvassák, így biztosítják be magukat, hogy a fejlesztők olyan terméket készítenek, amit ők meg akarnak venni. A szakkönyv írók elolvassák, és csinos kézikönyveket írnak (amit elvesztenek vagy kidobnak, de ez már egy másik történet). A főnökök elolvassák, és így úgy tudnak tenni a meeting-eken, mintha tudnák, miről is van szó. És így tovább.

Ha nincs specifikációd, akkor mindez a kommunikáció -mivel szükség van rá- megtörténik, de alkalmi (ad-hoc) jelleggel. A minőségbiztosítás akarva-akaratlanul őrületesen teker a programmal, és ha valami különöset talál, különböző ostoba kérdésekkel zaklatja és állandóan megszakítja a programozókat, hogy is kéne ennek tulajdonképpen működnie. Azon kívül, hogy ez a programozók hatékonyságának rovására is megy, a programozó azt válaszolja, amit ő a kódba beleírt, és nem feltétlenül a "jó választ". Így aztán a minőségbiztosítás teszteli, hogy a program úgy működik-e, ahogy működik, nem pedig azt, hogy úgy működik-e ahogy tervezték, ami, lássuk be egy kicsit hasznosabb lenne.

Ha nincs specifikációd, milyen vicces dolog történik vajon a szerencsétlen szakkönyv írókkal (akik nagy bajba kerülnek). A szakkönyv író gyakran nincs olyan politikai befolyásuk, hogy megszakítsák a programozókat. Sok cégnél, ha a szakkönyv írónak van mersze a programozókat zaklatni, hogy megkérdezze, hogyan lett elképzelve valaminek a működése, a programozó odamegy a főnökéhez, és elkezd arról sírni, hogy nem tud dolgozni ettől a [kifejezés törölve a szerk.] írótól. És ha lehetne, akkor ő nagyon kérné, valahogy ha lehetne, tartsák távol tőle az írót, és a főnök, hogy a termelékenységet megpróbálja fokozni, megtiltja a szakkönyv írónak, hogy bármikor is rabolni merészelje a programozó becses idejét. Azonnal felismerheted az ilyen cégeket, mivel a help állomány és a kézikönyvek nem adnak semmilyen más információt, mint amit a képernyőn már amúgy is látsz. Ha látsz egy ilyen üzenetet:

  • Engedélyezi az LRF-1914 támogatást?

és rákattintasz a „Segítség” gombra, akkor a következő tragikomikus help fejezet jön elő:

  • Választhat, hogy engedélyezi-e az LRF-1914 támogatást, vagy nem. Ha engedélyezni akarja az LRF-1914 támogatást, akkor válassza az "Igen"-t, vagy üsse le az "Y" billentyűt. Ha nem akarja engedélyezni, akkor válassza a "Nem"-et, vagy üsse le az "N" billentyűt.

Hoppá, köszi. Az teljesen nyilvánvaló, hogy szakkönyv író megpróbálta elrejteni azt, hogy fogalma sincs az LRF-1914 támogatásról. Nem kérdezhette meg a programozót, mivel (a) őt karanténba zárták, vagy (b) a programozó Hyderabadban vagy Londonban van, vagy (c) a szakkönyv szerző főnöke megtiltotta, hogy hogy zavarja a programozót, vagy bármilyen más céges betegségből kifolyólag, amiből túl sok van ahhoz, hogy számbavegyük, de az alapvető probléma az, hogy nincs specifikáció.

A harmadik számú fontos ok a specifikáció készítésére, hogy specifikáció nélkül nincs ütemterv. Az, hogy nincs ütemterved nem jelent problémát, ha doktoranduszként egy témán szeretnél dolgozni 14 évig, illetve ha a Duke Nukem következő verzióján dolgozó programozó vagy, és igazából akkor szállítasz, ha készen vagy, és amit csináltál az jó.De a valódi üzleti életben szinte minden esetben muszály tudnod, hogy mennyi ideig tart a fejlesztés, mivel a fejlesztése a terméknek pénzbe kerül. Eszedbe sem jut egy pár farmert venni, anélkül, hogy az árát megtudnád, így aztán elfogadod az üzleti döntéseket is, ahol soha nem hoznak létre egy terméket, amíg nem tudják, mennyi időbe telik, vagyis mennyibe kerül. Az ütemtervekről bővebben a Fájdalommentes szoftver ütemterv készítésé-ben olvashatsz.

A legáltalánosabb hiba, ha arról vitatkozunk, hogy valamit hogyan kellene megtervezni, de aztán a vita soha nincs lezárva. A híres amerikai "Dominos" pizzaláncnak volt egy szlogenje: "Szállítás harminc percen belül, vagy a következő egy már ingyen van." A Windows 2000 vezető fejlesztője Brian Valentine a következő mottójáról volt híres: "Döntés 10 percen belül, vagy a következő egy már ingyen van."

A legtöbb programozó szervezetben mindig tervezési viták vannak, de senki nem felügyeli, hogy döntés szülessen, általában politikai indokok miatt. Így a programozók csak az ellentmondások nélküli részeken tudnak dolgozni. Ahogy megy az idő, minden nehéz döntés egyre hátrébb tolódik. Ez a legtöbb kudarcot vallott projektnek az oka. Ha új céget alapítasz egy új technológia köré, és azt veszed észre, hogy a céged szervezeti úton nem képes döntéseket meghozni, akkor a legjobban teszed, ha bezárod, és visszaadod a pénzt a befektetőnek, mivel nem fogsz soha semmit szállítani.

A specifikáció írása a legjobb módszer arra, hogy belemélyeszd a körmeidet az összes ilyen irritáló tervezési döntésbe, mindegy, hogy nagy vagy kicsi, ami fel sem merülne, ha nem lenne specifikációd. Még a kis döntéseket is meg lehet hozni, ha a specifikációba kapaszkodsz. Például ha egy weboldalt készítesz saját tagsággal, talán nem felejtkezel el arról, hogy van olyan, amikor a felhasználó elfelejti a jelszavát, és el kell e-mail-ben küldened neki. Kíváló. De ez még nem elég ahhoz, hogy megírd a kódot. Ahhoz, hogy kódot írj, szó szerint ismerned kell az e-mail tartalmát. A legtöbb cégnél azoknak a szövegeknek a megírását, amivel a felhasználó találkozik, nem bízzák a programozókra (és a legtöbbször van is rá okuk). Így valószínüleg a marketinges, vagy a PR-es, vagy más nyelvi zseni lesz a szövegezéssel megbízva. "Kedves Misi, Itt az elfelejtett jelszavad. Kérlek ne légy ilyen gondatlan a jövőben." Ha rá vagy kényszerítve egy teljes és jó specifikáció írására (erről még ejtek majd pár szót), figyelni fogsz minden ilyen dologra, és vagy kipipálod őket, vagy megjelölöd őket nagy piros felkiáltójellel.

Rendben van. Azonos oldalon vagyunk most már. A specifikáció a mama és az almáspite. Gyanítom, hogy a legtöbben értik ezt, és a mulatságos szavalásommal semmi újat nem tanítottam. De akkor miért nem ír senki specifikációt? Biztos nem az idővel való spórolás miatt, mivel ez nem jelent semmit, és azt hiszem, a legtöbb kódoló tudja ezt. (A legtöbb szervezetben az egyetlen specifikáció ami létezik egy rövidke egy oldalas dokumentum, amit a programozó pötyögött be a Notepadba miután megírta a kódot, és miután megmagyarázta az összes átkozott tulajdonságot mind a háromszáz embernek.)

Azt hiszem azért van ez, mert az emberek nem szeretnek írni. A csillogás az üres képernyőn szörnyen frusztráló. Személy szerint az írástól való félelmemet a főiskolán küzdöttem le, ahol 3-5 esszét kellett írnom minden héten. Az írás erő. A több írás képessé tesz, hogy egyre inkább könnyebb legyen az írás. Ha arra van szükséged, hogy specifikációkat írj, kezdj egy újsággal, vagy egyszerűen hozz létre egy weblog-ot, végezz el egy kreatív író tanfolyamot, vagy egyszerűen írj egy kedves levelet a rokonaidnak, szobatársaidnak, akikkel az elmúlt 4 év alatt nem foglalkoztál. Bármi, ami arra sarkal, hogy szavakat írj egy papírra, növelni fogja a gyakorlatodat az írásban. Ha szoftver részleg vezető vagy, akkor küldd el a hegyekbe egy kreatív írás tanfolyamra azokat az embereket, akikről feltételezed, hogy nem tudnak specifikációt írni.

Ha még sohasem dolgoztál olyan cégnél, ahol volt specifikáció, akkor még sohasem láttál egyet sem. A sorozat következő részében megmutatok egy rövid, példa specifikációt, hogy meg tudd vizsgálni, és tudjunk arról beszélni, hogy mik a jó specifikáció követelményei. Olvasd El!



A fordítás alapjául szolgáló angol cikk címe: Painless Functional Specifications  

Joel Spolsky a Fog Creek Software alapítója. A Fog Creek egy apró szoftvercég, székhelye New York City. Joel a Yale egyetemen végzett, majd programozóként és menedzserként dolgozott a Microsoftnál, a Viacomnál és a Junonál.


Az itt olvasható oldalak egyetlen személy véleményét tükrözik.
Minden itt megjelenő tartalom ©1999-2005 Joel Spolsky. Minden jog fenntartva.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky