Weblabor

Elbeszélünk egymás mellett, vagy pedig nem fogalmaztam érthetően. Egy példával illusztrálom, amit most találtam:

Itt egy, a Facebook szerverén kihasználható Remote Exploit történetét lehet olvasni, ami röviden arról szól, hogy az azonosításhoz lehetett OpenID-t használni, viszont az implementációkban volt egy bug, aminek a segítségével egy fájlt lehetett eljuttatni a szerverre, s ott fájlokat listázni vagy akár tetszőleges kódot futtatni.

Egy program egyre több objektumból/komponensből áll, viszont a fejlesztőknek se ideje, sem pedig tudása/intelligenciája nincs meg ahhoz, hogy az összes köztes interakciót átlássák, és ezek hatását felmérjék.

Az absztrakciók számának növelésével nő a hibázási lehetőségek száma és a kiszolgáltatottság, erre is hozok egy egyszerű példát:

Az embernek nagyjából 20 celsius fokos hőmérsékletre van szüksége, hogy operálni tudjon, télen emiatt fűteni kell. A fűtéshez szükséges gázra és egy konvektorrendszerre. A gázt elégetem, a melegvíz eljut a konvektorba, így meleg van a szobában.

Régen a kazánból vastag csöveken szállították a melegvizet, ami nem túl esztétikus, viszont a fizika törvénye miatt automatikusan ment benne a keringés. Amikor bevezették a vékony csöveket, a vizet el kellett kezdeni keringetni egy szivattyúval. Ennek a következménye, hogy ha nincs áram, akkor hiába fűtene a kazán, a melegvíz nem tud eljutni a konvektorba.

Ez egy nyilvánvaló absztrakció, aminek az állítása: meleg van, fűtünk. A lényegtelen, elhanyagolt információ az, hogy ehhez gázra és áramra van szükség. Ha ezek közül valamelyik hiányzik, szivárog az absztrakció, és hideg van.

Tegyük fel, hogy továbbfejlesztjük a koncepciót, és az IoT jegyében elektronikus hőmérővel és mikroszámítógéppel váltjuk ki a termosztátot. Ha ez elromlik, vagy már nem szerezhető be, esetleg feltörik az interneten keresztül, megint nem lesz fűtésem.


A fentiekből következik, hogy a rendszerben lévő modulok számát a szükséges minimumon kell tartani, akár rendszerrel szemben támasztott követelmények számának csökkentésével. Fel kell tenni a kérdést: valóban szükség van erre és erre?

Egy ismerősöm autókereskedőknek fejlesztett webshopokat. Itt úgy mennek a dolgok, hogy a kereskedők folyamatosan nézik a konkurencia weboldalait, és amint megjelenik egy újdonság, azonnal kérik a sajátjukba ugyanazt. Ez az ész nélküli komplexitásnövelés beláthatatlan következményekkel jár.

Ebben tökéletesen igazad van, viszont ebből nem következik, hogy az implementáció komplexitása egyenlő a követelményekből származó komplexitással, annál nagyobb vagy egyenlő, de inkább sokkal nagyobb.

Példa:
A már sokat emlegett Ext.js-ben egy űrlapelem létrehozása átlagosan 2-8 számú öröklődési láncon keresztül történik. Az elem konstruktora megkapja a bemenő paramétereket, majd meghívja a szülői fán felfelé az összes többi konstruktorát. Ebből létrejön egy szép nagy objektum egy csomó belső tulajdonsággal.

Igen ám, de a tapasztalat szerint egy űrlapot az adott rekord adatainak kitöltése után már nagyon ritkán módosítanak. Akkor miért hozzuk létre minden alkalommal a fenti objektumot, amikor az űrlapot kirajzoljuk? Bőven elég egy darab divet kitenni a képernyőre, és csak akkor dolgozni, amikor valóban szükség van rá (valamilyen módon fókuszt kap).

Körülbelül két hete merült fel bennem, hogy egy űrlapra tulajdonképpen miért rakunk fel n darab beviteli mezőt, amikor egyszerre úgyis csak egyben lehet a kurzor? Egy ilyen elem kirajzolása elég költséges, ugyanis egy csomó eseménykezelőt rendel hozzá a böngésző; méréseim szerint nagyjából kétszer annyi idő a renderelése, mint egy divé. Bőven elég lenne kirakni mindenhova diveket, aztán, amikor rákattint valaki, akkor felé pozícionálni egy ugyanolyan méretű, átlátszó beviteli mezőt.