2019. március 3., vasárnap

Van-e gyakorlati tudás elméleti háttérismeret nélkül?

Olvastam nemrég egy prog.hu fórumtopik-ot, az alábbit:

https://prog.hu/tarsalgo/205333/netbeans-ide-hasznalata-kozepiskolaban

Erről eszembe jutott néhány gondolat, amikről egyébként írtak is egyesek a topik-ban, de az én gondolataimat is megmozgatta annyira, hogy bejegyzés szülessen belőle :)

Szóval, az én gyakorlati tapasztalataim alapján (kb. 25 év szoftverfejlesztés, azon belül már jó 15 éve architektúra-tervezéssel is kiegészítve):

  • Teljesen, 100%-osan egyetértek azokkal, akik az alapelvek oktatását hiányolják. Teljesen mindegy, hogy "végül" milyen fejlesztőkörnyezet lesz használva Java vagy C++ programozás tanítására, mert a programozás tanítása - még középiskolás, sőt általános iskolás szinten is - a következőképp kellene, hogy kezdődjön:
    • Általános algoritmikus és programozási alapelvek tanítása, úgy, mint mi az, hogy egész szám, lebegőpontos szám, karakter, szöveg, dátum, logikai érték, mit jelent az utasítás, az értékadás, a vezérlés (feltételes elágazás, ciklus), mi az a változó
    • A fentieket tanítva akár több különböző programozási nyelvből is lehet olyan egyszerű példákat mutatni, amelyeket látva megértheti a diák, hogy valóban nem a szintaxis megtanulása a célratörő, hanem a mögötte rejlő alapelvek
    • Erre jöhet rá később néhány magasabb szintű alapelv (pl. legalább a tömb/lista/halmaz/map adatstruktúrák ismerete, funkcionális programozási alapok, objektum-orientált programozási alapok, aspektus-orientált programozási alapok stb.) bemutatása, szintén, az alapok akár több különböző nyelvből is példákkal illusztrálva - ahol pl. már arra is rá lehet mutatni, hogy milyen nyelven, környezetben milyen típusú megoldás van "natívan támogatva", és mi az, ami nincs, illetve akár arról is lehet kicsit elmélkedni, hogyan lehet valamit megvalósítani, ha az adott környezetben nincs natív támogatása
  • A mai, 21. századi informatikában nagyon sok terület, lehetőség van, de ami szinte mindenhol előjön, mint haladó téma, és mindenképpen megéri foglalkozni vele, elméleti és gyakorlati szinten is:
    • Párhuzamos, több szálú program végrehajtáshoz kapcsolódó fogalmak és azok működése a kiválasztott környezetben
    • Változók, objektumok életciklusa, static typing vs. dynamic typing közötti különbségek, futtatókörnyezetek működési alapjai, "szemétgyűjtés"
    • A kiválasztott programozási nyelv esetén a nyelv, a környezet (fordító, linker, virtuális gép stb. hol mi az, ami van) és a nyelvhez tartozó standard library közötti összefüggések, különbségek (hogy egyértelműen értsük, hogy végződik a nyelv és hol kezdődik a library). Ennek része az is, hogy az adott nyelvi környezetben hogyan zajlik az alapvető folyamat, ahol a forráskódból végrehajtható program válik.
  • Számomra csak ezt követően jön el az, hogy fejlesztő környezettel kezdünk ismerkedni, hiszen ekkor meg rá lehet mutatni, hogy az adott fejlesztőkörnyezet pl. hogyan támogatja a projektek létrehozását és kezelését, hogyan segít a forráskódból végrehajtható programmá alakulás folyamatában stb. És - a fejlesztő környezettel együtt - fontos néhány további dolgot is tárgyalni, úgy, mint:
    • programozott tesztelés: teljesen mindegy, fejlesztők vagy tesztelők leszünk, vagy mindkettő egyszerre :), fontos, hogy értsük és tudjuk, mint jelent a unit tesztelés, az integrációs tesztelés, a kézi és az automatikus tesztelési folyamatok, és azon alapelvek, amelyek segíthetnek jól tesztelhető kódok ill. komponensek készítésében (pl. IOC)
    • build eszközök: pl. JVM környezetben (ahol én is dolgozom) ma már teljesen alapvetőnek kellene, hogy számítson a Maven és a Gradle alapszintű használata, a 3rd party lib-ek elérhetősége függőségkezelésen keresztül
    • segítő eszközök: a legtöbb környezetben elérhetők olyan eszközök, amelyek segíthetnek a programjainkban a nagyon elemi elírások/hibák észlelésében és felderítésében. Ilyenek pl. a statikus kódelemzők, a tesztfuttatások során "direkt hibákat vétő" megoldások, de ide tartozik a debugger (és azok gondolkodási mód, ami segíthet a hatékony használatában), a naplózási alapelvek és naplózási eszközök és a különböző, a programjainkat futásidőben monitorozó megoldások (profiler-ek)
    • további elvi érdekességek: ide sorolhatók pl. a tervezési minták, a SOLID, DRY, YAGNI stb. ismerete, ezek is sokat segítenek a szemléletformálásban
