Szintek

Van egy projektem, amiben a lil-guit használtam. Úgy tűnt, nem lehet benne a kontrollereket csoportosító foldereket dinamikusan üríteni, ezért lecseréltem egy hasonló tudású másikra, a tweakpane-re. Ez eddig nem olyan érdekes, inkább a hozzáállásom változása az.

1. kezdőként, mondjuk 20+ éve naivan átírtam volna az egész kódot, hogy lecseréljem a régi ui hívásokat az újra

2. gyakorlott szakiként mondjuk ~10 éve, gondos munkával írtam volna egy wrappert, hogy innentől ez ne jelentsen gondot, és bármikor cserélhessem a ui-t a jövőben is

3. most viszont végiggondoltam, hogy a wrapper 2-3x annyi munka, mint átírni a kódot (ahogy az 1. pontban), másfelől kicsi az esélye, hogy mégegyszer váltok, mert a jelenlegi scope-ban szükséges feladatokat ez már tudja. Harmadrészt a wrapper se garancia arra, hogy a legközelebbi váltásnál csak a gui specifikus dolgokat kell cserélni, simán eszkalálódhat mélyebb (magasabb) rétegekbe a dolog, ha olyan az új framework - így simán csak átírtam a kódot, ahogyan kezdőként is tettem volna🤷‍♂️

( asch v | 2024. 05. 03., p – 15:14 )

Van egy rakás olyan programozási okosság, ami divatba jött aztán kiderült róla, hogy annyira nem is jó. A példád jól demonstrál egy ilyet, hogy logikusnak tűnik, hogy kell ide egy abasztrakt réteg, amitől majd mennyire egyszerű lesz minden, de valójában meg tök fölösleges, mert az áttérést egyszer kell megcsinálni, és az absztrakt réteg helyett - gondolom - agyatlan search and replace jellegű munkával meg lehet oldani.

A kedvenc ilyen témám a "clean code", ami óriási divat lett, és sokáig szinte senki nem kérdőjelezte meg a létjogosultságát. Aztán meg mégis, például Molly Rocket - Clean code horrible performance: https://www.youtube.com/watch?v=tD5NrevFtbU Ugyanennek a youtubernek van egy másik videója is, ahol egy clean code "iskolapéldát" kb 5 osztály helyett megvalósít 10 sorban. Ami persze "átlathatatlan spagettikód" gondolom egy clean coder szerint :-)

Most éppen ezt nézem, ami viszonylag friss videó ami lazán kapcsolódik: I Interviewed Uncle Bob - ThePrimeTime https://www.youtube.com/watch?v=UBXXw2JSloo Azért érdekes, mert az interjút készítő ember a Molly Rocket-et is interjúvolta teljesítmény témában, és ő is a Clean Code kritikusa. Uncle Bob pedig a Clean Code szerzője (AFAIK).

Egy másik vitákat indító téma az Agile, amiről szintén van szó az előző linkelt videóban. Ugye egyre többen mondják, hogy kiégéshez vezet, és hogy egy csomó esetben egyáltalán nem annyira hatékony, mint szerették volna.

Van egy rakás olyan programozási okosság, ami divatba jött aztán kiderült róla, hogy annyira nem is jó.

Én azt gondolom, hogy ilyen talán nincs is egyáltalán. ;-)
Olyan lehet, amit az okosabbak már előre tudnak, hogy bizonyos szempontok szerint nagyon jó, más szempontok szerint meg nagyon rossz. Köztük pedig ott van minden szint.

Clean code is ilyen, illetve a Clean architecture is.

Ezek pl. akkor nagyon jók, ha sokan dolgoznak egy adott dolgon, nagy méretű, vélhetően többször is kell módosítani, jól tesztelhető kell legyen, könnyen érthető, viszonylag kevés hibával, ...

Ha kicsi kell, egy személy csinálja, hobbi projekt, fontos a teljesítmény, ..., akkor viszont esetleg nagyon rossz.

Illetve egész másként néz ki ugyanaz az okosság egy adott nyelven, mint egy másikon.
Azon is sok múlik, hogyan valósítod meg az adott okosságot.

Ui.:

Clean Architecture with Spring Boot: A good idea?

Egy kis projektet megvalósít hagyományos (common) módon, illetve Clean Architecure-rel (simplified). Leírja mit, hogyan csinált, majd a végén különböző metrikákat mutat: karbantarthatóság, módosítás költsége, fájlok illetve sorok száma. Utóbbi kettő indikálja, hogy mekkora többlet költsége lehet a Clean Arch.-nak az alap fejlesztésnél.

