Informatika bevezető

Az informatika egy iszonyatosan nagy és drasztikus, emberi aggyal szinte már felfoghatatlan mértékben változó szakterület, amiről egyszerre triviálisan egyszerű és lehetetlen leírást készíteni. Szubjektív tartalom következik!

Hardver

Fő kategóriák

A hardver az olyan, hogy a gyártók elkezdenek gyártani valamit, az újabb modellekben kisebb-nagyobb változtatásokat hajtanak végre, és ha elég nagy a változás mértéke és/vagy jó a marketing, akkor új kategória jelenik meg. Nehéz lépést tartani a változással, nagyon sok megnevezés van, és nagyon szűk a mezsgye bizonyos típusok között. Én az alábbi fő kategóriákat különböztetem meg.

Nagy számítógépek

Itt most tényleg a méretre gondolok: amely nem fér el "csak úgy", külön épületrészben helyezkedik el. Kezdetben az összes számítógép ilyen volt, ma pedig (többek között) a nagy forgalmú weboldalak kiszolgálói tartoznak ide. Valójában a nagy számítógép számomra ott kezdődik, ahol akkora kapacitásra van szükség (akár processzor teljesítményben, akár memóriában, akár tárhelyben), melyet nem tud egyetlen otthoni gép kiszolgálni.

Személyi számítógépek

A klasszikus személyi számítógép (Personal Computer, PC) ismérvei a következők: van egy doboz, amiben benne vannak a hardverelemek, külön monitor, billentyűzet, egér, és nemigazán mozgatható. Feltételezem, hogy ennél tudományosabb definíciót is lehetne adni, de számomra ez megfelel. Ebbe a kategóriába sorolom a hőskor személyi számítógépeit is: a Commodore-t, a ZX Spectrum-ot stb.

Persze mindent, amiben processzor van, és nem nagy számítógép, evezhetünk személyi számítógének, viszont más elterjed fogalom háján én most kizárólag a fent vázoltakat hívom annak, és pl. a laptopokat nem.

Laptopok

Számomra a laptop az, amelyben integráltan benne van minden lényeges hardverelem, a processzor, memória és tárhelyen túl a képernyő, a billentyűzet és a tapipad is. Számomra ide tartozik az is, amit mások notebook-nak, netbook-nak, vagy akármi másnak is hívnak. Lényeges különbség a PC és a laptop között a mobilitás: a laptop akkumlátorról is működik, kicsi könnyű, integrált; a PC nem az.

Tabletek

A tabletnek nincs külön billentyűzete, és általában jóval kisebb a kapacitása mint egy laptopnak. Viszont még a laptopnál is mobilisabb, méretre is kisebb, és gyakran tartalmaz olyan érzékelőket, amelyek a laptopokból általában hiányoznak (pl. elfordulás érzékelő vagy GPS). Fontos ismérve viszont az, hogy nem lehet vele telefonálni.

Okostelefonok

Az okostelefon fő ismérve az, hogy lehet vele telefonálni. Hasonló tulajdonságokkal bír mint a tablet. Általában méretre jóval kisebb annál. Ide sorolom a phableteket is, melyek lényegében nagyobb kijelzős okostelefonok.

Fő komponensek

Az alábbiak valamilyen formában mindegyik számítógépben meg vannak.

Processzor

A processzor az, ami végrehajtja az utasításokat. Annyira lényegi része a számítógépnek, mint az agy az embernek, vagy a motor az autónak. Ma szemmel nézve meglepően hasonlóak a processzorok és meglepően keveset tudnak: bitek mozgatása jobbra-balra, másolása a memória és a regiszterek között, kiírás portra, beolvasás portról, no meg persze a feltételkezelés. Pl. ha túlcsordult a legutóbbi összeadás, akkor ugorj valahova.

Persze mindez nagyon leegyszerűsítve, igazból processzorból is sokféle van. A fent vázolt utasításkészlet a szegényebb. Szokásos rövidítése a RISC, melyben az R a reduced szóra utal. Ennek továbbgondolása az ARM; ma már leginkább ilyennel lehet találkozni. Egyébként nem tudom, szándékos szójáték-e, ugyanis az arm németül szegényt jelent.

A normál PC-kben található processzoroknak gazdagabb az utasításkészlete; persze itt se kell olyasmire gondolni, hogy egy utasítással szereplőket lehet a képernyőn mozgatni, hanem több a regiszterek száma, kicsit bonyolultabb matematikai műveleteket is végre lehet hajtani (tehát nemcsak bitek jobbra-balra tologatását, hanem mondjuk lebegőpontos aritmetikát is), de közvetlenül még ezt is igen nehézkes programozni.

A processzorok két leggyakrabban emlegetett tulajdonsága a sebessége és a magok száma. A sebesség azt jelenti, hogy hány műveletet tud végrehajtani másodpercenként. Pl. egy 2,5 GHz-es processzor nagyjából 2,5 milliárd műveletegységet tud végrehajtani másodpercenként. Persze figyelembe kell venni azt, hogy melyik műveletnek mennyi egységre an szüksége, tehát nem mindegyik 1 egységnyi. Sőt, ez igazából sok mindentől függhet, nem is lehet teljesen precízen kiszámolni. A magok száma pedig azt jelenti, hogy hány processzor fut párhuzamosan. Még nem is olyan régen szinte kizárólag egymagos processzorok voltak csak elérhetőek, manapság viszont már a legegyszerűbb telefonban is természetes a több processzormag. Egy 2,5 GHz-es 4 magos processzort úgy kell elképzelni, hogy egymással párhuzamosan hajtanak végre ennyi műveletet, tehát elméletben másodpercenként összesen 10 milliárd egység végrehajtására képesek.

Memória

Tárterület

Alaplap

Beviteli eszközök

Kimeneti eszközök

Operációs rendszerek

A Microsoft világ

Már-már szinte közmondás, hogy a Windows egy nagy rakás sz*r, és ez igaz is, de nem mehetünk el amellett a tény mellett, hogy még mindig ez a legjobb. Legalábbis a személyi számítógépeken, laptopokon ez a legelterjedtebb, ehhez igazodik a világ, másoknak ehhez képest kellene jobbat alkotniuk (és majd látni fogjuk, hogy ez nemigazán sikerül nekik). Úgy látom, hogy a személyi számítógépeken nincs az az alternatíva, amely megszorongatná a Windows egyeduralmát, egyéb területeken viszont (kisebb részt a nagyvállalati szerverek területén, nagyobb részt a hordozható eszközök piacán) már nemigazán rúg labdába a Microsoft.

A Windows teljesítménye hullámzó. Voltak kifejezetten jó verziók is, kezdve a DOS 6.2 + Windows 3.1 kombóval, majd a Windows 98, a Windows 2000, a Windows XP és a Windows 7 kifejezetten kiforrott és végső soron használható operációs rendszerek voltak. De voltak egyenese katasztrófa verziók is: a Windows 95, a Windows ME, a Windows Vista és a Windows 8 felejtős. A kettő közé helyezném az egykori Windows NT-t, valamint a Windows 10-et is.

Óriási problémának látom még azt, hogy egy frissítést követően azon kell folyamatosan aggódni, hogy vajon mi nem fog működni.

Unix

