tifyty

pure Java, what else ?

Nyitott programok

Az open source alapvetően azt jelenti, hogy a programok forráskódja elérhető a felhasználó számára. Hogy mire használhatja, az persze más kérdés: van, hogy belenyúlhat (hopp… ugrott a garancia, ami általában nem is volt). Van, hogy a módosított szoftvert el is adhatja, de van, hogy csak megtekintheti. Ebből a szempontból igen gazdag a licenc kínálat; válogathatunk.

A nyíltság azonban nem csak ezt jelenti, hanem sok minden mást is. Ha a program nem magában nyújtja a szolgáltatásait, akkor olyan felületeket használ, amelyek elérhetőek más programok számára és szabványosak. Azért ma már elég nehéz elképzelni olyan programot, ami magában elketyeg: ha mást nem, legalább az operációs rendszert figyelembe kell venni. Bár léteznek embedded rendszerek, és az is igaz, hogy csak az, hogy a program fut egy operációs rendszer alatt még nem teszi igazán nyílttá, még akkor sem, ha a forrás maga elérhető.

És az is a nyíltsághoz tartozik, hogy nem csak használ ilyen felületeket, hanem ha értelmes a dolog, akkor nyújt is. Így a felhasználók nem csak egy GUI-n keresztül manuálisan érhetik el a funkciókat, hanem más rendszerekkel összeintegrálva komplex rendszereket alkothatnak konfigurációkkal, és apró kiegészítő szoftverekkel (általában ezt értjük rendszerintegráció alatt). És ez nagyon fontos, annyira, hogy amikor még nem tervezték ilyenre a programokat akkor komoly eszközöket fejlesztetettek arra 1994 környékén (Jabberwocky Toolkit), hogy a humán felületeket meg lehessen programból hajtani. Szerencsére akkor még nem nagyon voltak grafikus felületek, és egy 25×80 karakteres VT100 terminál felület programmal való értelmezése, és meghajtása azért egy kicsit egyszerűbb, mint egy Windows felület. Különösen alkalmasak voltak erre az IBM 3270 terminálok, amelyek nem karakterenként kommunikáltak a szerverrel, hanem egy egész képernyőt lehetett/kellett kitölteni, és utána elküldeni a szervernek. Ez persze nem jelenti azt, hogy a mainframe 3270 terminált használó alkalmazások nyitottak lettek volna abban az értelemben, ahogy a nyitottságot ma értelmezzük.

És ha már ilyen messzire elkalandoztam, nem tudom megállni, hogy el ne meséljek egy másik ide kapcsolódó történetet. A nyíltság egyik élenjárója a DEC volt (akkor még használatban volt ez a név, később már csak Digital volt a hivatalos említés, amikor a kék helyett bejött a piros logó). Magyarországon is lement egy TV hirdetés, amelyik azt hirdette, hogy a nyitott szoftverek jobbak, mint a zárt mainframe-es rendszerek. A TV spotban egy ejtőernyő volt látható, amelyik szépen kinyílik, és a szlogen (nembiztos, hogy pontosan idézek): better open. Másnap betelefonált a Digital-ba valaki, hogy szeretne ejtőernyőt vásárolni.

Na akkor most `stash` és `checkout origin master`. Végül is master sempre certa est.

Csak ezért jobb-e egy programnak ha nyitott, mert több lehetőséget ad a felhasználóknak, hogy saját környezetükbe integrálva használhassák? Mostanában tanultam meg, hogy nem.

Pontos részletek meghatározása nélkül az történt, hogy egy program egy részét ki kellett nyitni, és elérhetővé tenni, a mi jó kis implementációnk helyett a felhasználók által készítendő különböző alkalmazások számára. Ez azt jelentette, hogy ezentúl nem csak az történhetett hogy JVM-en belül meghívtunk valami metódust, létrehoztunk egy/néhány osztályt, hívtuk őket, visszahívtak, paraméterek jöttek, mentek, míg végül összeállt valami. Sajnos az egész kódra ez utóbbi volt a jellemző a fejlesztés folyamán: addig masszírozta a csapat, amíg összeállt valami.

Amikor azonban ki kellett nyitni a funkciót, az történt, mint amikor egy kelést felnyitnak: a belül fortyogó sárga genny kijön és elkezdődik egy tisztulási folyamat. Pontosabban meg kellett határozni, hogy pontosan hol vannak, hol legyenek a funkcionalitási határok: ki csinál mit, mi kerül az egyik oldalra, és mi a másikra. Ezzel (utólag már) nem meglepő módon a hívó kód is tisztább lett, és egy év után látszott a JIRA statisztikákból is, hogy kevesebb az ezen területet érintő hibajegy.

Természetesen kitisztulhat egy ilyen modul úgy is, hogy nem nyitjuk ki, de általában, mint a gennyes sebnél: ez nem szokott bekövetkezni. Nem refaktorálunk, csak amikor már nagyon fáj. Vagy amikor valamilyen más ok miatt kell. Szükséges az úgynevezett “demanding need”. Ha ez nincs, akkor a gennyes kód betokozódik, és ott marad, amíg az egész program a krematóriumban nem végzi.

7 responses to “Nyitott programok

  1. Mark május 16, 2013 10:05 de.

    Ha már refactoring, akkor az jó, ha engem az “És ha már ilyen messzire elkalandoztam,” résznél elfogott egy érzés, miszerint ide most kéne egy extract method, és új posztban mesélhetnél ezekről? 🙂

  2. tamasrev május 16, 2013 5:10 du.

    Erre mondják azt, hogy a forma szabadságot ad.

  3. Mefi május 18, 2013 6:40 du.

    Nagyon jó bejegyzés, mindent összefoglal, ami a nyílt forráskódú megoldások hátterében nyugszik.

  4. Bence június 14, 2013 10:12 de.

    Szervusz, Péter! Nagyon szépen leírtad a nyílt forrású szoftverek megközelítőleg 3-4% -át, de a maradék 96-97% továbbra is közelebb áll a gennyes, fekélyes nyílt töréshez, mint a tisztulás (clean code) iskolapéldájához. Ugyan a Duna vizére lehet bocsátani egy Karavella milliókat érő, 1:1500 -as, részletes modelljét, de attól még a folyó javarészt szemetet, ürüléket és tetemeket hord. Hogy mi ezzel a gond? Reméltem, hogy a cikked alapján megtalálom a nyílt forrású szoftverek értelmét, létjogosultságát, de nem így történt. Szomorú maradtam.

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s

%d blogger ezt kedveli: