Elkerülendő szoftverfejlesztési hibák - 2. rész
A sorozat első részében megmutattunk már néhány gyakori tévutat, lássuk hát a többit is...
Az "inner-platform" jelenség
Sajnálom, nem találtam rá jó magyar kifejezést, de ettől függetlenül a jelenség valószínűleg nem lesz ismeretlen senki számára sem: az egész nem más, mint a spanyolviasz feltalálása, vagyis egy adott nyelvben, vagy platformon már létező funkciók újbóli - jellemzően kevésbé optimalizált - implementálása.
Miért nem jó?
Azért, mert kiforrott nyelvek, és rendszerek esetén szinte egészen biztos, hogy ha már van létező megoldás, beépített metódus egy problémára, akkor nem fogunk tudni ennél optimálisabbat találni. A saját, világmegváltó ötletek viszont gyakran melegágyai a teljesítménybeli problémáknak. Továbbá jó példa az is, hogy ha "újraalkotunk" egy nyelvi elemet, akkor ez által a kód nehezebben érthető lesz azok számára, akik később csatlakoznak a projekthez (szemben a standard, elterjedt megoldásokkal).
Hogyan kerüljük el?
Képezzük magunkat folyamatosan, hogy tisztában legyünk az általunk használt nyelvek, keretrendszerek, operációs rendszerek "képességeivel", és hatékonyan használni is tudjuk őket.
Példák és jelek
- Implementálunk egy új gyorsítótárazási megoldást ahelyett, hogy a használt operációs rendszerre hagynánk ezt a feladatot.
- PHP-ban írunk egy feladatütemezőt a webszerverünk számára.
A trükkös rész
Nagyon-nagyon ritán mégis szükség lehet az egyéni megoldásokra, járjunk el ilyenkor körültekintően.
tl;dr
Ne találjunk fel újra már létező dolgokat, ha nem muszáj!
A számok és a stringek varázslatos világa
Miért használunk névtelen számokat, és literálokat, ha helyettük használhatunk szépen elnevezett konstansokat is?
Miért nem jó?
Azért, mert ha még kommentben sem jelöljük egy számnak, vagy literálnak a szerepét a kód egy adott sorában, akkor később, amikor módosítanunk, vagy refaktorálnunk kell, fájdalmas meglepetések érhetnek bennünket. Nézzük pl. az alábbi kódrészletet:
def create_main_window():
window = Window(600, 600)
# ...Milyen szerepet tölt itt be a két szám? Valószínűleg az ablak szélességét, és magasságát jelölik. Na de mi van, ha módosítanunk kell az ablak magasságát? Nem kereshetünk rá a "600" kifejezésre a kódban, hogy lecseréljük "800"-ra mindenhol, mert lehetséges, hogy olyan helyen is megtörténne a csere, ahol nem szeretnénk.
Hogyan kerüljük el?
Használjunk nevesített konstansokat, ahol csak lehetséges.
Példák és jelek
Lásd a "Miért nem jó?" résznél...
A trükkös rész
Ne essünk át a ló túloldalára: százalékszámításnál a 100, vagy paritás vizsgálatánál a 2 nyugodtan maradhat névtelen.
tl;dr
Ne szórjuk tele a kódot névtelen számokkal, és literálokkal, mert később úgyis megbánjuk!
Vakon követjük a számokat
Akkor beszélhetünk erről, ha kizárólag számosítható mutatókra támaszkodunk egy döntési helyzetben.
Miért nem jó?
Ahogy a sorozat előző részének első két pontjában is láthattuk, időnként kifejezetten érdemes mérésekre, konkrét tényekre támaszkodnunk ahelyett, hogy csupán megérzéseinkre hagyatkozva döntenénk egy adott kérdésben. Ugyanakkor ez a stratégia fordítva is elsülhet, ha olyan helyzetben alkalmazzuk, amikor az eredmény nem feltétlenül mérhető objektív módszerekkel. Ahogy Bill Gates mondta: "Ha egy fejlesztési folyamat előrehaladását abban mérjük, hogy hány sor kód készült el, az pont olyan, mint egy repülő építésekor a súlyából következtetni a készültségi fokára."
Hogyan kerüljük el?
Megfontoltan, és ne vakon használjuk a számokat.
Példák és jelek
- A forráskód hossza alapján ítéljük meg a program minőségét.
- Az alkalmazottak teljesítményét aszerint állapítjuk meg, hogy mennyit túlóráznak.
A trükkös rész
Minél több döntést kell meghoznunk, annál inkább fogunk támaszkodni automatizmusokra, ez által pedig a nyers számokra, ilyen helyzetben pedig sokkal nehezebb elkerülni a fenti buktatókat.
tl;dr
A nyers számokat döntési helyzetben mankóként használjuk, ne hagyjuk, hogy helyettünk döntsenek.
Forrás: Sahand Saba