A Linux nehézkes, és akármennyire is próbálnak egyesek mást állítani, a nyilvánvaló lemaradását nem sikerült lefaragnia a Windows-zal szemben. Persze gyorsan tegyük hozzá, hogy az összehasonlítás igazságtalan, mert a Windows fizetős, a Linux meg ingyenes, szóval ezt ne feledjük el, de azért lássuk az előnyöket és hátrányokat! Szubjektív vélemények!

  • A nagyon "Linuxos agyú" emberek hozzáállása szerintem nem elfogadható, márpedig rajtuk áll vagy bukik az egész. Sokan elvárják, hogy mindenki saját maga fordítson kernelt és a programokat is, csakhogy egyrészt ez irreális, másrészt meg szinte sohasem úgy működik, ahogy a nagykönyvben le van írva. Ezek az emberek burkolt vagy nyílt lehülyézés nélkül nemigazán segítenek, szeretik hirdeti önnön felsőbbrendűségüket, és azért ritkán annyira okosok, mint amennyire magukat gondolják. Ők azok, akiknek a tipikus szófordulata az, hogy "most éppen nem működik, de …". Hát most éppen működjön!
  • Persze nem mindenki ilyen ebben a világban sem. Ott van pl. az Ubuntu, amely tényleg viszonylag könnyen telepíthető, elég sok mindent tud, az alapértelmezett telepítés gyors és használható. Üde színfolt a Linux világban, szerintem ennek köszönhető az, hogy nem tűnik el reménytelenül a süllyesztőben.
  • A lemaradás a Windows mögött egyértelműen kitapintható. Még a '90-es években szinte természetes volt, hogy pl. zenét nem tudtam lejátszani Linux alatt, mert hogy, hogy nem, pont az én hangkártyámat nem támogatta, de Windows alatt működött rendesen. Csomó kiselőadást hallgattam, hogy mennyire jól optimalizál a Linux, bezzeg a Windows meg nem, de valahogy nem sikerült elindítanom 16 MB RAM-mal egy olyan tudású szövegszerkesztőt, mint a 4 GB RAM-mal, Windows 3.1-en futó Word 2.0. Nem működtek rendesen az ékezetes karakterek. A kijelző alapból 640x480 volt, és nem volt triviális az átállítása, ha egyáltalán lehetséges volt. Később is egyértelmű volt a lemaradás: az első szkenneremet, első nyomtatómat, első digitális fényképezőgépemet, első GPS készülékemet stb. "természetesen" nem tudtam használni. Sok, általam használt alapszoftver nem volt elérhető. Ma már persze természetes, hogy az olyan alapdolgok, mint mondjuk a hang, működik, de szinte biztos tudok venni olyan hardvert, ami csak Windows-zal működik rendesen, Linux-on nem.

Az egyszerű, nem informatikus felhasználónak nem tudom jó szívvel ajánlati a Linuxot. Én magam is virtuális környezetben használom, és elég gyorsan eljön az a pont, amikor azt mondom, hogy jól van, ennyi szívás elég volt, térjünk vissza a Windows-ra.

Egyéb területen viszont a Linux nyerésre áll: az üzemeltetés legtöbb esetben Linux operációs rendszereken zajlik (és pl. a Microsoft is az Azure felhőben Windows mellett Linuxos szervereket is üzemeltet), valamint az Android is Linux alapú. Mivel a fejlődés egyre inkább a hordozható eszközök irányába tolódik, ott nyerő pozícióban van, és ezen a területen fogja legyőzni mégis hosszú távon a Linux a Windows-t.

Az Apple világ

Az Apple termékek túlárazottak, ami azt jelenti, hogy nem engedhetem meg magamnak, hogy ilyen termékeket vásároljak. Ez persze azt is jelenti, hogy érdemben nem tudok erről nyilatkozni, nincs élményem testközelből. Persze valószínűleg nem véletlen, hogy ennek is jelentős a piaca, és ahogy látom, az Apple termékek (Mac, iPhone, iPad, iPod) tulajdonosai sohasem panaszkodnak a minőségre. Ha valaki elkészítené az előnyök/hátrányok összefoglalását ennek a világnak, azt szívesen venném!

Minden egyéb

