Meg kellett Tanulnom Újra Kódolni

2012.IV.16

Miért kellett megtanulnom újra kódolni?

Alapvetően már programozgatok egy ideje. Csináltam kisebb programokat, egyetemi házikat, gyűjtöttem statisztikákat pókerezésről a UPinak, dolgoztam cégnél és ilyenek. Namármost mind amit csináltam, azt kb újra kellett gondolnom és újra kellett tanulnom. Szerintem leginkább azért, mert a környezet amiben dolgozom megváltozott.

Régen belőttem az éppen használatos szerkesztőmet, legyen az turbo/borland pascal, visual studio, emacs vagy eclipse, megírtam a kódot ami helyesnek gondoltam, kicsit debuggoltam a hibákat, futtattam és nézegettem, és amikor meg voltam elégedve, akkor kész volt. Ez már nem megy. Igazából már a szerkesztő programnál gondokba szoktam ütközni.

Most főleg Java-ban kódolok, hát az eclipse jónak tűnik. Dehát git-et használok, úgyhogy felnyomok rá egy eGit-et. De hát nagyon sokáig tart újraindexelni a 2-3 millió sok kódon végzett változtatásokat. Meg kihal heap/GC/memória okokból, és build-elni is 5-6 perc. De végülis ez nem baj, mert most amin dolgozom annak úgysincs user interface-e, ahol látnám mit változtattam. Jah, de még adatbázis sincs igazán. Igazából teljesen esélytelen, hogy a szimpla kis gépem (64bit linux box, 8GB memória) kibírja azt a rendszert, ami 2000 szerveren fut, a világ különböző pontjain, és másodpercenként 500k kérést dolgoz fel.

Szóval akkor vissza vi/emacs szerkesztőkhöz (most nézem a CodeMirror-t), háttérben fut a headless jvm, és közben nézem hogy hogyan használhatnám a google protobuffer-jét adatkommunikációra, főleg a primitív könyvtárakkal teleoptimalizált kódjaimhoz. Közben bevezettem egy dinamikus adatstruktúrát, mert egy benchmarkból kiderült, hogy 50 elem alatt a bináris keresés egy listában gyorsabb mint egy hash-elés. (Hehe, igen a hash túl drága nálunk, ha lehet bitmask-elni vagy bináris keresni az jobb, de ha túl nagy az adathalmaz implementálnom kell bloom filter-t). Nézem hogyan tudok szimulálni adatforgalmat (mégha hdfs-t nem is), és közben mint állat írogatom a unitteszteket... különben ötletem sincs mit változtattam amíg a QA környezetébe be nem kerül a dolog. Bár a unit tesztek amúgy is alap. Főleg hamár óránként néhány másik változtatás amúgy is bekerül másik fejlesztőktől abba részbe, amit én is fejlesztek. Meg lássuk be, azért a continuous integration és regressziós tesztelés azért már nem újdonság sehol.

Mi a nagy változás? Két érdekes dolog van, egyrészt a fejlesztés fókusza megváltozott. A tradicionális fejlesztéstől eltértem, nem terméket fejlesztek, hanem platformot. És mint egy dolog ami megfelelő ecosystem nélkül nem működik, hátbizony mások a játékszabályok. Másrészt meg a technológia és a fejlesztési folyamatok megváltoztak. Teljesen mindegy, hogy éppen mit fejlesztesz, érdemes megnézni és tudni, hogy milyen technológiák vannak. Weblapot akarok fejleszteni? Node.js, css, html5, webGL, kávé és js, rails vagy django, wp, joomla vagy drupal, és a többi és a többi. Adatokat kell feldolgozni? Mennyit és hogyan? SQL vagy noSQL, MangoDB, hive, spark, zookeper és oozie, sok-sok más technológia. És érdemes ismerni, mert kevésszer van két teljesen ugyanolyan probléma, és még kevesebbszer van hogy nincs valami közeli megoldás már valahol.

Szóval megváltozott, hogy hogyan fejlesztek, és nem csak mert nagyobb cégnél vagyok és több emberrel fejlesztek mint eddig bármikor. Nem csak azért, mert a szokványos fejlesztőkörnyezetem már nem működik a problémák mérete miatt. Hanem mert megváltoztak a játékszabályok, megváltozott, hogy mi számít egy technológiai cégben és mert olyan ütemben fejlődik a világ, amivel nehéz lépést tartani, de érdemes. Szóval sebességre és méretre optimalizálok platformot. Mostmár mindent tudtok.

Elézést annak, aki eljutott idáig a cikkben, és nem technikai beállítottságú. A másik dolog amiért elnézést kell kérnem az a hunglish része a cikknek. Biztos vagyok benne, hogy mindenre van szép magyar kifejezés, de ezt azt hiszem már bebuktam.

Tagek:
 
Utoljára módosította Ulmar 2012.IV.16 19:16-n; 2 hozzászólás
PermaLink