Ha valaki egy olyan oktatónál tud tanulni, aki figyelembe veszi a fentieket, ott biztos lehet abban, hogy a Netbeans, vagy az Eclipse, vagy bármilyen más környezet dolgait fogja elsősorban megtanulni, hanem azt a gondolkodásmódot, amely segítségével valóban szoftverfejlesztővé válhat.

Egy volt kollégám, aki az én első munkás éveimben az egyik fontos mentorom is volt, írt egyszer nagyon velősen arról, amiről Peter Norvig kicsit bővebben, hogy miért nem jelenti ugyanazt egy programozási nyelv megtanulása, mint a programozás megtanulása, és, hogy miért is kell hosszú idő ahhoz, hogy valakiből valóban jó szoftverfejlesztő váljon.

Persze, a mai eszközök és megoldások (akár a Scratch, akár egyéb, "vizuálisan összekattogtatós megoldások") egyre jobban terjednek és azt a feeling-et adják, hogy "ez nem is olyan bonyolult". És, igazuk is van :) Viszont a fejlesztés sosem azért volt bonyolult, mert nehéz a szintaxis. A fejlesztés mindig is azért volt bonyolult, mert:
  • Tudni kell megfelelően kialakítani azt az absztrakciót, amely lefedi az aktuális igényeket, és teret hagy a továbbfejlesztésekhez abban az esetben, ha nem változik meg teljesen az alap működési elv
    • Ehhez meg kell tanulni szöveget értelmezni, abból absztrakt modelleket felépíteni, azzal összemérni az elvárt igényeket és pl. észrevenni, ha ellentmondásosak az elvárások, ...
  • Tudni kell kiválasztani a megfelelő eszköztárat, amely segítségével az adott igény megvalósítása megfelelő színvonalon, ugyanakkor lehetőségek szerint az elvárt határidőn és költségkereten belül megtehető
Persze, nagyon sokféle terület van jelenleg is, amire azt mondjuk, hogy fejlesztői feladat. Nyilván, ha a fő profil, hogy van egy vagy két féle "termék", amelyeket minimális testreszabással szállítunk, és ezen - viszonylag egy kaptafára történő - testreszabásokat fejlesztők végzik, erre a feladatra nem feltétlenül kell olyan fejlesztőt felvenni, aki "nulláról" is képes fejleszteni, és képes új megoldásokat adni felmerülő problémákra.

Ha viszont valaki túl szeretne valaha lépni az "emelt szintű fejlesztői segédmunkás" szerepkörön, az kénytelen a fenti - nyelv- és környezetfüggetlen - alapelvekkel is megismerkedni, mert ezek nélkül viszonylag hamar "meg fog rekedni" egy szinten...

Visszatérve egy gondolat erejéig a Netbeans "betiltására", ami a témaindító topik volt. Kollégáimmal:
  • A 90-es évek végén Java fejlesztésre a Visual J++ eszközt használtuk, mert fényévekkel gyorsabb és kezelhetőbb volt, mint akkoriban bármilyen versenytársa (a 233Mhz-es MMX Pentium processzorral és 128MB memóriával szerelt fejlesztői gépen mindenképp)
  • Utána tettünk kitérő Visual Café, Forte (a Netbeans elődje), Borland JBuilder irányokba is, sőt megnéztük az Emacs-ot is a JDEE-vel; mindegyikkel végeztünk produktív szoftverfejlesztést
  • Végül rátaláltunk az Eclipse-re (ekkor még az Eclipse 2.0 volt aktív fejlesztés alatt :) ), és utána egészen sokáig az Eclipse maradt, illetve később az STS (SpringSource Tool Suite)
  • Végül, 2016-ban váltottunk az Intellij IDEA-ra, és azóta azt használjuk
A lényeg: mivel kollégáim ismerték/ismerik az alapelveket és megvan a szükséges háttértudásuk, gyakorlatilag mindegyik váltásnál gyakorlatilag a 2. napon már teljesen produktívan tudtak dolgozni, aztán persze még jobban megismerték az eszközöket és még hatékonyabbá váltak. Nem azt tanulták meg, hogy "és akkor az eszköztáron a 8. ikont, ami olyan izé... színű és formájú, ha megnyomom, akkor utána tudom majd futtatni a programomat", hanem azt, hogy "hol van a build menüpont" :)

Nincsenek megjegyzések:

Megjegyzés küldése