Szerintem ezek szóra sem érdemesek, mivel eléggé esélytelen, hogy komoly külső támogatást kapjanak. A Windows ereje nem abban rejlik, hogy olyan ügyesek lennének a Microsoft programozók, hanem onnan, hogy ha valamelyik cég elkészít egy szoftverterméket, akkor az első célközönség, akikre gondol, az a Windows felhasználók köre. Hasonlóan, a mobilalkalmazások esetén is az Android felhasználók az elsődleges célközönség. Nincs az a nagyon nagy nyomás a szoftverfejlesztő cégeken, hogy piacra dobják mondjuk az OS/2 vagy BlackBerry verziójukat is, és ott is megfelelő támogatást nyújtsanak, mert egyszerűen nem éri meg nekik. Ha nem túl elterjedt rendszert használunk, elég gyorsan belebotlunk olyan hibába, amivel nem tudunk mit kezdeni. Ha mondjuk a legelterjedtebb operációs rendszeren a legnépszerűbb böngészőt használva megnyitjuk a kedvenc oldalunkat (ami jó eséllyel másnak is kedvence), akkor szinte biztos, hogy jól fog működni. Egy nem túl elterjedt kombinációval ez már egyáltalán nem garantált.

A '90-es években volt egy jópofa magyar játék, a részletekre már nem emlékszem, ami szépen működött Windows alatt Internet Explorerrel, de Linux alól Netscape Navigator-ral nem ment. Magyarázat persze volt, hogy nem a Netscape és a Linux a hibás, de a felhasználó nem magyarázkodást akar hallani, hanem a rendszert használni. Márpedig egy nem elterjedt rendszer esetén szinte törvényszerű, hogy a felhasználó a problémája megoldása helyett "magyarázatot" kap.

Ha egy rendszer tényleg annyira jó, hogy megérdemli azt, hogy létezzen, nőjön nagyra, egyelőre szívjon vele más, én majd csak akkor jövök, ha bizonyított.

Szoftverek

Operációs rendszer közeli szoftverek

Böngészők

Irodai alkalmazások

Fejlesztőeszközök

Médialejátszók

Játékok

Szakmák

Szokás informatikusnak hívni azt, aki az informatikában dolgozik, ami kb. annyiban igaz, mint mondjuk az egészségügyi dolgozó, ami magába foglalja az összes szakorvost, háziorvost, mentőst, gyerekorvost, szakképesítés nélküli rezidenst, állatorvost, gyógyszerészt, ápolót stb. Valójában olyan szakma, hogy informatikus, nincs, hanem ez egy gyűjtőfogalom, melybe legalább olyan sokféle foglalkozás beletartozik, mint mondjuk abba a gyűjtőfogalomba, hogy egészségügyi dolgozó.

Szoftverfejlesztő

A szoftverfejlesztő az én értelmezésem szerint az a szakterület, ami az orvos az egészségügyben, és legalább annyira szerteágazó ez is. A szoftverfejlesztő szerepe központi, mivel fizikailag ő készíti el a szoftvert, itt készül el a semmiből a valami. Minden más körszerep kiegészítőnek tekinthető: előkészületek a fejlesztés megkezdéséhez, a fejlesztés folyamatának nyomon követése, az eredmény minőségének ellenőrzése, a termék üzemeltetése. Ezzel természetesen nem a többi szerepkör jelentőségét szeretném csökkenteni, természetesen azok is fontosak ahhoz, hogy a szoftver ne csak elkészüljön, hanem az megfelelő minőségben, megfelelő határidőre, adott költségvetési kereten belül stb. történjen.

A szoftverfejlesztő tehát az, aki programoz. Hívhatnánk programozóak is, véleményem szerint viszont a szoftverfejlesztő általánosabb mint a programozó. Egy szoftverfejlesztőnek a leglényegesebb része a programozó, aki konkrétan elkészíti a kódot, de a szoftverfejlesztő igazából több annál: az ideje nagy része valójában nem is a kódolással megy el, hanem az egyéb, kiegészítő tevékenységekkel: megbeszélésekkel, hibakereséssel, a kód megértésével, tanulással, adminisztrálással stb.

