Azzal egyetértek, hogy célszerű az elején, (már a PoC előtt) végiggondolni, hogy hova fajulhat a dolog, - én is jobban tettem volna, ha megfogadom a híres Bene Gesserit mondást, miszerint: A kezdet kezdetén kell a leggondosabban ügyelni rá, hogy meglegyen a dolgok egyensúlya.
Nade, a fene se figyelte. :-)
Igazából az a gond, hogy egy nem teljesen definiált projekt esetén az ember nem akar túl nagyot invesztálni, ezért azzal kezdi, ami a legkevesebb befektetést igényli, ÉS amit a belátható feladatra alkalmasnak vél. Én kis PoC -ot álmodtam, ha ez egy kis staikus oldal maradt volna, akkor most nem beszélgetnénk erről. A cég rendszereiben fut vagy 20-30, de lehet, hogy akár 50 különböző kis scriptem is, néhány sorostól a néhány oldalasig, ezek nem nőtték ki magukat, sokukról már meg is felejtkeztem, mert gond nélkül teszik a dolgukat.
Sok fejlesztésnél látom, hogy elkezdődik egy projekt valami igény mentén, majd ahogy halad a megvalósítás, megváltozik az igény. Ez egyébként nem feltétlen rossz, csak nyilván, problémát jelent ha túl merev volt az eredeti terv és macerás eltérni tőle, mert repedezni kezdenek a már felhúzott falak.
Nekem van egy állatorvosi ló projektem a cégnél. Erre egyrészt büszke vagyok, másrészt meg tényleg a világ vicce a dolog.
Ez egy monitorozó rendszer szerver oldala. Tudom, van ezernyi dobozos monitor rendszer, ki az a hülya aki nulláról fejleszt egyet, na, hát én. Erre több ok is volt, amelyek közül sok még máig valid, egyszer egy sör melett majd sírva röhögve mesélek róla, de leírni azért nem írom le. Na. :-)
Ez a kód 300+ kilobyte méretű. Ok, van benne komment is, de azért ez azzal együtt is sok. Viszont amit tud, hát az elég jó. A hibák álapotának követése, aktív webes GUI, high availability (feldolgozó node kiesés esetén hibatűrés, megléte esetén terhelésmegosztás), ismert hibák adatbázisa, automatikus kiértesítés, email és SMS csoportok kezelése, automatikusan több szálra skálázódó adatfeldolgozás, a koncepcióból adódóan kifejezetten jó jel/zaj arány előállítása, ismert probléma esetén a riasztás kikapcsolása, DoS védelem, és egyszerű bővíthetőség pluginokkal. Valamint egy automata teszt rendszerrel is rendelkezik az állapotgép teszteléséhez, szóval a core funkcionalitás bármilyen nem triviális módosítás után validálható.
Ezt 5 éve kezdtem írni, konkrétan nulláról. A beérkező adatokat bash scriptek küldték,és ennek az első feladata nem volt más, mint hogy aggregálja össze a beérkező üzeneteket, és ha gubanc van, akkor egy levélben küldje el az összes riasztást, és ne annyi levél jöjjön ahány riasztás történt, mint ahogy az előző rendszer tette. Ez is fél oldal kód volt cirka az elején, így hát sokáig nem volt gond azzal, hogy bash -ben írtam.
Most, 5 évvel később már más a helyzet. Ha tudtam volna, hogy ide jutunk, akkor eleve pythonban kezdem.
Két-három fordulópont volt amikor felmerült az átírása.
Első alkalommal, amikor már nehezen volt kezelhető a mérete az egyetlen forrás filenak, akkor felmerült, hogy átírom, de végül is úgy döntöttem, hogy egyszerűbb több filera szétszedni a jelenlegi kódot, és source -olni ami kell.
Másodjára amikor a bővíthetőség merült fel, illetve egy olyan funkció igénye merült fel, amire tudtam, hogy a bash nem alkalmas. De akkor meg megoldottam a godiuszi csomót azzal, hogy pluginokkal tettem bővíthetővé, mondván, hogy ha kell a nehéz funkció, akkor oda be lehet dobni akármilyen nyelven megírt scriptet is, és máris nem kell nulláról kezdeni a dolgot.
Harmadjára amikor performancia gondom volt, de ekkor jött az ötlet, hogy több szálon dolgozzam fel a beérkező trágyát, és ez szépen megolotta a dolgot.
Most olyan számomra ez a rendszer, mint a Win7 a MS számára. Szeretne tőle szabadulni, mert nem jó irány, viszont olyan kiválóra sikerült már az évek során, hogy nem tudja elengedni, és időnként még kiad rá egy kis javítást. Én a két ünnep között foltoztam be egy hibát, és tettem egy kicsit robosztusabbá egyes részeit, de nagy alapvető fejlesztést már nem szívesen tennék benne. Plugint bármikor lehet beletenni, az nem probléma, de az alapvető dolgokat nagyon nehezen lehetne benne megváltoztatni, mert a kódjában sok olyan dirty egymásra támaszkodás van, amit nem jó piszkálni.
Például, bash-ben elfogadott dolog, hogy fogok egy szöveges állománt, tr -el lecserélem a sorvége karaktereket mondjuk aláhúzásra, aztán mint string átadom egy másik parancsnak ami nem szereti a több soros bemenetet, nade visszafele az rárak egy sorvégét, ami miatt a tr amikor az utolsó aláhúzás jelet is visszalakítja sorvégére, akkor egyel több sorból fog állni a file. Ilyen baromság egy "normális" programnyelvben fel sem merül, mert nincs szükség ilyen grep | cut | awk | tr | sajatfuggveny | grep | tr | akármi csatakígyókra.
Ezt az ember valamikor valamiért ilyen gányul csinálta, és két modul így kommunikál, és jó lenne megszüntetni, mert nem elegáns, de aztán sosincs rá idő. És a kód nagyjából jó is, csak az a plusz enter a végén, és annak a workaround -je, na az egy rohadt taposóakna. Én ezt látom a bash nyelven történő programozás buktatójának, hogy nagyon könnyű ilyen egyszerű és hasznos, ámde "nem elegáns" kódot írni benne, amit jóval nehezebb emiatt karbantartani, mintha sima python lett volna, ami a saját eszközkészletében nem "sugallja" az efféle mellékhatásokkal járó megoldásokat.
Én is kaptam már örökölt bash kódot, mondván, hogy javítsam meg, - hát, inkább újraírtam, mert tele volt varázslásokkal, elenben mondjuk a logolás (ami nekem a személyi fétisem, hogy mindenem ír valamilyen szintű trace logot) na az nem volt benne, mert majd elhisszük, hogy minden úgy van ahogy reméljük. Hát nem. :-)
A bash hibakezelés elég trükkös tud lenni. Más nyelvek ezt sokkal szebben megvalósítják. Ez a hiányosság főleg akkor jön ki, amikor megváltozik a környezet. Nálam a következő történt. Volt egy load balancer elenőrzés, ahol vagy nem válaszolt a gép, vagy azt mondta, hogy "200 OK" vagy egy sorban röviden elmondta, hogy mi a kínja. Ezért a mérésben, hiba esetén én megjelenítettem, hogy mit mondott, hogy segítsem azt aki kijavítja a hibát. Ez sokáig jó is volt, majd egyszer egy deploy után válaszként kaptam egy jó kövér weblab komplett HTML forrását. Egy kicsit megrogyasztotta a dolgaimat, na. Nem erre készültem, a cut/awk nameg a regexp keresések egy kicsit nehezményezték a dolgot. Oké, más nyelven is megüti az ember a bokáját, ha nem ellenőrzi az inputot, de azért itt van egy nagyon nagy különbség!
Bash -ben olyan kicsi dolgokat írunk, többnyire "saját magunknak", ahol nincs rendes input ellenőrzés, mert tudjuk, hogy nagyjából mi jöhet be. Tipikus példa a for file in $(ls -1 /data/import); do
Aha, és ha megcsúszott az a script ami oda teszi a fileokat, és legenerált neked egymillió darab üres akármit? Akkor szívás van! De ilyenre az ember nem gondol amikor bash-an egy 5 soros vackot ír, ami bizonyos fileokat mondjuk scp -ve átlök valahova.
Egy komolyabb programnyelvben, egy komolyabb problémakört megoldva az ember hajlamosabb belerakni azokat vizsgálatokat mitől stabilabb lesz a program.
De amikor egy bash kód kinövi magát, akkor egy belső workaroundoktól, és nem kezelt lehetőségektől, vagyis potenciális hibáktól hemzsegő kód fog hirtelen nagyon fontos munkát végezni.
Én ezt látom a legnagyobb problémának.