Címke: humor
2 blog bejegyzésnél szerepel:
Murphy törvénykönyve – görbe tükör IT szemmel
4 db hozzá kapcsolódó címke:
Arthur Bloch népszerű könyvéből gyűjtögettem néhány szösszenetet. Biztosan sokaknak ismerős. A címe: Murphy törvénykönyve, avagy miért romlik el minden? A gondolatokat itt-ott kiegészítettem a programozásra, szoftverfejlesztésre jellemző szemléletmóddal. Ezt a blog bejegyzést április 1-jén tesszük közzé. Nem véletlenül. 🙂 Az alap Murphy-törvényből induljunk ki: „Ami el tud romlani, az el is romlik.” Következzen 13+1 bölcsesség.
„Semmi sem olyan egyszerű, mint amilyennek látszik.” ⟹ Pláne, ha az ügyfél úgy gondolja, hogy ezt az apróságot bizony 4 perc alatt megoldja egy ügyes fejlesztő.
„Minden több időt vesz igénybe, mint gondolnád.” ⟹ Ha csak egy paraméter típusát változtatod meg egy metódusban, akkor az biztos, hogy lavinát indít és a forráskódban sok helyen kell módosítanod.
„Ha többféle dolog is elromolhat, biztos, hogy az romlik el közülük, amelyik a legnagyobb kárt okozza.” ⟹ Elegendő belegondolni abba, hogy egy WordPress-ben lehet bármennyi bővítményed, amik általában gond nélkül frissülnek, de egy apró PHP frissítéstől összedől az egész weboldal.
„Ha rájöttél, hogy egy művelet négyféle módon mondhat csődöt, s mindegyiket kivéded, menten fellép az ötödik.” ⟹ Hiába készülsz fel minden input adatra, billentyűzet- és egéreseményből adódó problémára. Egy webes űrlap esetén, egy macska mindig átfuthat a billentyűzeten. Teljesen váratlanul.
„Semmit sem lehet a kétbalkezesek ellen bebiztosítani, mert a kétbalkezesek rendkívül találékonyak.” ⟹ Egy tesztelő mindig tud olyan tesztesetet produkálni, amire senki sem gondolt korábban a tervezésnél, megvalósításnál, dokumentálásnál. Bár egy kicsit sántít ez a gondolat, mert egy tesztelő messze nem kétbalkezes, hanem tudatosan csinálja, amit csinál. Legalábbis remélem.
„Ha javulni látod a dolgokat, akkor valami fölött elsiklottál.” ⟹ Amikor azt érzed, hogy ez a sprint végre most elkészül határidőre, akkor az utolsó napon, órában, percben tutira borul valami.
„Ha egyszer összekutyulódott valami, a kijavítására tett minden kísérlet csak rontani fog rajta.” ⟹ Pláne, hogy mindenhol, még a jól megtervezett osztálykönyvtárakban is van legalább egy leggyengébb láncszem.
„Amit ember összerakott, előbb-utóbb szétesik.” ⟹ Amikor azt gondoljuk, hogy egy jó dátumkezelő funkciót kiválóan megterveztünk, rommá teszteltünk, akkor bezzeg nem 3,9 év múlva jön egy szökőév…
„Egy esemény előfordulásának valószínűsége fordítottan arányos bekövetkezésének kívánatosságával.” ⟹ Azt kár feltételezni, hogy a jogszabályok, végrehajtási rendeletek ritkán változnak. Pedig gyakran építünk sok-sok funkciót ezekre építve szinte bármilyen szoftverben, webáruházban.
„Nyomás alatt a dolgok tovább rosszabbodnak.” ⟹ Pedig kipróbáltuk az legkritikusabb adatbázis táblát 1000 db tesztadattal, de arra nem számítottunk, hogy élesben napi 500 rekord kerül bele és ugye előbb-utóbb eljön a havi zárás annyi adattal, amire nem készültünk fel. Ugyanilyen, ha nem skálázható webtárhelyen futó WordPress-re irányítunk intenzív marketingkampánnyal sok-sok látogatót és akkor egyszer csak összeomlik a weboldal a váratlan nagy terhelés alatt.
„Ha n számú alkatrészre van szükség, éppen n-1 van raktáron.” ⟹ Ez – főleg – akkor (is) igaz, ha egy SCRUM csapatban az alkatrészt kollégának tekintjük. Még szűkebb keresztmetszet, hogy legyen releváns tapasztalata is az aktuális problémához és éppen érjen is rá. És persze ne holnap menjen el a konkurenciához/külföldre dolgozni f+1 fizetésért és ne holnapután üsse el a villamos.
„Legjobban azzal ébreszthetsz magadban új gondolatokat, ha leragasztasz egy levelet.” ⟹ Korszerűsítve és adaptálva a gondolatot: miután lenyomtad a Deploy gombot egy webalkalmazás aktuális változatának publikálásához, akkor biztosan eszedbe jut, hogy mit kellett volna még beletervezni, fejleszteni a szoftver aktuális verziójába. Nem baj, hamarosan kiadjuk majd a következő frissítést is.
Eddig volt 13 bölcsesség. Azzal akartam zárni, hogy a +1-edik bölcsesség elromlott, hiszen biztosan erre is érvényes a Murphy-törvény, de inkább írok még egyet. Még jó, hogy „Murphy optimista volt”. 🙂 Ez a szerencsénk. Mi lenne velünk, ha pesszimista lett volna? 🙂
Az IT kockáknak speciális humorérzéke van. Nekünk külön kategóriákba sorolható mémek készülnek és persze magunk is gyártjuk időnként. Az alábbi összeállítást szabadon keresgélve a weben szedtem össze és csoportosítottam a szoftverfejlesztés, programozás ismert szakterületeihez, folyamataihoz kötődően. Nem fordítottam le angolról magyarra a szövegeket. Aki érti, úgyis érti. Aki nem, úgyis továbbgörget. Enjoy!
Az algoritmusok alapvető építőelemeivel, egyben a strukturált programozás alapfogalmaival illik tisztában lenni. Ismerni kell ezek működését, egymásba ágyazásának lehetőségeit. Szekvencia, szelekció, iteráció. Időnként döntéseket is hozni kell. Néha úgy érezzük, hogy túl korán, néha pedig későn. Érezzünk rá, mikor jó. Sosem árt lezárni egy-egy blokkot és tudni jól egymásba ágyazni amit kell. Azért a metódusokkal csínján kell bánni.
Nem érthetünk mindent és persze nem érthetünk mindenhez. A dolgokat különböző szemüvegen át látjuk, hiszen eltérő tapasztalatokkal rendelkezünk. Persze hasznos, ha egy csoportban értjük egymást, vagy legalább egy valaki tisztában van az ügyfél igényével. J Például a webfejlesztés során el kell fogadni, hogy vannak látványos, azonnali élményt nyújtó változtatások (pl.: design), és hosszú távon megtérülő háttérmunkák (pl.: technológiai SEO).
Azért nem árt a precíz, pontos, konkrét feladatspecifikáció. Mindez akár több szinten is megfogalmazva: fokozatosan közeledve az ügyfél bölcsészmondataitól a kockaságig. Hasznos, ha nem csak a határidő motivál. Nyilván a pénz is. 😉 Érdekek mindig ütköznek, de ezt is meg kell tanulni elfogadni/kezelni. Néha csupán az erősebb kutya esete áll fenn, néha a hatáskörig is megy a történet.
Mivel a különböző kapcsolódó szakterületeken tevékenykedő szakemberek szókincse eltérő, így ezekből gyakori és tipikus félreértések születhetnek. Ha a fejlesztés hosszabb ideig tart, akkor menet közben is változhatnak – és változnak is 😉 – az igények. Célszerű lenne folyamatokban gondolkodni és feltenni némi empátiával azt a kérdést, hogy igazából mit is akar az ügyfél? Vajon milyen problémát szeretne megoldani, milyen folyamatot tenne könnyebbé a fejlesztendő/karbantartandó szoftverrel? Egy bizonyos szint felett az interdiszciplináris megközelítés elengedhetetlen. Visszacsatolás során kiderül(het), hogy az ügyfél hogyan használja a szoftvert. Lehet, hogy teljesen másképpen, mint ahogyan gondolnánk. Örök bölcsesség: a tervezésre fordított idő később mindig többszörösen megtérül.
Előbb-utóbb eljön az a szint, ahol már a különböző módszertanok is megjelennek. Ezekhez is alkalmazkodni kell. Minden fejben kerül helyre. Ezek többnyire a folyamatokhoz, a napi/heti munka szervezéséhez/ütemezéséhez is kapcsolódnak.
Sokféleképpen mérhető/értékelhető egy fejlesztő munkája. Nyilván nem kilóra, például a megírt forráskód sorainak számával. Persze egy komplex szempontrendszernek lehetnek/vannak kvalitatív és kvantitatív mutatói.
Sosem az számít, hogy milyen hatások érnek bennünket. Az a fontos, hogyan reagálunk ezekre. Semmi sem könnyű, de természetesen erről is különbözőképpen gondolkodunk. Helyén kell tudni kezelni a dolgokat és akkor minden fenntartható hosszú távon. A programozást elkezdeni sosem késő, vagy másképpen: nem lehet túl korán kezdeni? Mindez nézőpont kérdése.
Legyünk tisztában a tesztelés alapjaival és folyamatával is. Ha lefuttatjuk még egyszer az összes tesztesetet, azzal biztosan nem rontunk el semmit. 😉
Sokan és sokszor nem szeretünk dokumentálni. Bárki bármit mond és tapasztal, a dokumentálás szükséges és hasznos. Ugye senki sem gondolta, hogy ebből a mém gyűjteményből Chuck Norris kimaradhat? 😉
Tisztában kell lennünk a helyünkkel a csoportban: feladatkör, pozíció, felelősség, szerep, kommunikáció. Három fontos kulcsszó: konfliktuskezelés, időmenedzsment, érdekérvényesítés. És persze a hatékony csoportmunkához szükséges soft skillek is előtérbe kerülnek. Kevesek működnek alapból/ösztönösen jól együtt csoportban, a többségnek ezzel tudatosan foglalkoznia kell. Ne éljünk a tipikus csoportmunka hozzáállással: „megcsináltam”, „elrontottuk”. Ezzel megvolt a kötelező cicás kép, már triplán is. 😉
A programozási nyelvek csupán eszközei annak, hogy amit kigondoltunk, megterveztünk, modelleztünk, azt megvalósítsuk és működjön asztali gépen, böngészőben, telefonon. Elveket, koncepciókat is meg kell érteni. Kihagyhatatlanok az alapvető algoritmusok, adatszerkezetek. Meg kell ugrani az objektumorientált paradigmát is. A funkcionális paradigma is egyre népszerűbb. Hasznos, ha a tanulás során el tudjuk fogadni a tapasztaltabbak véleményét, javaslatait. Többnyire elsőre nem alkotunk tökéleteset, de minden hibából tanulunk. Tudomásul kell venni: nincsenek átugorható lépcsőfokok. Egyszerűen kell egy kritikus tömegű önálló gyakorlás és utána jön a sikerélmény.
Ha elszántad magadat és szoftverfejlesztést/programozást tanulnál Java nyelven, akkor jó helyen jársz. A Jelentkezés lapon követheted, mikor indulnak csoportjaink.