A szoftverfejlesztői szerepkör rendkívül szerteágazó, és egymástól igen távol álló területeket ölel fel. Több nagy területet ölel fel. A területek közötti átjárás minimális; több évre van szükség ahhoz, hogy valaki egyik területről átkerüljön a másikra, pl. webes frontend fejlesztőből Java backend fejlesztő legyen. Még területeken belüli mozgás esetén is éves nagyságrendről beszélünk: ennyi időre van szükség ahhoz, hogy valaki egy adott technológiákat használó Java backend projektről átkerüljön egy más technológiákat használó Java backend projektre, és ott ugyanolyan produktív legyen. Sőt, még a projekten belüli mozgás sem megy egyik napról a másikra; több hét, akár több hónap kell, mire valaki belerázódik a nyilván ugyanolyan technológiák használó más alrendszerbe. Szoftverfejlesztők estén tehát nem igaz az az elképzelés, hogy az ember megtanulja a tudnivalót, és utána akárhol egyből megállja a helyét.

A szoftverfejlesztőket sokféle szempont szerint lehet csoportosítani, és az egyes kategóriák igen távol állhatnak egymástól:

  • Attól függően, hogy mennyire van közel a forráskódhoz, számomra a két véglet a kódoló ill. az architekt.
    • Az architektet még a szoftverfejlesztő kategóriába sorolom (bár meggyőzhető vagyok arról, hogy más kategóriába kerüljön). Egyébként nincs egyértelmű definíciója az architekt szerepkörnek. Számomra az architekt az, aki magas szinten átlátja a rendszert, sok technológiát ismer, ismeri azoknak előnyeit és hátrányait (tudja azt, hogy mi miatt született döntés adott technológia mellett), és figyelmembe véve a funkcionális és nemfunkcionális követelményeket is, határozza meg a fejlesztés fő irányvonalait. Pl. ő dönti el azt, hogy milyen programozási nyelvben készüljön a program, annak milyen verziójával, milyen környezetben fusson a rendszer (beleértve az alkalmazásszervert is), milyen fő komponensei legyenek, milyen adatbázist használjanak stb. Az architekt az a legmagasabb szint, aki még részleteiben it átlátja a kódot. (Az afeletti menedzseri szinten ez már általában nem igaz.)
    • A vezető fejlesztő az architekt útmutatásai alapján elkészíti a rendszer fő komponenseit, a program fő keretének alaplogikáját. A vezető fejlesztő tehát operatívan részt vesz a fejlesztés folyamatában.
    • A kódoló részleteiben kidolgoz egy részkomponenst.
  • Attól függően, hogy mennyire látható közvetlenül az eredmény, beszélhetünk backend és frontend fejlesztőről.
    • A backend fejlesztő a háttér folyamatokat fejleszti, így ennek az eredménye közvetlenül nem látható. Itt található az üzleti logika. A backend fejlesztőnek a programozási nyelv alapos ismeretén túl a következő kompetenciákkal kell rendelkeznie: adatbázis kezelés, kapcsolat más rendszerekkel (pl. üzenetek dekódolása), üzenetek kezelése stb. Fontos az, hogy képes legyen olyan kódot írni, amely optimálisan gazdálkodik az erőforrásokkal. Az üzleti logikát nem kell feltétlenül részleteiben értenie.
    • A frontend fejlesztő a rendszernek azt a részét fejleszti, ami látszik. Tehát az is fontos, hogy hogyan néz ki az eredmény, nemcsak az, hogy mit csinál. A frontend fejlesztő ismeri a grafikus felületi elemeket, az esemény alapú vezérlést, és általában ismer több olyan keretrendszert, aminek segítségével igazán dinamikus, professzionális hatású felületeket tud készíteni.
  • A programozási nyelv szerint szinte annyiféle fő kategóriát különböztethetünk meg, ahány programozási nyelv van. Persze helytelen lenne az egy programozási nyelv - egy kategória felosztás, mert egyrészt vannak közeli programozási nyelvek (pl. egy C++ fejlesztő számára nem jelent gondot a C nyelv megértése, ahogyan egy Scala fejlesztőnek a Java-é), másrészt adott programozási nyelven belül is létezhetnek egymástól alapjaiban eltérő területek (pl. standard és enterprise Java). A tapasztalatom szerint a legnagyobb területek az alábbiak:
    • Java világ, beleértve a standard és az Enterprise Java-t, is, valamint azokat a rendszereket, amelyek a Java-ból "nőtték ki" magukat, pl. a Scala.
    • C/C++ világ, beleértve a beágyazott rendszerek fejlesztését is.
    • C#/.NET világ, ami a Microsoft válasza a nagyvállalati környezet kihívásaira.
    • Webes frontend világ, beleértve a HTML-t, CSS-t, a JavaScript-et különféle keretrendszerekkel, a PhP-t (bár ez inkább backend) stb.
    • Az interpretált script nyelvek világa: Perl, Python, Ruby stb., de akár a natív shell kódot is ide lehet sorolni.
    • És a listát még nagyon hosszan lehetne sorolni.
  • A szakterület (domain) is számít, és adott esetben hosszú ideig tarthat, mire egy adott területen jártas fejlesztő belerázódik a másik területbe. Néhány példa: telekommunikáció, közlekedés, játékok, tudományos alkalmazások (pl. statisztika), irodai alkalmazások, közösségi média, fordítóprogramok, és a sort itt is lehetne nagyon hosszan folytatni.
  • Az is számít, hogy a szoftver milyen rendszerre készül. Itt is igaz az, hogy egy adott rendszerben jártas fejlesztőnek sok idejébe telik, mire egy másikban is produktív lehet. Néhány példa: asztali szoftver Windows-on, Linux-on, Mac-en, vagy más operációs rendszeren; szerveren futó alkalmazás; mobil alkalmazás (azon belül is különböző rendszereken: Android, Windows Mobile, iPhone stb.); beágyazott alkalmazás (tehát egy célhardveren futó alkalmazás), és sok más, kisebb jelentőségű egyéb.
  • Egy fejlesztő lehet egy adott terület specialistája. Néhány példa:
    • Adatbázis specialista: amíg egy átlagos fejlesztő tetszőleges adatbázis rendszeren létre tud hozni egy adattáblát különböző oszlopokkal, addig egy adatbázis specialista az adott adatbázis adott verziójának a legmélyebb bugyrait is ismeri. Csak az adott rendszerre jellemző paramétereket is be tud állítani. Célszerű, hogy ha egy adott projekt egy adatbázis mellett dönt, akkor legyen olyan specialista, aki optimálisra be tudja állítani a rendszert. Egy példával illusztrálom: egy backend fejlesztőtől elvárható, hogy létre tudjuk hozni egy SQL táblát, adatokat tudjon beszúrni, vagy lekérdezéseket tudjon készíteni, viszont az már az adatbázis specialista feladata, hogy tudja, hogy mondjuk a Microsoft Data Warehouse-ban az azonosítókat erőforrás osztályokba (resource class) sorolják; az alapértelmezett a smallrc, mely legfeljebb a memória 3%-át kaphatja meg, ellenben 32 párhuzamos szálat futtathatnak egyszerre, mígy mondjuk a largerc a memória 22%-át is megkaphatják, de legfeljebb 4 párhuzamos szállal, és hogy a EXEC sp_addrolemember 'largerc', 'username'; paranccsal lehet ezt beállítani.
    • Adattudós (data scientist): aki jól ismeri azokat a módszereket, statisztikai függvényeket, diagram típusokat, melyek segítségével értékes adatot tud kibányászni az adatokból.
    • Big data szakértő: akinek van tudása és tapasztalata nagy mennyiségű adatok feldolgozásában. A big data szakértő feladata tehát az, hogy az adat maga rendelkezésre álljon, az adattudósé pedig annak feldolgozása.
    • Szoftverbiztonsági szakértő: aki átvizsgálja a rendszert olyan szemmel, hogy vannak-e neki nyilvánvaló biztonsági rései.

