IT blog
Szakmai tanácsok, új módszertanok, hogy napról-napra jobb fejlesztővé válhass.

Elkerülendő szoftverfejlesztési hibák - 1. rész

IT 2015. június 12. Kóbor Ádám

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

measurement

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

prioritization

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"

over-analyzation

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

cable mess

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

Címkék

Hasonló cikkek