Elkerülendő szoftverfejlesztési hibák - 1. rész
Korábban írtunk már a tervezési mintákról, most azonban rendhagyó módon olyan "anti-mintákat" mutatunk nektek, amiket mindenképpen érdemes elkerülni a fejlesztések során.
Túl korai optimalizálás
Akkor beszélünk korai optimalizációról, ha elegendő információ nélkül, megalapozatlanul kezdünk el előre optimalizálni úgy, hogy azt sem tudjuk, hol, és pontosan miért lenne rá szükség.
Miért nem jó?
Azért, mert előre szinte lehetetlen megmondani, hogy mi lesz a szűk keresztmetszet egy komplex alkalmazásnál. Természetesen nem arról van szó, hogy nem érdemes előre tervezni, hanem arról, hogy feleslegesen, találgatásokra alapozva ne tegyük ezt, mert idő-, és erőforrás-igényes. Aszpirint se kapkodunk be minden nap azzal a felkiáltással, hogy "egyszer majd úgyis lesz valami bajunk".
Hogyan kerüljük el?
Helyezzük előtérbe azt, hogy a kódunk átlátható, és jól olvasható legyen, használjunk bevált, és már tesztelt algoritmusokat, és eszközöket. Mérésekre, és megfigyelésekre támaszkodjunk, ne a feltételezéseinkre!
Példák és jelek
- Már az előtt cache-elünk, hogy bármit megmértünk, teszteltünk volna
- Matematikailag helyes, bizonyított algoritmusok helyett rögtön világmegváltó ötletekre építjük az alkalmazásunkat
A trükkös rész
A trükkös rész ebben az esetben egyenlő azzal, hogy egyáltalán felismerjük, mikor felesleges, túl korai az optimalizálás. Gyakori probléma ugyanis, hogy egy felesleges optimalizálást arra használnak a fejlesztők, hogy elfedjenek vele eleve rosszul megírt algoritmusokat, pl: implementálnak egy O(n2) futásidejű algoritmust, miközben létezik O(n) megoldás is, de utóbbit nem értik igazán, így inkább az időigényesebb, de egyszerűbb megoldást választják.
tl;dr
Először mérjünk! Ne áldozzuk fel az egyszerűséget a teljesítmény kedvéért, egészen addig, amíg nem indokolt.
Rossz priorizálás
Hívják angolul bikeshedding-nek is, a kifejezés C. Northcote Parkinson-tól ered, aki megfigyelte, hogy egy erőmű tervezésekor a lényegi pontok helyett a döntőbizottság olyan kérdésekkel volt inkább elfoglalva, mint például hogy milyen anyagból készüljön a munkások biciklitárolója.
Miért nem jó?
Szimpla időpocsékolás.
Hogyan kerüljük el?
Egyrészt bátorítsuk a csapattagokat, hogy merjenek dönteni. Akár pénzfeldobással, akár szavazással, mindegy, de lépjenek túl a kevésbé lényeges problémákon. Inkább támaszkodjunk később A/B tesztekre, ha indokolt (UX, UI kérdésekben pl).
Példák és jelek
Napokon, vagy órákon keresztül vitatkozunk egy alkalmazás háttérszínén, vagy azon, hogy egy gomb jobbra, vagy balra kerüljön.
A trükkös rész
Nem nagyon van. A helytelen priorizálást könnyű észrevenni, csupán hozzállás kérdése, hogy időben közbelépünk-e, vagy legyintünk, és hagyjuk elburjánzani az indokolatlan vitát.
tl;dr
Triviális döntésekre ne égessünk el az indokoltnál több időt!
"Analízis paralízis"
Avagy a tett halála az okoskodás. Hívják még overthinking-nek is, vagy furán magyarosan túlgondolkodásnak.
Miért nem jó?
Azért, mert extrém esetekben nem csak irreálisan lelassít egy-egy folyamatot, hanem teljesen meg is akaszthatja azt, az is lehetséges, hogy a projekt el sem hagyja a tervezési fázist.
Hogyan kerüljük el?
A figyelem ebben az esetben is segíthet. Legyünk észnél, és próbáljunk meg időről-időre felülről tekinteni a problémára. Ha nem tudunk dönteni egy kérdésben, akkor próbáljunk meg több információt gyűjteni az elemzéshez. Ha több adatunk van, akkor ugyanis sokkal nagyobb az esélye, hogy előbbre jutunk, mint ha körbe-körbe futkosnánk, ugyanannyi tudással, ugyanazon a kérdésen rágódva.
Példák és jelek
Hónapok, vagy évek eltöltése egy adatbázis-struktúra, vagy UI megtervezésével.
A trükkös rész
Mindig kényes kérdés, hogy mikor érdemes elhagyni a tervezési fázist, és átlépni a megvalósításra, valamint a tesztelésre
tl;dr
Ne elemezzünk túl semmit, inkább keressünk új nézőpontokat, szerezzünk több információt.
Az "isteni" osztály
Ha valaki úgy gondolja, hogy egy alkalmazás összes funkcionalitását lehetséges, és érdemes belezsúfolni egyetlen osztályba, akkor nagyon téved.
Miért nem jó?
Az ilyen hatalmasra hízott osztályokat kínszenvedés refaktorálni, vagy módosítani, mivel a legkisebb módosítás is beláthatatlan közvetkezményekkel járhat a kód átláthatatlansága miatt. Ezen túl nehéz unit teszteket írni rájuk, vagy dokumentálni őket.
Hogyan kerüljük el?
A megoldás egyértelmű, használjunk sok kisebb, egyszerűbb osztályt, felosztva bennük az alkalmazásunk funkcionalitását valamilyen logikus vezérfonal mentén.
Példák és jelek
Olyan osztályokat érdemes keresnünk, melyek túl sok "felelősséggel" rendelkeznek, számtalan másik osztályt használnak, vagy épp őket használja rengeteg másik osztály.
A trükkös rész
Nagyon nehéz elkerülni, hogy egy alkalmazás életében ne alakuljanak ki ilyen óriás-osztályok. A folyamatos refaktorálás segíthet, amíg nem késő.
tl;dr
Óvakodjunk a "túl nagy" felelősséggel rendelkező osztályok implementálásától, és használatától!
Következő részünkben további hasonló hibákkal folytatjuk.
Forrás: Sahand Saba