Az én véleményem szerint egy "egységsugarú" Java backend fejlesztő a következőképpen néz ki (és ilyen listát tetszőleges pozícióról létre lehet hozni):

  • Ismeri a Java programozási nyelvet, beleértve a rendszer alapkönyvtárait is, és több év fejlesztési tapasztalata van benne.
  • Ismer jó néhány külső könyvtárat. Ez két dolgot jelent, és egyet nem:
    • Ismeri a leggyakoribb könyvtárakat, úgy mint Log4J, JUnit (legalább egy mock rendszerrel), használt már szerializáló könyvtárat (pl. JSON, XML vagy más) stb.
    • Ismer néhány speciális könyvtárat, ami arra a projektre volt jellemző, amelyen dolgozott.
    • Nem ismeri az összes könyvtárat, sőt, azok 99,99%-áról még csak nem is hallott. Ez teljesen természetes! Ha rákerül egy újabb projektre, akkor az ott használt könyvtárak egy részét meg kell tanulnia, és ezzel az adott projekt vezetőjének is számolnia kell.
  • Találkozott már adatbázissal: ismeri az SQL-t, és ismer legalább egy konkrét adatbázis rendszert. (Az előfordulhat, hogy pont azt nem ismeri, amit egy esetleges új projekten használnak. Azzal, hogy használt már hasonlót, viszonylag gyorsan belerázódik bármelyikbe.)
  • Használt valamilyen alkalmazás szervert (a szó tágabb értelmében, tehát ide sorolva a webszervereket, vagy az olyan keretrendszereket is, mint pl. a Spring). Ha van olyan specifikus tudás, amihez érdemes ragaszkodni, akkor az ez lehet.
  • Találkozott sokféle fejlesztőeszközzel: használt valamilyen integrált fejlesztőeszközt, a kódot valamilyen verziókövetőben mentette, a korábbi projektjein volt valamilyen feladatkezelő, a dokumentumokat valahol tárolták, valamilyen módszertan szerint fejlesztettek (melyen voltak pl. kisebb-nagyobb megbeszélések) stb. Ideális esetben ezek pot ugyanazok az eszközök, amelyeket az esetleges új projektjén használnak, a valóságban viszont lehet kisebb-nagyobb eltérés, és ez esetben idő (adott esetben ez akár több nap is lehet, és betanítás lehet szükséges), míg megtanulja és belerázódik.
  • Van neki egy általános jártassága Windows-ban és Linux-ban is. Ismeri a szoftverfejlesztők körében legnépszerűbb alkalmazásokat, és a leggyakoribb nem szoftverfejlesztési feladatokat meg tudja oldani.
  • Legalább középszinten (B2) beszél angolul.

