Adam Nemeth’s Blog

I have told this multiple times, maybe it’s worth a blogpost on its own. It’s mainly a reaction to recent posts of Dave West from InfoQ, and the discussions formed beneath them. Although I can feel it through what makes someone to think this way, yet I have different opinions which I would like to tell.

I have been hearing a lot of times about wether what programmers do is engineering, is science, art, or what. When I was about 18, even I had some thoughts that building software is not about engineering, but now, perhaps just because I became a master of software engineering officially (ok, it’s called engineer-informatitian in hungarian), I do think it is.

Why does the question arise? Because our daily job - at least, for a lot of us - is not based on science, but rather is about some chaotic finding-your-way thing. It rarely involves drawings and science - not gut - based calculations if you don’t explicitly insist on them, especially not in the enterprise world.

Some say 60 years ought to be enough for an engineering discipline to form, and therefore this isn’t one; I think it otherwise. I think it will take us a lot more time to find out what this thing is, even if we reached this far, and even if our profession has roots in the ancient Egyptian civilization (have you ever thought of that the basis of Egyptian tax administration is a series of calculatiosn based on water sensors and other aggregated data?).

Let’s start with two questions: what is engineering? What is software engineering?

Let me answer the first question with a personal point of view, and a second with an official one.

(more…)

Ez a poszt angolul van most, bocsi. Igaziból egy kommentem egy InfoQ-s cikkel kapcsolatban, de önmagában is megállja a helyét, így gondoltam, kirakom

Recently, a whole module of a legacy web application written in PHP4 around 10 years ago (and constantly “maintained” since) was needed to have new features.

We’re talking about 1000s of lines of code within one function, or even case of a switch case.

Most of the time, people don’t refactor maintained legacy applications, as somebody told me “the first rule of support development is: don’t change anything other than requested, just add your stuff.”

I haven’t been able to track the application back to its beginnings but its imminent to me that if-else branches don’t grow to 600 lines by themselves, without human intervention. Somebody has to mess these up, and someone has to have such kind of thinking. This is pretty general in enterprise programmng:

• most of the tasks are about legacy applications
• people fear to clean things up
• it’s not about development, but adding requested features and fixing bugs.

Also, PHP is a dynamic language, and therefore formal refactoring tools are usually unavailable. For example, PHP refactoring support in netbeans is basically non-existing.

So, what would you do here?

I decided that a system’s answer is dependent only from its input and its context. This seems pretty straightforward:


System ( input, context ) -> output


OK, what is the input of a web application? Of course, its HTTP request! In PHP, it’s hard to think about any other input.

What’s the context? Context is given by two components basically: the underlying platform, whatever it is (no matter you have a framework or just common libraries, we call these platform together), and the persistent data layer. So:


Web app (request, persistent data) -> answer


(I know, I forgot platform to add, but in refactoring scenarios, platform should stay the same anyway. In case you change platforms too, there are other complications which we won’t talk about this time.)

What’s the answer? First, it’s an HTML (or XML, JSON, etc) output. We didn’t have to care about it in this particular case. The other output is: changes to the persistence layer. It’s unusual for web applications to change anything other than their database and cache layers.So:


Web app(request, persistent data) -> (written-out response, persistent data' )


OK, what to do? We have an old system and we want to refactor it to a new system, and the question was: are they equal in functionality?

Question is: Web app == Web app' ?

Let’s see what I did:

• Ask a manual tester to go through every possible combination on the user interface
• Recorded these into files (serialize($_REQUEST)), or, even better, (serialize($GLOBALS))
• Ask the DB layer to NOT write anything to the DB (ugly global variable hack, if it is present, only select queries are executed), this way, we ensure that we keep a consistet state
• Record every writing operation (so, instead of executing them, take note of them)
• An algorhythm:
  1. load the serialized request,
  2. start recording db,
  3. run the original controller,
  4. collect db recordings,
  5. re-load request (in case it was modified by the original controller - we could never know)
  6. run the new controller
  7. collect db recordings
  8. see if the two are equal

This way, I could be sure, that in all of the scenarios a manual tester could come up with, both of the controllers behave the same way.

After the original recordings, I did a few additional points:

9. re-load the request again
10. enable db writing
11. run the new controller
12. display result.

This way I could create an - albeit slower - but seemingly normally functioning version of the software, which did everything it did previously, and it was verified that functionality haven’t changed with the new controller.

I called this blackbox-harness test.

What do you think?

Kértétek, itt van. Alapvetően itt a modultervezésről lesz szó, a komplett rendszerek tervezése egyrészről picit más tészta, másrészt ebből a szempontból meglepően sokszor van megkötve a kezünk. Érdemes elolvasni a cikket is, de a kapcsolódó két esettanulmány a legértékesebb talán.

Ha a specifikáció megvan, hányszor adjuk oda tetszőleges, az implementációs környezetet valamelyest ismerő kollegának azt, már implementált (és titokban: tesztelt) terméket várva vissza cserébe? Mi sem természetesebb ennél, nem igaz? Az alkotói szabadság, a modulok amúgyis függetlenek, a srác amúgyis megbántódna, ha beleszólnának a dolgába… ugye?

Hát egy lúf.szt.

Alapvetően a kód azon részei, amit senki nem menedzsel (nem látja senki a készítőjén kívül), fekete dobozok. A fekete doboz pedig nem elhanyagolható valószinűséggel lehet rossz, hibás. Azt, hogy megvalósítja-e egyáltalán a specifkációt, csak akkor tudjuk, ha ténylegesen leteszteltük (amit általában szintén a programozóra bízunk..). A specifikáció gyakorlatilag mindig interfészspecifikáció: azt mondja meg, adott interfésze(ke)n keresztül milyennek tűnjön a program. Lehet ez UI, lehet ez adatbázis, de lehet épp másik programrész.

A tervezés elsődleges feladata, hogy részekre válassza a megoldandó feladatot, a részek közti összefüggéseket (interfészeket) pedig rögzítse. Tehát eme fázis nem más, mint részekre bontás, és részspecifikálás.

(more…)

Objektívan nézve a szavazásban ez nyert, így ez az első, de következőnek követi majd a tervezési folyamat. Kevésbé objektíven nézve a szavazószoftver az adblockereseknek jó eséllyel nem működött megfelelően (legalábbis kaptam erre utaló visszajelzéseket), de valami alapján dönteni kellett…

A requirement analysisnek (magyarul: megtudni, mit is kéne csinálni) a gyakorlatban két módja van:

• az egyiket már félig-meddig bemutattam, ez a use-case analízis. Ez egy lassú, de biztos módszer.
• A másik egy sajátos európai módszer: a klónozás. Ez általában nem is a programozókat érinti leginkább, hanem a megrendelőket: “egy olyat akarok, mint ez”.

(Hívják ezt kreatív másolásnak is…)

Ez utóbbi módszer megrendelői oldaláról egyszer elmondtam az őszinte véleményemet. Azóta több ember nem hajlandó velem szóbaállni; olyan se, aki részt se vett benne, csak klónozott terméket felügyel. Így most csak azzal foglalkozunk, a fejlesztés műszaki vezetőjeként mit tehetsz a szituációval.

A klónozás ugyanis egy dolgot nem mond meg: hogy mi miért van ott. Pont a legfontosabbat hagyja ki, azt, hogy mikre van szükség. Nem jó általában dolgozni olyan ügyféllel, akit nem lehet túllendíteni ezen.

De mégis, mit lehet tenni?

Ha előre nem megy, kénytelenek vagyunk visszafele.

(more…)

Ez már majdnem kód… bocsi, kitaláltam valamit, kell a gondolatmenet felépítéséhez ennek az ismerete… Meg aztán remélem, haszonnal forgatjátok, megismerkedtek egy olyan eszközzel, amiről eddig sokszor csak előítéleteket hallottatok…

A modellek sokszor folyamatokat írnak le, nem struktúrákat (Beiratkozás az egyetemen, forrás: Agilemodeling.com)

Az előző postban elejtettem, hogy “a diagramjaim rendszerint rövidtávra készülnek”. Ez egy nagyon fontos mondat, szeretnék rajt elidőzni.

A modellezésről a legtöbb embernek a Model-Driven Development jut eszébe, ami egy szép elméleti elképzelés, a gyakorlatban viszont nehéz kivitelezni, bár vannak működő rendszerek, főleg bankoknál.

Pedig a modellezés fontos része a programozásnak, enélkül nem lehet átlátni a szoftvereket, nemhogy minőségi programot írni.

(more…)

A legutóbbi post után egyik olvasóm (feltéve, hogy több is van), arra kért, írjak az Agile módszerekről.

(Jövő héttől esküszöm, programozni fogunk. Suszter meg kaptafa, ugye.)

(Illetve lehet, hogy nem értek hozzá: viszont mi tudtunk határidőre is hozni dolgokat, nagyjából ezzel a készlettel. Azért ebben az iparban ez nem egyértelmű…)

A baj az, én nagyon rég vezettem projekteket, akkor is inkább vezetőfejlesztő voltam (úgy hívtam: szakmai / műszaki projektmenedzser), de leírhatom, hogy mik voltak az alapelveim a jó-hely és az azt megelőző projektek idején, és hogy látom most, akár az agilis módszertanok tükrében.

Itt szeretném halkan megjegyezni, biztos-ami-tuti, hogy ennek nem feltétlen van köze ahhoz, ahogy mostani munkahelyemen vezetnek projekteket, nem mintha nem csinálnának egy csomó dolgot nagyon jól, csak én ott fejlesztő vagyok, és nehogy valaki összekeverje.

(more…)

Az informatikának az elmélete és gyakorlata néha élesen kettéválik egymástól. Két tábor van: az egyik tábor - ők vannak kevesebben - megpróbál az elméleti principiumok mentén létrehozni egy akadémiai alapokra épülő szakmát, ahol a dolgok folyamata valamiféle profi rend szerint történik.

A másik tábor - ők vannak többen - az egyetemi tudás jó részét hasztalannak tartja, a saját életére nem érzi alkalmasnak.

Az Architect dolgok nem titkolt célja, hogy bemutassa az utóbbi tábor tagjainak, hogy igenis, érvényesek az ő életükre is ezek a szabályok. Az pedig, hogy nem így csinálják, hiányosság, ad absurdum legtöbbször hiba.

Ezt általában rendkívül gyakorlati - mindennapi munkámból vett - példák hétköznapi, az akadémiai életben kevésbé népszerű - php, javascript - nyelvekkel való megoldásán keresztül mutatom be.

A mai post ennél picit elméletibb. Én szeretném, ha ez egy kis vitát generálna köztetek, köztünk, így, író-olvasó között, már úgy értve, hogy a blogpostot mégiscsak én írtam, a kommenteket, visszajelzéseket meg majd reméljük, mások.

A Software Crisis arról szól, hogy a projektek 60%-a nem készül el időre vagy költségkeretre. Ez egy folyamatosan létező probléma, nem csupán a korai informatikára igaz, mai napig velünk van.

Amiről a software crisis nem szól, hogy azok a szoftverek, amik a végén így-vagy-úgy elkészülnek, mennyire teszik elégedetté az ügyfelet. Nem árulok zsákbamacskát, a legtöbb esetben semennyire.

Lehet ezért az ügyfelet okolni, hisz nem tudja mit akar, mindig változtat úgyis… De az építészetben ugyanez a helyzet, mégse omlanak össze az épületek, és alapvetően lakható helyeket készítenek jobb - akár magyar - építészeink.

Lehet ezért a beosztott programozóinkat okolni, de hisz legtöbben főiskolát, egyetemet végeztek, de legalábbis elkezdték: az építészetben a végrehajtók sokkal kevesebb képzettséggel rendelkeznek; mégis, a házak állnak, még a középszerű mérnökök által tervezett, vezetett projektek végén is.

Szerintem a hiba bennünk van: senior programozókban, vezetőkben, projektmenedzserekben, architektekben, bennünk, akiknek hozzáértésünket, akadémiai ismereteinket, szakolvasmányainkat kéne hozzárakni tapasztalataink mellett a projektekhez.

(more…)

A mai post kicsit alapszintűbb, műegyetemi infoképzést őszintén végighallgatók sok újat nem fognak benne találni. Az apropója egy új, fiatal kolléga a csapatban, aki teljesen új modult fog kapni, és arról beszélgettünk, ehhez hogy kell nekilátni - szerintem.

A kezdő informatikus - vagy a nem kezdő, ugyanakkor más szemléletű vagy épp autodidakta - ha kap egy feladatot, mivel kezdi?

Az adatstruktúrák felállításával.

You’re doing it wrong. *

(* Legalábbis szerintem, a legtöbb esetben)

Egy programnál sohasem az a kérdés, hogy milyen elemek vannak, ez részletkérdés. Ami a fontosabb: mit kell csinálnia annak a szegény programnak?

Erről ad információt az (egyesek kedvéért huszonötször átnevezett, elrejtett, átsematizált) use case modellezés.

(more…)

(Kettő és feledik rész, linkajánló)

A tapasztalatom az, hogy a magyar programozók, ritka ám tiszteletreméltó kivételektől eltekintve, nem szeretik, nem is értik a javascriptet. A legtöbbje backend ember, jobban megbízik a statikus nyelvekben. Szíve joga.

Egy magyar srácot hallani beszélni arról, hogy hogy használják a javascriptet szerveroldali nyelvként, mennyivel biztonságosabb és skálázhatóbb(!) a javascript kód a javahoz képest, mennyivel egyszerűbb javascriptes embereket szerezni egyszerre meglepő és felemelő érzés.

A java számomra egyértelműen túl van értékelve. Persze nem azért szidom, mint mások, de ettől még nem mindig jó megoldás ott, ahol használják, és komoly problémák vannak vele nyelvi szinten is.

Hallgassátok hát Szegedi Attila előadását a Javascript üzenet-orientált banki rendszerükről az InfoQ-n.

Frameworköt írni nem egy nagy dolog.

Tulajdonképpen minden jó programozó tud frameworköt írni, és a legtöbbje ír is. Persze a Jó Programozó azt is tudja, más, mégjobb programozók írtak frameworköket, így ő, ha teheti, nem ír sajátot.

Mi nem tehettük meg: nincs sok PHP4 framework, és létező kódhoz kellett hozzáírnunk, természetesen egy szigorú security audit előtt (aminél jobb, ha nem a mi kódunk bukik meg.)

Mi is kell egy webes frameworkhöz?

Az “Architect dolgok” második része erről szól.

(more…)