Viszonylag sokat foglalkozom meglévő kódbázisok analizálgatásával, és egyre többre értékelem a lokalitás princípiumát, azaz hogy lehetőleg mennél több dolog legyen egy helyen, hogy lássuk, hogy mi történik. A nagyon rövid metódusokból sokkal több kell, mintha megengednénk, hogy valami hosszabb legyen. És az ugrálás követése plusz mentális erőt igényel. Ezért nem tartom jónak a Clean Code-nak ezt a princípiumát. Azt állítja, hogy egyszerűbb megérteni, ha rövid a metódus. Ez még igaz is, hogy egy hosszabb metódusnál egyszerűbb. De mondjuk 5 rövid metódus már simán lehet bonyolultabb mint egy hosszú. Bár abból a szempontból csak jól járok vele, hogy junioroknak esélye sincs megérteni mi történik, nem kell attól félni, hogy lecserélnek minket :-)

Hasonlóan egyébként a CPU is díjazza a lokalitást, meg a fordítók is, mennél kevesebb az absztrakció annál jobban tudnak optimalizálni.

(A linkelt cikket majd megnézem, egyelőre anélkül reagáltam.)

Nem, 5-10 sort szoktak mondani a Clean Code-ban. Tehát egy képernyőnél is kisebb. Azzal egyetértek, hogy _többnyire_ egy képernyőbe már jó ha beleférünk, de ha meg nem, az nem tragédia, sőt előfordul, hogy az a jobb. Ésszel kell dönteni mindig a helyzetnek megfelelően.

Igen, az együvé tartozó dolgoknak sokkal jobb, ha egy helyen vannak. Kiszervezni csak olyan dolgokat érdemes, amik már egy absztrakciós szinttel  lentebb vannak, tehát az adott rész megértéséhez nem kell.

Nekem ez a példa tetszik nagyon:

Megkérdezel valakit, hogy: Mit csináltál a hétvégén?

  1. eset, absztrakció nélkül:
    - Reggel 6.30-kor keltem,kimentem a fürdőszobába, nyomtam egy kis fogkrémet a fogkefémre, ...
  2. eset, absztrakcióval:
    - Délelőtt játszottam a gyerekekkel, délben az "Éhes vándor" fogadóban ebédeltünk, délután kertészkedtem egy kicsit.

A 2. esetben, ha valami mélyebben érdekli, akkor belekérdez (belemegy) az adott részbe. Ha azon belül is, akkor egyre mélyebbre, de nincs ott minden egyben.

Hasonlóan egyébként a CPU is díjazza a lokalitást, meg a fordítók is, mennél kevesebb az absztrakció annál jobban tudnak optimalizálni.

A CPU igen, de a fordítók az absztrakciót sokkal jobban tudják optimalizálni (méretre, teljesítményre, párhuzamosításra). Ha valamit lekonkretizálsz, akkor nincs akkora mozgástere a fordítónak, mintha rá lenne bízva a hogyan kitalálása. A bzt-s versenyfeladatnál is ez nekem pont előjött a Zig-es megoldásnál, de máshol is láttam ilyet (pl. map, reduce, filter, ...).

Ellenpéldát is hozok, amivel erősítem azt, amit mondasz. ;-)

Solid Programming - No Thanks

Mondjuk mond benne pár hülyeséget, mert pl. fogalma sincs mi az a Liskov Substitution Principle, de ha attól eltekintünk, akkor rengeteg valid érv van benne pl. arra, hogy a túlzott absztrakció rossz.

A SOLID-ot is, legalábbis bizonyos részeit, lehet rengeteg esetben jól használni, amivel tesztelhetőbb, olvashatóbb kódot készíthetünk, de ugyanígy, akár ez az ellenkezője is lehet.

Nem úgy tervezték meg. A fájlok száma, mérete a Clean Architecture esetén nem jó, 50%-kal nagyobb lesz a kód, kb. ennyivel több erőforrás kell az elkészítéséhez.

Épp ez a lényeg! Ha csak egyszer kell megcsinálni és soha többet hozzányúlni, akkor biztosan rossz a Clean Architecture. Akkor is rossz lehet, ha teljesítményre kell optimalizálni, mert szét van forgácsolva az egész. Bizonyos részeit ilyenkor biztosan nem jó úgy csinálni. Nincs olyan architektúra, ami minden esetben jó. Sőt, semelyik principle (okosság) sem jó minden esetben.