Tehát ha egy ilyen fejlesztő rákerül egy másik projektre, akkor:

  • Elvárható, hogy a fenti, gyakoribb általános tudást jól ismerje.
  • Az jó, ha a ritkább általános tudása és az új projekt esetén az ottani ritkább általános tudás egy része egybeesik, de arra nem számíthat az új projekt vezetője, hogy megtalálja azt az embert, ami minden általános tudás birtokában van. Magyarán fel kell készülni arra, hogy olyan tudást is el kell sajátítania, ami egyébként a projekttől független.
  • A projektspecifikus tudás egyáltalán nem elvárható, azt meg kell tanítani.
  • Valamint természetesen biztosítani kell számra a hozzáférést. Mert pl. hiába profi valaki a git verziókövető rendszerben, ha nem kap hozzáférést az új projektjén.

Ez azt jelenti, hogy még legjobb jelölt esetén is számolni kell egy komolyabb betanulási időszakra, ami egyben azt is jelenti, hogy egy új embernek a projektre kerülése ideiglenesen visszaveti a csapat teljesítményét, mivel az, aki betanítja, ideiglenesen kiesik a munkából. Ezt viszont szigorúan, felülről vezérelve kell végrehajtani.

Tesztelő

Üzemeltető

rendszergazda, DEVOPS

