Ülj neki, és kódolj

Van egy jó ötleted, amit eddig senki se valósított meg? Vagy nem úgy, ahogy szerinted kellene? Ha egyszerűen megoldható, akkor csak ülj le, és kezdj el kódolni!

Mindez szöges ellentétben van azzal, amit pár éve HH Hírbehozónak (Webisztán) mondtam.

A programozás rákfenéje szerintem meg pont az, amikor belecsapunk a lecsó közepébe és elkezdünk kódolni. Kell egy cél, amit el akarunk érni, ahonnan tovább akarunk menni, ahová végső soron el akarunk érni (ne kelljen már rendszertervezési kiselőadást tartanom, ha ebből élsz tudnod kell ezt jól :)) Ez pedig nem kizárólag a dobozos szoftverek sajátossága, hanem a jól megtervezett, továbbfejleszthető programoké. Ez nem jelenti azt, hogy feltétlenül UML ábrát kell rajzolni egy kis méretű, kevés funkcióval rendelkező app-hoz. […]

Ha nem is született mindig dokumentáció, de mindenhol készült egy szöveges alapú csontváz (néha mindmap) az elérni kívánt feature-ökről, ami alapján a programozást is végeztem.

A napokban egy olyan mikro méretű app-on dolgoztam, aminek összesen egy feature-t kellett megvalósítania. Ezért leültem az IDE elé, létrehoztam egy új (Java) Class file-t, és elkezdtem kódolni. Konkrétan így nézett ki:


public static void main(String[] args) {
// get XML from URL: ...
// get attribute ... from XML
// download from URL ... using attr ... from 1 to X
// finish
}

Hopp, máris ott voltam, amit HH-nak írtam, volt egy szöveges csontvázam, ami egy nagyon kezdetleges programdokumentációnak is megfelelt. Csak négy lépés, ami leírja, hogy pontosan mit is akarok csinálni és mit akarok elérni.

A következő lépésben mindenféle OOP-s “frinc-franc” nélkül lekódoltam a feladatot, “bután”, kopi-pésztelve dolgokat, majd statikus metódusokba kiemelni. Ez egy nagyon ronda spagetti kód lett, amiben nem volt hibakezelés, nem használt paramétereket, vagy bármilyen beviteli felületet, de már működött.

Nagyon gyorsan, kevesebb mint fél óra alatt elértem azt, hogy büszke legyek magamra 🙂 Volt egy ötletem, volt egy eszköz a kezemben, és volt egy működő verzióm. /Kérlek, most ne mondjátok, hogy ezt simán meg lehetett volna Bash scriptben oldalni, ezzel tisztában vagyok, de nekem ez volt az egyszerűbb, másnak meg a Bash script az./

Ha csak az input bevitelt/paraméterezést oldom meg, akkor saját használatra már ezzel vége is lehetne a történetnek. Ismerem a kódot, ha hiba van, akkor elszállt az internet, betelt a háttértár vagy hasonló gond van, megoldom manuálisan. Van egy (minimális) dokumentációm is, ennyi tényleg elég.

De mi van akkor, ha bővíteni akarom a programot? GUI felület, multithread környezet, batch feldolgozás… Szépen ki lehetne dolgozni, ha nagyon akarnám, de nem abban az állapotban, ahogy most van.

Miután kiörömködtem magam önnön kivállóságomon, újra elővettem a kódot. Kapott proxy kezelést, CLI input felületet, paraméter kezelést. Létrehoztam egy thread-elhető osztályt és a hozzá tartozó inicializáló és futtató metódusokat. A háttérben futtatás miatt protokol file-t kezdtem írni. Kibővítettem a dokumentációt, és teletűzdeltem olyan TODO-kkal, amik “nice to have” feature-öket tartalmaznak, de nem létük nem számít major update-nek (pl. nem kap a CLI helyett, mellett egy GUI felületet [is]).

Az egész alig két óra volt a kód első betűjétől az utolsóig. Láttam egy számomra nem tökéletesen működő programot, amiről már az első használatnál látszott, hogy ilyet (jobbat) én is gyorsan össze tudok dobni. Úgyhogy csak “leültem és kódoltam”.

Van, amikor tervezés nélkül belevágni két-három-négyszeres munkát jelent, de ha túlzásba viszi az ember, akkor a nagy tervezgetésben elmegy a kedv a megvalósítástól.

Te hogy szoktál kis kódszösszeneteket, scripteket írni?

2 Comments

Comments are closed.