A sikeres szoftverfejlesztés elemei Filozófiai alapok — módszertani ajánlások
Szilágyi Tamás
[email protected]
c AMORES projekt konzorcium, 2014
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
1 / 57
Tartalom 1
2
Filozófia Mi a programozás? Mi a baj a szoftveriparral? Vitatkozunk? Szervezkedünk? A bonyolultságról Programozási metodológiák Módszertan A programnyelv megválasztása Bottom-up programozás Funkcionális programozás Interaktív fejlesztés Kódolási konvenciók Névadás Kommentelés
Szilágyi Tamás (
[email protected])
Világos kódolás A kerék fel(nem)találása Kifordított feltételvizsgálat Debug célú kiírások Világos kódolás redux Optimalizálás Verziókezelés
3
Ajánlott olvasmányok
A sikeres szoftverfejlesztés elemei
c AMORES 2014
2 / 57
Filozófia
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. (Rick Cook) Software and cathedrals are much the same – first we build them, then we pray. (Sam Redwine) Talk is cheap. Show me the code. (Linus Torvalds)
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
3 / 57
Mi a programozás?
Programozni annyi, mint megérteni. (Kristen Nygaard)
In fact, my main conclusion after spending ten years of my life working on the TEX project is that software is hard. It’s harder than anything else I’ve ever had to do. (Donald E. Knuth)
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
4 / 57
Mi a programozás? A program egy megadott problémára adott formalizált – azaz automatikusan végrehajtható – megoldás a problémával kapcsolatos pillanatnyi tudásunkat foglalja magába. ez a tudás a program elkészítése közben fejl˝odik, finomodik – még akkor is, ha a feladat változatlan és teljesen specifikált azonban a valóságban ez sem igaz, mert tökéletes specifikáció nincs: Ha a problémára létezne tökéletesen precíz (formális) specifikáció, akkor az maga lenne a program!1 A programozás ezért szükségképpen pontatlan, hiányos kezdetekr˝ol való, iteratívan végrehajtott kreatív építkezést jelent a tökéletes megértés felé. Ezen folyamat mellékterméke a hibátlan, kész program. 1A
program és a specifikáció közti különbség nem min˝oségi, csak fokozatbeli.
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
5 / 57
Mi a programozás? Miért olyan jó dolog programozni? a teremtés puszta öröme: az ember felépíthet magának egy saját, külön világot (amiben istent játszhat) mások számára hasznos dolgok létrehozásának öröme a bonyolult összefüggések alkotta rejtvény kibogozásának b˝uvölete mindig tanul az ember, mert a feladat soha nem ugyanaz a „közeg” végtelen formálhatósága: a puszta gondolatoknál nem sokkal több, amib˝ol építkezünk – a képzelet teremt˝o erejének semmi nem szab határt A programozás legtisztább formájában egy ellenállhatatlan varázslat, a bennünk lakozó kreatív energiák kiélésének határtalan közege.
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
6 / 57
Mi a programozás? Miért rühelljük mégis a programozást? tökéletesen kell teljesíteni – egy karakternyi pontatlanság a programban, és semmi nem m˝uködik2 a célokat mások szabják meg, mások biztosítják az er˝oforrásokat és küls˝o feltételeket – felel˝osségünkhöz mérten kevés a hatalmunk mások rossz programjaira, rendszereire kell támaszkodnunk, azokat használnunk, azokkal együttm˝uködnünk nagyív˝u terveket sz˝oni jó móka, alattomos hibákat kutatni nem az a verejtékes munkával felépített termék elkészültére (vagy már el˝otte) elavul – de legalábbis nyakunkon a következ˝o megvalósítandó cool-ság
2 Az embernek nem természetes közege a tökéletesség. Ehhez hozzáedz˝ odni a programozóvá válás legnehezebb része. Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
7 / 57
Mi a programozás? A kihívás és a küldetés ezek után valódi megoldásokat találni valódi megoldatlan problémákra korlátozott id˝okeret és adott (rendelkezésre álló) er˝oforrások révén. A hagyományos mérnöki munkánál megkövetelt m˝ugonddal kell eljárnunk, miközben hallatlan kreativitást engedhetünk meg magunknak. Csak nehogy visszaüssön! When your only tool is a hammer, every problem starts to look like a nail. When your hammer is C++, everything begins to look like a thumb.
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
8 / 57
Mi a baj a szoftveriparral? A világ nem tud szoftvert gyártani. A legtöbb projekt kudarcának oka egyszer˝uen az id˝ob˝ol és költségvetésb˝ol való kicsúszás. Miért? a becslések, el˝oirányzatok készítésének gyenge technikái3 ezek a technikák hajlamosak összetéveszteni az er˝ofeszítést az el˝orehaladással, mintha az emberek és az általuk munkával eltöltött id˝otartamok egyformák és tetsz˝olegesen csereberélhet˝oek lennének miután becsléseik bizonytalanok, a döntéshozók gyakorta nem kell˝oen határozottak, amikor a terveket módosítani kellene az ütemterv szerinti el˝orehaladás monitorozása általában gyenge a csúszás felismerésekor a természetes (és hagyományos) reakció: további emberi er˝oforrás hozzáadása, ami csak olaj a t˝uzre. Az ebb˝ol származó még nagyobb t˝uz még több olajat kíván, és így tovább, amíg be nem üt a krach 3 A kimondatlan alapfeltevés: „Minden rendben fog menni”, ami a legritkább esetben jön be... Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
9 / 57
Mi a baj a szoftveriparral? Minden programozó optimista. Lehet, hogy a varázslásnak ez a modern formája azokat vonzza, akik hisznek a happy-end-ekben? Vagy a folytonos, apró frusztrációk ezrei el˝uzik mindazokat, akik alkatilag nem a végs˝o célra koncentrálnak? „Most már biztosan jó lesz!” „Épp most találtam meg a legutolsó bugot!” → a becslés hamis alapja: minden feladatot végre is tudunk majd hajtani annyi id˝o alatt, ami ahhoz szerintünk kell Csakhogy: elképzeléseink hiányosságai és következetlenségei csak a megvalósítás során derülnek ki! Szeretjük a kezdeti tervek tökéletlen voltát okolni a végs˝o kudarcért, elfelejtve, hogy a sikeres projektek is tökéletlen tervekb˝ol indultak. Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
10 / 57
Mi a baj a szoftveriparral? A tervek jobbára az el˝ozetes vágyálmokat tükrözik. Természetesen el˝ofordulhat, hogy egy bizonyos feladat éppen a terv szerint készül el, hiszen a csúszás valószín˝uségi eloszlásában a „nincs csúszás” esete is véges valószín˝uséggel szerepel. Egy összetett, sok részb˝ol álló feladat esetén azonban annak esélye, hogy mindegyik ilyen jól sikerül, gyakorlatilag elenyész˝o. Rendszerint a tervezés alapját képez˝o metrika is téves: Az eredmények kézzelfoghatatlansága miatt a befektetett munka mennyiségét mérjük.
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
11 / 57
Mi a baj a szoftveriparral? Embernapokban számolni jogos akkor, ha a feladat kommunikáció nélkül particionálható.
Teljesen particionálható feladat
Nem particionálható feladat
Egy gyerek kilenc hónapig tart, függetlenül a résztvev˝o n˝ok számától. A résztvev˝ok közötti kommunikáció n2 -es teher, ahol n a résztvev˝ok száma. Ez hamar felemészti a particionálásból származó összes el˝onyt. Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
12 / 57
Mi a baj a szoftveriparral? A particionálhatóság legf˝obb ellenségei: az egyes komponensek debug-olása, a rendszerintegráció és a rendszerszint˝u tesztek. Ezek ugyanis szerializálják a feladatok elvégzését, illetve egyazon feladat egyszerre sok résztvev˝ot leköt.4 Optimizmusunknál fogva alábecsüljük a hibák számát, csakúgy mint kijavításuk nehézségét. → A tesztelés a szoftver életciklusának leginkább alábecsült szakasza.
4 Az
óhatatlan szervezési, logisztikai nehézségeket már meg sem említjük.
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
13 / 57
Mi a baj a szoftveriparral? Fred Brooks ökölszabálya egy szoftveres projekt id˝obeosztására: 1/
3
rész tervezés
1/
6
rész kódolás
1/
4
4
1
a tervezés a szokottnál hosszabb
rész komponens- és korai rendszertesztelés
2
a teljes ütemterv fele megy a „kész” kód debug-olására
1/
3
a legjobban tervezhet˝o munkaszakaszra allokálja a legkevesebb id˝ot
rész rendszerteszt valamennyi komponens részvételével
A rendszertesztek idejének sz˝ukössége különösen veszélyes, mert a projekt végén jelentkezik a probléma, amikor senki nem számít rá – és korrigálni sem lehet már. Brooks’ Law: Adding manpower to a late software project makes it later. Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
14 / 57
Mi a baj a szoftveriparral? Mi kell ahhoz, hogy a projekt ütemterv szerint haladjon? Az els˝o lépés, hogy van ütemterv. Az ütemterv mérföldkövekb˝ol áll, melyeknek dátuma van. A dátumok megválasztása egy becslési probléma, ami a tapasztalaton múlik. A mérföldkövek tartalmát egyetlen kritérium határozza meg: konkrét, mérhet˝o esemény bekövetkezése vagy állapot elérése.5 A szoftvernek olyan rugalmasnak kell lennie, hogy az el˝ore nem tervezhet˝o változtatásokat is végre lehessen hajtani anélkül, hogy eldobnánk. Megfelel˝oen képzett programozók jól megválasztott technikákkal készítik és dokumentálják (lásd: módszertan). A legnehezebb a visszacsatolások folyamatos fenntartása. 5A
kódolás a projekt felén át végig 90%-os készültségben tud lenni...
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
15 / 57
Mi a baj a szoftveriparral? Az els˝ore „megsikerült” rendszer számos projekt esetén alig (nehézkesen) használható túl nagy, túl lassú elszáll, lefagy, stb. Ilyenkor legalábbis egyes komponenseket elölr˝ol kell kezdeni, eldobva az eredeti „terméket”. Sokan vallják, hogy összetett, bonyolult rendszerek esetén ez a lépés nem spórolható meg, mert az igazán jó megoldás megépítéséhez szükséges tudáshoz csak így juthatunk hozzá. Plan to throw one away; you will, anyhow. (Brooks) Kivéve, ha olyan rugalmasan tudunk programozni, hogy a programot menet közben alakítjuk a problémát illet˝o, alapvet˝oen megváltozó tudásunkhoz. Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
16 / 57
Mi a baj a szoftveriparral? Mennyi id˝ot fog egy rendszer megépítése felemészteni? Mennyi er˝ofeszítés árán? Hogyan tudunk egyáltalán bármit megbecsülni? A történelmi tapasztalatok két dologra mutatnak rá: 1
A szükséges er˝ofeszítés a probléma méretének hatványával arányos: effort = const × size1.5 Kisebb feladathoz szükséges id˝o nem extrapolálható lineárisan, ahogy a százméteres síkfutás ideje sem mond semmit a maratonról.
2
A programozók id˝oegységenként adott mennyiség˝u programsort képesek legyártani, debugolni, dokumentálni. Magas szint˝u nyelven ez 5-10x annyi, mint alacsony szint˝u nyelven!
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
17 / 57
Vitatkozunk? Szervezkedünk? Bábel tornya (projekt értékelés) A Teremtés könyve szerint Noé bárkája után Bábel tornya volt az emberiség második, mérnöki értelemben jelent˝os vállalkozása. Ugyanakkor ez volt az els˝o (de messze nem utolsó) komoly mérnöki fiaskó. Vajon rendelkezésre álltak a projekt végrehajtásához szükséges feltételek? 1
világos cél? Igen, bár eleve lehetetlen volt. Azonban a projekt messze nem jutott el odáig, hogy alapvet˝o korlátokba ütközött volna.
2
emberi er˝oforrás? Amennyit csak szeretnél.
3
épít˝oanyag? Mezopotámia b˝ovelkedett agyagban, szurokban, nádban.
4
elegend˝o id˝o? Semmi jele annak, hogy bármiféle id˝okorlát élt volna.
5
megfelel˝o technológia? A gúla és a kúp eredend˝oen stabil és a nyomásból származó terhelést jól teríti. A k˝om˝uvesség abban az id˝oben már elég fejlett volt; nem ütköztek technológiai korlátokba.
Ha mindez megvolt, vajon miért vallottak kudarcot? Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
18 / 57
Vitatkozunk? Szervezkedünk? Bábel tornya (projekt értékelés) Komoly fogyatékosság két vonatkozásban lépett fel: a kommunikáció és ebb˝ol adódóan az organizáció elégtelenségéb˝ol fakadóan. Mivel nem tudtak beszélni egymással, koordinálni sem tudták a feladatot. Amint a koordináció cs˝odöt mondott, a munka leállt. A nagy programozási projektek cs˝odjéért a mai napig a koordináció hiányosságai tehet˝ok felel˝ossé: az egyes alkotórészekre vonatkozó feltételezések kimondva vagy kimondatlanul megváltoznak, szétcsúsznak: → a készül˝o rendszer egészének integritása esik szét! Hogyan kommunikáljanak a rendszert épít˝o különálló egyének és csapatok? Az elképzelhet˝o legtöbbféle módon! Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
19 / 57
Vitatkozunk? Szervezkedünk? Kommunikációs csatornák: Informális: személyes találkozások, telefon és email Megbeszélések: rendszeres projekt meetingek a különböz˝o technikai részletkérdések megvitatására, döntések meghozatalára Írott anyagok: a projekt résztvev˝oi által készített munkanaplók, memók, m˝uszaki specifikációk, leírások Az írott anyagok fontosságát nem lehet túlbecsülni! célkit˝uzések, peremfeltételek felhasználói specifikációk interfész specifikációk felhasználói kézikönyvek munkanaplók, feljegyzések teszt eredmények
Éppúgy, ahogy a lasagne-ra sem lehet túl sok sajtot reszelni, az írott dokumentációk készítését, min˝oségét és mennyiségét illet˝oen sem tudjuk azt a hibát elkövetni, hogy a lécet túl magasra tesszük.
adminisztratív memók Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
20 / 57
Vitatkozunk? Szervezkedünk? Minek ennyit írni? 1
A döntéseket és m˝uszaki tartalmakat alapvet˝oen fontos írásba önteni. A hézagok és következetlenségek csak akkor kerülnek felszínre, ha az ember megpróbálja azokat írásba foglalni.
2
A dokumentumok közvetítik az információt mindenki máshoz6 .
3
Az információk a közvetítés folytán nem torzulnak.
4
Adatbázis és checklist épül, melyet id˝or˝ol id˝ore fel lehet (és kell) használni a döntéshozatal során.
5
A dokumentumok menet közben átlényegülnek és újrahasznosulnak: ami követelmény-specifikációként indult, abból kin˝ohet a felhasználói kézikönyv.
6 Mindenki
tud mindenr˝ol? Na ugye.
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
21 / 57
A bonyolultságról A szoftver megalkotása során kétféle bonyolultság nehezíti az életünket: lényegi: a feladat esszenciális bonyolultsága – az absztrakt szoftver-entitást alkotó, a megoldandó problémát lefed˝o mindazon komplex struktúrák, melyeket fel kell építenünk, összhangba kell hoznunk egymással. esetleges: az entitások reprezentációjának részletkérdései egy adott programnyelven, és minden olyan „favágás”, amit el kell végeznünk, hogy a lényegi bonyolultsághoz hozzáférjünk. A szoftvertechnológia fejl˝odésének nagy ugrásai jórészt abból álltak, hogy az esetleges akadályokat kisebbítették vagy számolták fel. No silver bullet: a lényegi bonyolultság nem megkerülhet˝o! Azonban mindent meg kell tennünk annak érdekében, hogy az esetleges bonyolultságot a minimumra szorítsuk.
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
22 / 57
A bonyolultságról A lényegi bonyolultság teszi a szoftvert a világ legnehezebben „gyártható” termékévé. Forrásait a szoftver alábbi tulajdonságai adják: komplex: A szoftver méretéhez viszonyítva bonyolultabb, mint bármi más, mert nincsenek benne ismétl˝od˝o, egyforma részek.7 Ez a komplexitás a mérettel nemlineárisan növekszik. konform: Gyakran fellép˝o küls˝o követelmény egy már létez˝o szabványnak vagy interfésznek való megfelelés, amelynek problémáját semmilyen egyszer˝usítéssel vagy újratervezéssel nem lehet megkerülni. alakítható: Folyamatos a változtatásra irányuló nyomás. Hagyományosan „legyártott” termékek esetén újabb modellek kibocsátása valósul meg, általában újratervezés mellett. láthatatlan: A szoftver, ellentétben egy épülettel vagy gépalkatrésszel, vizualizálhatatlan: struktúrája nem engedelmeskedik hierarchiába- vagy síkbarajzolhatósági, ábrázolhatósági követelményeknek. 7 Ha vannak, akkor ezeket megfelel˝ o absztrakciós eszközzel, például függvényhívással megszüntetjük. Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
23 / 57
A programozási metodológiákról Rengetegen vannak és tanulságosak. Közös bennük, hogy egyik sem érinti a programozásban rejl˝o lényegi bonyolultságot; némelyik a – szerencsésebb esetben mell˝ozhet˝o – esetleges bonyolultságot sem tudja mérsékelni. Objektum-orientált: így készíts strukturált spagettikódot! (Ez nem mindig rossz: ha eleve spagettikód lett volna, mint sok való életbeli program, akkor legalább strukturált lesz.) Design patterns: az általunk használt nyelv nem támogatja a probléma által megkívánt hatékony absztrakciókat,8 de mi csak ezt ismerjük.9 (Magasabb szint˝u nyelven a pattern láthatatlanná válna, elt˝unne.) Agile módszerek: az id˝onket programozással akarjuk tölteni (bár még fogalmunk sincs, mit gyártunk); ja és rühellünk doksit írni. A metodológiák legf˝obb csapdája, hogy a lényegi problémával kapcsolatos segítséget várunk t˝olük. Ezt csak mi tudjuk saját magunknak megadni. 8 Kezdetben 9 Peter
a szubrutin is csak egy pattern volt PUSH, CALL, RET, POP nev˝u tánclépésekkel Norvig: Design Patterns in Dynamic Programming
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
24 / 57
Módszertan
Programs must be written for people to read, and only incidentally for machines to execute. (Hal Abelson) Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it? (Brian W. Kernighan)
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
25 / 57
Módszertan Módszertanunk céljai: Adott feladatot megoldó szoftver forráskódja legyen minél kisebb I
A mérettel nemlineárisan növekv˝o komplexitás, a részek közötti kapcsolatok minimumra szorítása
A problémáról alkotott tudás minél egyértelm˝ubb ábrázolása I I
Prioritás az ember, és nem a gép felé történ˝o kommunikáció Legyenek világosak a tudásunk korlátai is!
A szoftver minél rugalmasabban alakítható legyen I
I
Bottom-up programozás révén a visszafordíthatatlan (és általában a további lehet˝oségeinket sz˝ukít˝o) döntések minél kés˝obbre halasztása Verziókezelés
Az esetleges bonyolultság mell˝ozése (minimumra szorítása) I I I
Megfelel˝o absztrakciós szint és eszközök alkalmazása Egységes kódolási konvenció következetes használata A „túlzott okosságok” csapdájának elkerülése
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
26 / 57
A programnyelv megválasztása Az esetleges bonyolultság legf˝obb forrása, hogy a feladatot túl alacsony absztrakciós szinten dolgozva próbáljuk megoldani. A program absztrakt szinten a feladathoz köthet˝o objektumokra, rajtuk értelmezett m˝uveletekre, magas szint˝u struktúrákra (listákra, fákra, gy˝ujteményekre stb.) és kommunikációra (üzenetküldés, metódushívás) épül. A konkrét gépi program bitekkel és regiszterekkel, feltételvizsgálatokkal és elágazásokkal, adatátviteli csatornákkal, tárral stb. operál. A legtöbbet azzal nyerhetjük, ha olyan programnyelven dolgozunk, amely a problémának a számunkra érdekes fogalmakkal való ábrázolása elé a legkevesebb akadályt gördíti. Az absztrakciók a legjobb barátaink, mert lehet˝ové teszik, hogy ne foglalkozzunk a megoldás számunkra lényegtelen aspektusaival. Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
27 / 57
A programnyelv megválasztása A Blub paradoxon: A programnyelvek kifejez˝oereje széles spektrumot fed le, de ezt nehéz felismernie annak, aki csak bizonyos (a spektrum alsóbb részén fekv˝o) nyelveket ismer. Elvileg minden program megírható lenne bármely programnyelven (hiszen mindegyik általános célú programozási nyelv Turing-teljes). Gyakorlatilag sok olyan program van, amelyet lehetetlen lett volna alacsonyabb szint˝u programnyelven megírni. Az átlagos programnyelv használatával pont olyan eredményre számíthatsz, mint amit az átlagos programozók tudnak. Elég jó ez? Any sufficiently complicated C or Fortran program contains an ad hoc, informally specified, bug-ridden, slow implementation of half of Common Lisp (Greenspun’s tenth rule) Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
28 / 57
A programnyelv megválasztása Absztrakciós technikák: Adatabsztrakció: adatrejtés, els˝o osztályú típusok Funkcionális absztrakció: els˝o osztályú függvények, zárványok10 Szintaktikus absztrakció: makrók, túlterhelés Vezérlésabsztrakció: makrók, magasabbrend˝u függvények Tárabsztrakció: garbage collection Er˝oforrás-absztrakció: amit látunk vs. ahogy az meg van valósítva Programozni lehet... a nyelven: a megoldást a nyelv korlátai határozzák meg a nyelvbe: a (nyelven kívüli) megoldást a nyelv eszközeivel építjük meg a nyelvre: a megoldás és a nyelv félúton találkoznak: olyan nyelven programozunk, ami a problémához a legjobban illeszkedik, miközben ezt az ideális nyelvet a rendelkezésre álló nyelv eszközeivel felépítjük. 10 magyarul:
closure
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
29 / 57
A programnyelv megválasztása Sokat nyerhetünk azzal, ha a program egyes részeit automatikusan (akár direkt erre a célra írt segédprogrammal) generáljuk. Ehhez hasonló technika, ha a program egy vezérl˝o adatstruktúra szerint m˝uködik: lényegében egy „interpretert” írunk (kevés kód), ami a konkrét (esetleg nagyméret˝u) probléma leírását (sok adat) járja be, dolgozza fel. Mindig megéri gondolkozni azon, hogy hogyan tudnánk a probléma lényegét formálisan ábrázolni adat, nem pedig kód segítségével.11 Ilyen és ehhez hasonló „voodoo-technikákat” rendszerszinten támogatnak a magas szint˝u funkcionális nyelvek, mint például az Erlang és a Common Lisp.
11 Döntési
táblák, szabály-alapú programozás, stb.
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
30 / 57
Bottom-up programozás Az általánosan alkalmazott top-down eljárás során 1 gondosan megtervezzük, hogy pontosan mit akarunk megépíteni; 2 megépítjük. Ez a hagyományos mérnöki eljárás, ami jó eredményt ad, ha toronyra vagy hídra van szükség. Az el˝oz˝oek fényében nem meglep˝o, hogy szoftver esetén ez nem (vagy alig) m˝uködik. Nem azért, mert a tervezés nem volt elég körültekint˝o, hanem mert valamennyi kísérletez˝o, felfedez˝o munka minden program megírásának része. A bottom-up programozás segíti el˝o a szoftver rugalmas alakíthatóságát: a részekt˝ol haladunk az egész felé a komplex rendszer organikus fejl˝odés eredménye a részek átrendezésével a rendszer könnyebben átalakítható a „nagy egészre” vonatkozó döntések a végére maradnak jó intuíció kell a részek „helyes” funkcionalitásának belövéséhez Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
31 / 57
Funkcionális programozás A bottom-up építkezés el˝onyei akkor a leger˝osebbek, ha funkcionális programozási stílussal ötvözzük. Ezt bármilyen programnyelven megtehetjük! A funkcionális programozási paradigma a számításokra kifejezések kiértékeléseként tekint12 a mellékhatások és a globális állapot mell˝ozésére törekszik hivatkozási transzparenciát ad: x = y → f (x) = f (y) A funkcionális (stílusú) program helyességér˝ol könnyebb meggy˝oz˝odni (kevesebb, triviálisabb bug!) hatékonyabban fordítható, könnyebben optimalizálható nagyobb mértékben párhuzamosítható Nem lehet a program egészét tisztán funkcionálisra megírni, de törekedni kell a mellékhatásoktól mentes és a „mocskos” részek (< 10%) elválasztására. 12 Nem
pedig utasítások végrehajtásaként, mint az imperatív programozás.
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
32 / 57
Interaktív fejlesztés A tapasztalat szerint nagy termelékenységi el˝onnyel jár, ha minél feszesebb, pörg˝osebb ciklusokban tudjuk a változtatásainkat elvégezni és kipróbálni. Ez min˝oségileg más fejlesztést, ezzel min˝oségileg más programok elkészítését teszi lehet˝ové, éppen úgy, ahogy a telefon feltalálása is – a levelezéshez képest – min˝oségileg másfajta kommunikációt tett lehet˝ové az emberek között. Az interaktív fejlesztésben nagy segítséget nyújt nyelvünk toplevel-je, ha van neki olyan. Innen a program bármely része – annak fejlesztése közben – kipróbálható, ha pedig menet közben meg tudunk gy˝oz˝odni az egyes kis részek helyességér˝ol, a nagy egész hibakeresése is egész máshogy fest majd. Ha nincs a nyelvnek interaktív környezete, akkor érdemes minél kisebb egységeket külön lefordítható és futtatható modulokba szerveznünk, illetve a nagy programot a fejlesztés idejére úgy preparálnunk, hogy csak az éppen fontos részek fussanak. Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
33 / 57
Kódolási konvenciók
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live! Every rule can be broken, but no rule may be ignored.
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
34 / 57
Kódolási konvenciók A programkód a feladattal kapcsolatos tudásunk megjelenítésének legfontosabb eszköze. Els˝odleges célja ennélfogva az ember felé való kommunikáció. Embertársainkra13 való tekintettel mindig a t˝olünk telhet˝o legjobb min˝oség˝u kódot kell megírnunk. Ez a hozzáállás maximalizálja hosszú távon a kód (újra)felhasználhatóságát. Ez a törekvés különbözteti meg a profikat a lelkes amat˝orökt˝ol. Közkelet˝u tévedések, melyeket a valóság mindig megcáfol: ez egyszerhasználatos lesz, csak egyszer futtatom, többé nem fog kelleni úgyis csak egyedül én fogom fejleszteni majd kés˝obb visszatérek rá és rendberakom Egy program soha nincs kész, s˝ot minél sikeresebb, annál valószín˝ubb, hogy eredetileg nem tervezett módon is felhasználják. Olyanok is, akikre nem gondoltunk. 13 beleértve
saját magunkat is
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
35 / 57
(Nem csak) kódolási konvenciók Mit˝ol lesz a programkód jó min˝oségu? ˝ 14 a fordítóprogram csendben van, miközben a program lefordul I I
„szemetes kód”: a fordító hányja a warning-okat aki írta, vagy nem figyelt oda, vagy azt sem tudta, mit csinál
egységes stílusban íródik: indentálás, névadás, kommentelés I
másvalaki kódját megérteni épp elég nehéz akkor is, ha az világos és logikus szerkezet˝u, hát még úgy, ha trehány és rejtélyes nevekkel teli
kell˝oen kicsi, befogadható részekre van osztva (vö. spagetti-kód) I I
egy-egy függvény vagy blokk férjen ki egy 50 soros képerny˝ore az indentálás ne legyen 3-nál mélyebb
kihasználja a nyelv által biztosított absztrakciós eszközöket I
ha ötször kell ugyanazt csinálni, csak kicsit másképp, akkor nem öt helyen van a programban elrejtve majdnem ugyanaz a kód
14 már azon túl, hogy lefordul és azt csinálja, amit szeretnénk, de ezt mintegy kiindulási alapnak, magától értet˝od˝onek tekintjük Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
36 / 57
Kódolási konvenciók Többemberes fejlesztés esetén kívánatos megállapodni egy programozási stílusban (kódolási konvencióban), ami mindenkinek megfelel. Majd pedig ahhoz a kód megírása során mindvégig ragaszkodni. Nem a konkrét részletek fontosak, hanem a megállapodás. Eredmény: a kód struktúrája és részletei is ránézésre könnyen áttekinthet˝ok. Azon kódoké is, amiket nem én írtam. Ellenkez˝o eset: a másik fejleszt˝o által megírt kódrészlet rusnya, bottal sem piszkálom, de ami sokkal nagyobb baj, hogy nem is látom át, nem értem. Kiindulási javaslat (C nyelv˝u programokhoz): Linux kernel coding style https://www.kernel.org/doc/Documentation/CodingStyle GNU indent: a kód megadott stílus szerinti automatikus formázása Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
37 / 57
A névadásról A jó névadási stílus programnyelv-függ˝o: C: under_score_style Java: camelCaseStyle Lisp: most-chars->allowed-in-syms! Gyakorlati tanácsok: Mindig legyen értelmes (beszédes) neve a változóknak!15 A frappáns névadás nem könny˝u, tör˝odni kell vele, de megéri. Ha a program fejl˝odése során a változó szerepe megváltozott, ne legyünk restek új nevet adni neki! (Edit: Search–Replace All) FAIL: „ez csak egy segédváltozó, legyen q” → q, q1, q2, uIntq, qUint Soha ne kódoljuk bele a változónévbe a típust! Ha azon kapjuk magunkat, hogy kommentben magyarázzuk a változó szerepét, gondoljuk meg, nem tudnánk-e inkább jobb nevet adni neki! 15 ciklusváltozók:
c, i, j, k, n, m, x, y
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
38 / 57
A kommentelésr˝ol Kommentelni jó, de a túlkommentelés egy valós veszély. Ökölszabályok: Soha ne próbáld kommentben elmagyarázni, hogyan m˝uködik a kód! A kódot kell úgy megírni, hogy m˝uködése világos legyen.16 A komment arról szóljon, hogy mit csinál a kód és miért úgy, ahogy. Az egyes függvényekhez vagy blokkokhoz tartozó magyarázatot többsoros blokkokba írd, közvetlenül eléjük. Adatstruktúrák, algoritmusok dokumentálása kötelez˝o! Az „okos” megoldásokat mindig jelezd közvetlenül azok helyén I
kívánatos megindokolni, miért nem a nyilvánvaló megoldást választottad
Sorminták, dobozok rajzolása kerülend˝o, helyettük: /* This is the preferred style for multi -line comments . * Please use it consistently . * Description : A column of asterisks on the left side. */ 16 Rosszul
megírt kódot magyarázni pótcselekvés.
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
39 / 57
A világos kódolásról Mindent olyan egyszer˝uen kell csinálni, amennyire csak lehetséges, de semmivel sem egyszer˝ubben. (Einstein) Kerüljük és irtsuk ki a programkódban lév˝o felesleges bonyolításokat! Zárójelet nem akkor használunk, amikor lehet, hanem amikor muszáj. Kasztolást is csak akkor írjunk, ha nélküle a kód mást jelentene. A varázslatos értékeket kötelez˝o beszédes névvel ellátni! gps−>lon = gps−>long_deg + ( gps−>long_min / 6 0 ) ; /* NEM OK */ pan = ( int ) ( ctx−>aor−>axis1_deg ∗ 1 0 ) ; verticalAngle = ( atan ( ( ( uavHeight − gpsHeight ) ) / distance ) ) ∗ 5 7 . 2 9 5 7 8 ; if ( ! ( chksumCalc == ( unsigned char ) chksum ) ) { . . . } gps−>lon = gps−>long_deg + gps−>long_min / 6 0 ; /* OK */ pan = 10 ∗ ctx−>aor−>horiz_deg ; vertical_angle = atan ( ( uav_height − gps_height ) / distance ) ∗ RAD_TO_DEG ; if ( chksum_calc ! = chksum ) { . . . } Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
40 / 57
A kerék fel(nem)találásáról Akármilyen programot is írunk, óriások vállán állunk. Használjuk ki! Ismerjük a rendelkezésünkre álló nyelvi és könyvtári eszközöket!17 if ( p [ 0 ] == ’ $ ’ && p [ 1 ] == ’G ’ && p [ 2 ] == ’ P ’ && /* NEM OK */ p [ 3 ] == ’G ’ && p [ 4 ] == ’G ’ && p [ 5 ] == ’A ’ ) { . . . } if ( ! strncmp ( p , "$GPGGA" , 6 ) ) { . . . }
/* OK */
Rövidebb és bárki számára azonnal érthet˝o a szándék. Lehet, hogy az els˝o gyorsabb? I
Szeretném én azt a benchmarkot látni! F F
I
17 Sokat
a standard könyvtár rommá van optimalizálva a modern fordító a modern programozónál sokkal többet tud a modern architektúra bugyrairól
Még ha lassabb, akkor is ezt választom, mert sokkal világosabb. tanulhatunk mások által írt programok olvasgatása által.
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
41 / 57
Kifordított feltételvizsgálat Nagyon gyakran bevethet˝o trükk az indentációs mélységgel való spórolásra: int is_pattern_found ( char ∗ p ) { ... if ( ! strncmp ( p , "$GPGGA" , 6 ) ) { /* block on 2nd indentation level */ ... return 1 ; } return 0 ; } int is_pattern_found ( char ∗ p ) { ... if ( strncmp ( p , "$GPGGA" , 6 ) ) return 0 ; /* block on 1st indentation level */ ... return 1 ; } Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
42 / 57
Debug célú kiírások The most effective debugging tool is still careful thought, coupled with judiciously placed print statements. (Brian W. Kernighan) Hogyan helyezzünk el kulturált debug kiírásokat egy C programban? A kiírásokat általában akkor kezdjük el betenni, ha baj van A debugolás végén kiszedjük o˝ ket, mert útban vannak (zavaró output) Legközelebb kezdhetjük elölr˝ol! Érdemes eleve felkészülni a debug kiírásokra. Legegyszer˝ubb eset: egy DEBUG szimbólummal ki/bekapcsolható output ezt a forrásban vagy a Makefile-ból is beállíthatjuk
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
43 / 57
Debug célú kiírások Legegyszer˝ubb eset: # include < s t d i o . h> /* uncomment or compile with -D_DEBUG for debug output */ //# define _DEBUG ... # ifdef _DEBUG # define DBG ( fmt , . . . ) printf ( ( fmt ) , __VA_ARGS__ ) #else # define DBG ( fmt , . . . ) # endif ... int main ( int argc , char ∗∗ argv ) { DBG ( " E n t e r i n g main ( ) , a r g c : %d \ n " , argc ) ; ... return 0 ; }
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
44 / 57
Debug célú kiírások Használhatunk specializált makrókat különböz˝o típusú változók kiíratására: # include < s t d i o . h> # ifdef _DEBUG # define DBG_D ( var ) printf ( "%s = %d \ n " , #var , var ) # define DBG_C ( var ) printf ( "%s = \ ’% c \ ’ \ n " , #var , var ) # define DBG_S ( var ) printf ( "%s = \"% s \ " \ n " , #var , var ) #else # define DBG_D ( var ) # define DBG_C ( var ) # define DBG_S ( var ) # endif int main ( int argc , char ∗∗ argv ) { DBG_D ( argc ) ; DBG_S ( argv [ 0 ] ) ; DBG_C ( argv [ 0 ] [ 0 ] ) ; ...
Szilágyi Tamás (
[email protected])
/* /* /* /*
prints : argc = 1 argv [0] = "./ prog" argv [0][0] = ’.’
A sikeres szoftverfejlesztés elemei
*/ */ */ */
c AMORES 2014
45 / 57
Debug célú kiírások Deluxe változat: futásidej˝u verbosity szintek, forrásfájl és sorszám # include < s t d i o . h> # include < s t d a r g . h> int verbosity = 0 ; /* no. of -v opts minus no. of -q opts */ int dbg_print ( int vlevel , char tag , const char ∗ file , int line , const char ∗ format , . . . ) { int ret ; va_list ap ; if ( vlevel > verbosity ) return 0 ; printf ( "%c[% s :%d ] : " , tag , file , line ) ; va_start ( ap , format ) ; ret = vprintf ( format , ap ) ; va_end ( ap ) ; return ret ; } Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
46 / 57
Debug célú kiírások Deluxe változat: futásidej˝u verbosity szintek, forrásfájl és sorszám int dbg_print ( int vlevel , char tag , const char ∗ file , int line , const char ∗ format , . . . ) ; /* These symbols encode verbosity levels . */ # define D_ERR 0 # define D_WARN 1 # define D_INFO 2 # define D_DBG 3 # define p r _ e r r ( fmt , . . . ) \ dbg_print ( D_ERR , ’E ’ , __FILE__ , # define p r _ w a r n ( fmt , . . . ) \ dbg_print ( D_WARN , ’W’ , __FILE__ , # define p r _ i n f o ( fmt , . . . ) \ dbg_print ( D_INFO , ’ I ’ , __FILE__ , # define p r _ d b g ( fmt , . . . ) \ dbg_print ( D_DBG , ’D ’ , __FILE__ ,
Szilágyi Tamás (
[email protected])
__LINE__ , fmt , ## __VA_ARGS__ ) ; __LINE__ , fmt , ## __VA_ARGS__ ) ; __LINE__ , fmt , ## __VA_ARGS__ ) ; __LINE__ , fmt , ## __VA_ARGS__ ) ;
A sikeres szoftverfejlesztés elemei
c AMORES 2014
47 / 57
Debug célú kiírások Deluxe változat: futásidej˝u verbosity szintek, forrásfájl és sorszám int main ( int argc , char ∗∗ argv ) { int c ; while ( ( c = getopt ( argc , argv , " vq . . . " ) ) ! = −1) { switch ( c ) { case ’ v ’ : ++verbosity ; break ; case ’ q ’ : −−verbosity ; break ; ... } ... /* no frills - use it just like printf () */ pr_info ( " v e r b o s i t y = %d \ n " , verbosity ) ; ... if ( fubar_cnt ) { pr_err ( "FUBAR (%d ) , g i v i n g up \ n " , fubar_cnt ) ; return 1 ; } ...
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
48 / 57
Világos kódolás redux a hiba nem marad észrevétlen – fellépésekor azonnal kezeljük a programszöveg mégsincs tele egyforma hibakezel˝o ágakkal # define ALLOC( p t r , s i z e ) \ if ( ! ( ptr = malloc ( size ) ) ) { \ pr_err ( " o u t o f memory " ) ; \ exit ( 1 ) ; \ } # define REALLOC( p t r , n e w s i z e ) \ if ( ! ( ptr = realloc ( ptr , newsize ) ) ) { \ pr_err ( " o u t o f memory " ) ; \ exit ( 1 ) ; \ } struct map ∗ root ; ALLOC ( root , sizeof ( struct map ) ) ; pkt−>n_fields ++; REALLOC ( pkt−>fields , pkt−>n_fields ∗ sizeof ( char ∗ ) ) ; Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
49 / 57
Az optimalizálásról Három általános érvény˝u alapszabály: Koncentrálj az üvegnyakakra!18 most of the running time in non-IO-bound programs is concentrated in about 3% of the source text (Knuth) → el˝obb mérni, csak aztán optimalizálni, amit muszáj Ne kezdd túl korán! Premature optimization is the root of all evil (or at least most of it) in programming. (Knuth) Kezdd az algoritmusokkal! De vigyázz, mert az algoritmusokkal kapcsolatos döntéseket néha korán meg kell hozni.
18 magyarul:
bottleneck
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
50 / 57
Az optimalizálásról A jó optimalizálás alapja majdnem mindig stratégiai jelleg˝u áttörés, nem pedig alacsony szint˝u taktikai ügyeskedés: egy hatékonyabb algoritmus egy jobb adatábrázolás a probléma jobb absztrakciója vagy felosztása A programozás esszenciája a reprezentáció. Az adatok ábrázolásának, tárolásának és kezelésének formája az, ami a hatékonyságot els˝osorban meghatározza. Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious. (Brooks) Mindezt részletesen dokumentálni kell! Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
51 / 57
A verziókezelésr˝ol Mint módszertanunk összes elemét, ezt is az ember-ember kommunikáció tükrében tudjuk igazán értékelni. A verziókezel˝o rendszer a teljes fejleszt˝ocsapat kollektív emlékezete. Haszna a beletett információ mennyiségével és min˝oségével arányos. Szemét helyett értékes információt töltsél bele, és szemét helyett értékes információt fogsz tudni kinyerni bel˝ole, amikor szükséged lesz rá. Ami nincs verziókezelve, az a csapat szempontjából nincs is: Nincs kommunikáció I I
mi változott? ki min dolgozik?
Nincs kód review Nincs mások általi használat, tesztelés
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
52 / 57
A verziókezelésr˝ol Megfelel˝o használata bármely elosztott vagy kollaboratív fejlesztés során elengedhetetlen. Azonban egyszemélyes projektek esetén is er˝osen ajánlott. Verziókövetés I I
I
Bármely korábbi (kommittált) állapotba vissza tudunk állni19 Fel merjük forgatni a kódot, mert tudjuk, hogy legrosszabb esetben visszaállunk a legutolsó mentett állapotba Nincs többé „de hiszen legutóbb még jó volt, azóta meg nem nyúltam hozzá”–típusú híres utolsó mondat
Csapatmunka, koordináció I I I I
Párhuzamos munkavégzés az adatvesztés veszélye nélkül Változtatások auditálása, jogosultsághoz kötése Könnyen kideríthet˝o, hogy adott kódrészletet utoljára ki módosított A kódok kényelmes szinkronban tartása minden fejleszt˝o környezetében
Biztonság, redundancia I I
19 Például
Az adatok integritásának védelme Adattárolás több fizikai helyszínen tudni szeretnénk, hogy egy bug mikor került bele a kódba.
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
53 / 57
A verziókezelésr˝ol Mit és hogyan kommittáljunk? inkább gyakran keveset, mint ritkán sokat (felbontás!) logikailag egybetartozó változtatások összességét (changeset) I
ez lehet kevés kód (egyetlen karakternyi javítás), de lehet sok is
írjunk hozzá adekvát logbejegyzést I I I I
mi szükség van erre a változtatásra? hogyan, milyen eszközökkel éri el a célját? milyen mellékhatásai vannak? küls˝odleges vonatkozások: hibajegy száma, patch eredete, stb.
ez a metaadat lesz legkönnyebben elérhet˝o a kommittal kapcsolatban I I
ugyanolyan gonddal írjuk meg, mint a kódot, amit kommittálunk inkább írjunk a kelleténél többet, mint kevesebbet20 F F F
I
20 Ami
egy sorban: rövid, tömör leírása a változtatásnak egy üres sor kimarad több soros szövegben fejtsük ki a változtatás részleteit
tartalmasabb kommithoz értelemszer˝uen b˝obeszéd˝ubb leírás dukál
nekünk itt és most nyilvánvaló, az másnak, máskor nem biztos, hogy az!
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
54 / 57
A verziókezelésr˝ol For best results A munkamenet kezdetén I I
frissítsd a saját másolatodat (svn update vagy git pull) olvasd át a logot, hogy mások munkáját illet˝oen képbe kerülj
Kommit el˝ott I
fordítsd le a teljes kódot (nulláról, ha lehet) F
I I
lefordul? ad warning-okat? nem lehetne ezeket megszüntetni?
célzatosan teszteld le a javítást/feature-t alaposan nézd át a kommittálandó változásokat (svn diff)
Kommit után I
tényleg mindent úgy kommittáltál, ahogy tervezted? (svn status) F F
I
nem maradt-e ki egy újonnan készített forrásfájl? nem adtad-e hozzá véletlenül a lockfájlt/biztonsági mentést is?
fontos változtatás esetén küldj email-t a társaidnak
Ha több független területhez is hozzányúltál I I
próbáld ezeket egymástól elválasztva (szelektíven) kommittálni ha ez nem megy, a logbejegyzés térjen ki az összes változtatásra
Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
55 / 57
A verziókezelésr˝ol Haladóknak: gerilla-VC Saját kis kódomat egyedül fejlesztem, sokáig nem lesz stabil,21 a nagy közös repóba addig minek kommittáljak? Soha NEM megoldás a fejlesztést verziókezelés nélkül csinálni! Bonyolult helyzetekben hasznos lehet az ún. „gerilla”-verziókezelés: csinálj magadnak egy lokális Git repót az SVN-beli állapotból kiindulva a fejlesztéseket s˝ur˝un kommittálva told ebbe a repóba I
a Git végtelen szabadságot ad a kommitok utólagos rendszerezéséhez
ha kész, az egészet told vissza SVN-be (ésszel: ne 1 kommit legyen!) a git-svn segítségével mindez könnyen megvalósítható I I
a Git-ben lév˝o kommitok szelektíven pakolhatók SVN kommitokba érdemes a Git-ben eleve branch-eket használni, melyek egy-egy SVN kommittá alakulnak majd
21 A legjobb persze az, ha a fejlesztés nem így történik. Tudjuk, hogy az életben ez nem mindig érhet˝o el – a fólia arról szól, hogy ez nem kifogás. Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
56 / 57
Ajánlott olvasmányok Frederick P. Brooks, Jr.: The Mythical Man-Month Peter Seibel: Coders at Work – Reflections on the Craft of Programming Richard P. Gabriel: Patterns of Software – Tales from the Software Community Paul Graham: On Lisp Paul Graham: Beating the Averages Paul Graham: Revenge of the Nerds Eric S. Raymond: The Cathedral and the Bazaar Eric S. Raymond: The Art of UNIX Programming Abelson & Sussman: Structure and Interpretation of Computer Programs Nassim N. Taleb: Antifragile: Things That Gain From Disorder Scott Chacon: Pro Git Collins-Sussman et al: Version Control with Subversion Szilágyi Tamás (
[email protected])
A sikeres szoftverfejlesztés elemei
c AMORES 2014
57 / 57