Signal Noise Ratio

Minicube

Sziasztok, az én nevem Papp Krisztián és ez pedig a minicube podcast ötödik epizódja!

A mai témánk igen egyszerűnek tűnhet, legalábbis ha az azonos nevű wikipédia oldalból indulunk ki, de mi most a fejlesztésre vetítve fogjuk megvizsgálni ezt. Ugye a dolog nagyon egyszerű, van a jel, van a zaj és a kettőnek van egy viszonya. Nyilván minél nagyobb a zaj jelhez viszonyitott aránya, annál rosszabb a helyzet. Na de hol érdekel ez bennünket?

Hát bizony nem a fórumokon az értelmes bejegyzések versus trollkommentek aránya, habár erre a példára is applikálható. Minket inkább a kód érdekel, amit ugye nem a gépnek, hanem embereknek irunk. Ezért itt is igencsak fontos a zaj, mint olyan. Na de mi lesz itt a zaj? Volt már olyan, hogy megnyitottatok egy kódbázist és csak percekig bogarásztátok, hogy mi történik? Mi miatt lehetett ez? Szar a kód, vágja rá rögtön mindenki. Jójó, de mégis miért az?

Lehet azért, mert félrevezet. Mivel? Pl olyan kommentekkel, amik nem is szükségesek. Nincs hozzáadott értékük, csak a helyet foglalják, tehát ez is csak zaj, amit az agyunk próbál kiszűrni, de ez nem megy könnyen. Hasonló a helyzet a hosszú copyright fejlécekkel is, meg az importok a fájl elején, amiket az IDE már magától eltüntet előlünk, hogy ne is lássuk azt.

Ezek már annyira beleették magukat egyes nyelvekbe, hogy van ahol már nyelvi elem is van rá, mint pl a c#-ban a regionök. Konkrétan megadhatunk régiókat, amiket el tudunk rejteni, mert annyi minden lenne előttünk. Ezzel pedig nevesitett régiókat tudunk létrehozni, amibe aztán mindenfélét belehányhatunk anélkül, hogy a külső szemlélőt ez terhelné.

A kérdés itt az, hogy vajon jó-e az, hogy már nem csak az IDE, de maga a nyelv is ad eszközöket erre? Egyik oldalról jönnek az olyan checkstyle szabályok, hogy ne legyen hosszú a fájl, aztán jön az, hogy dugjuk el az importokat, amik aztán maguk 40-50 sort is elfogalhatnak, meg dugjuk el a régiókban levő dolgokat, amik szinte kiáltják, hogy ebből baj lesz. Aztán bumm, 600 soros osztályokat gyártunk. Az importok amúgyse ok nélkül kerültek be a fájlba. Ha sok van, akkor az azt jelenti hogy a fájlnak sok a függősége, ezzel instabillá téve azt, de ez már egy másik téma.

Na de tegyük fel nincs rengeteg import, meg nincsenek kommentek, amik hibásan azt irják le mit csinálnak és nem azt, hogy miért. Miféle zaj lehet még a fájlban? Metódusok, amiknek semmi közük ahhoz, amit mi épp meg akarunk oldani. Ezért is fontos, hogy valamiféle sorrendiség legyen benne és azok a függvények vagy metódusok, amik egymást hivják sorban legyenek. Nyílván van kódnavigáció, de több sort látunk egyszerre és jó lenne, ha amit látunk az összetartozó és lényeges. Persze itt elő is jön a sokszor félreértelmezett single responsibility is, csak kicsit más szemszögből. Ami nem oda tartozik, azzal ne is terheljük a saját agyunkat.

Ide tartozik még a pattern driven development, amikor úgy érezzük, hogy fú, de kipróbálnánk az xy tervezési mintát, de hol kéne azt… Hát persze, hogy az éles kódban, amivel aztán majd más is fog szívni. Ebben az a legjobb, hogy elkezdjük lefejleszteni a dolgot, a nulladik időpillanattól kezdve az adott mintát használva, még ha nem is oda való és aztán ebből lesznek azok a singletonok, amiket utólag cserélni lehet, mert nem is singletont akartunk, a visitorok, amik egy elemet járnak be, meg a builderek, amik igazából factoryk, meg a factoryk, amik igazából egy osztályba rejtett new statementek. Folyamatosan megtévesztjük az olvasót, mert az amit lát, nem szolgál semmiféle értéket.

Majdnem elfelejtettem azt, amire igencsak tudok ugrani, főleg reviewkon. Lehet csak engem zavar, de ha egy fájl nincs megformázva, valahogy az is képes elterelni a figyelmem és megnehezíti az értelmezését. Itt egy behúzás, ott kicsit más, itt van space, amott hiányzik. Nem csak a szépérzéket triggereli, elhihetitek. A másik kedvenc még az impl utótag, ami ugye azt hivatott közölni, hogy ez az implementációja valaminek, de nem tudtunk jobb névvel előállni, hogy mégis miféle implementációja is, így odabiggyesztjük ezt. Fontos? Fontos tudni, hogy ez egy implementáció? Ha az, akkor nem lenne jobb azt tudni, hogy mégis miféle, hiszen elvileg többet ilyet is akarunk, ha interfész mögé tettük.

Persze nem csak a kódban lehet zajforrások után kutatni. Vegyük mondjuk a ticketing és projektmenedzsment eszközöket. Igen, most inkább a PM-ekhez szólnék. Mondjuk az gyakrabban probléma, hogy az adott hibajegy hiányosan van kitöltve, de most ebbe ne menjünk bele. Inkább azt nézzük, amikor fogják és a panaszkodó ügyféltől kapott mailt egy az egyben belemásolják.

Mennyi szükséges és mennyi szükségtelen ebből? Hát ha az átlag felhasználót nézzük, akkor simán lehet, hogy az egész csak zaj lesz, az a kis jel pedig totál nonszensz. Leírja, hogy mit reggelizett, melyik oldalról navigált hozzánk, kitalált elemeket emleget, majd azt, hogy aztán kifagyott. Köszi, sokat segítettél.

De nem kell ilyen messze menni a zavaró tényezőkért. Gondoljunk csak arra, hogy mit is látunk alapból egy IDE-ben? Mennyi hasznos és mennyi haszontalan információt is ad? Most megnyitottam és azt látom, hogy plugineket kéne updatelni, a képernyő egy negyedét elfoglalja egy hatalmas toolbar, benne egy hibaüzenettel, a másik negyedét a fájlböngésző ablak, és kb a képernyő felében van ténylegesen kód. Ha ebben a kódban még van egy rakás zaj, akkor sok sikert a hatékonysághoz.

Ez volt a minicube podcast, ha tetszett a rész, akkor irjátok meg a [e-mail] cimre, addig is, találkozunk legközelebb!

---

Our GDPR privacy policy was updated on August 8, 2022. Visit acast.com/privacy for more information.