Kapcsolódó tevékenységek

Olyan területeket sorolok itt fel, amelyeket még túl kicsinek tartok ahhoz, hogy külön kategóriába soroljam, de nem lehet egyértelműen "beletuszkolni" egyik többi kategóriába sem.

  • Web designer: aki megalkotja a weboldal kinézetét. Elképzelhető, hogy egy szépérzékkel megáldott frontend fejlesztő végzi ezt a feladatot, viszont olyan is van, hogy a web designer egyáltalán nem ért a szoftverfejlesztéshez. Emiatt tartottam indokoltnak ebbe a külön kategóriába sorolni.
  • UX designer: ez az User eXperience designer rövidítése. Feladata az, hogy a felületet a felhasználói élményt figyelembe véve alakítsa ki. Tekinthetünk rá olyan frontend fejlesztőként, aki ebbe az irányba szakosodott, de mivel ebben a pozícióban nem feltétlenül kell érteni a kódoláshoz (bár az kifejezetten hasznos), emiatt nem feltétlenül tekinthetünk rá fejlesztőként.
  • Műszaki szakszövegíró (technical writer): ő készíti el a műszaki dokumentációkat, tipikusan a szoftver használói számára, ilyen pl. az online help. Ezt a szerepet betöltheti akár egy olyan tesztelő is, aki nagyon jól ért az adott területhez, elsődleges pozíciójánál fogva jól ismeri a lefejlesztett szoftvert, és kiváló nyelvi készségekkel rendelkezik (ez utóbbi ebben a pozícióban természetesen alapkövetelmény), de akár olyan is, aki teljesen független a csapat többi részétől, így ezt a szerepkört sem lehet egyértelműen hozzácsapni más területhez.
  • Biztonságtechnikai szakértő, pl. etikus hacker. Gyakran előfordul, hogy mondjuk egy szoftverfejlesztő, egy üzemeltető, vagy akár más pozíciójú informatikus elmélyed a szoftverbiztonság területén, és belőle lesz a biztonságtechnikai szakértő, viszont önálló szakmaként és elképzelhető, emiatt ez sem egyértelműen része másnak.

Menedzser

Ide sorolok mindenkit, aki a folyamatokért felel. Lehet, hogy sokak szemében szentségtörés lesz, amit ide írok, de nem érzek túl nagy különbséget az alábbi szerepek között, és egy kisebb projektben akár egyetlen ember is elláthatja az alábbiakat:

  • Folyamat menedzser, pl. Scrum master: az, aki azt vezéreli, hogy mikor ki mit csinál. Ő az, aki megkérdezi, hogy ki hogy halad a feladatával, és intézkedik, ha valami blokkolja az előrehaladást.
  • Release menedzser: aki azért felelős, hogy elkészüljenek a verziók. Itt nem elsősorban arra gondolok, aki fizikailag legyártja a jar fájlokat, és leadminisztrálja a verziókövetőben, hanem aki egyensúlyoz az ügyfél igények és a fejlesztőcsapat teljesítménye között.
  • Quality manager: aki a szoftver minőségéért felelős. Tehát ha pl. szükség van code review-ra, akkor ő maga nem feltétlenül vesz részt ebben, viszont figyeli, hogy megtörtént-e, és figyelmeztet, ha nem.
  • Product owner: aki felülről látja az egészet. Ő tartja a kapcsolatot az ügyfelekkel, a többi csapat vezetőjével és magával a csapattal is, és ő látja azt, ha pl. növelni kell a csapat méretét, vagy valamilyen kompetenciát kell a meglévő csapattagoknak megtanulnia.

Itt módszertantól függően egészen sok egyéb szerep lehetséges, pl. controller, auditor, műszaki menedzser, csoportvezető stb.

Tanár

Kutató

Hardveres

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License