Fejlesztőeszközök

Ezen az oldalon azok az eszközök vannak felsorolva, melyek segítik a szoftverfejlesztés folyamatát.

Integrált fejlesztő környezet

A kódot elvileg egy egyszerű szövegszerkesztővel, akár Notepad-del is el lehet készíteni. Azonban már a legegyszerűbb estekben is felmerülnek a fejlesztés során olyan igények, amit egy szövegszerkesztő többnyire nem tud. Valamint számos más eszközt is használnunk kell a fejlesztés során: fordítás, futtatás, hibakeresés stb. Felmerül a kérdés, hogy nem lehetne mindezeket a gyakori feladatokat egy rendszeren belül végrehajtani? Az integrált fejlesztőeszközöknek (Integrated Development Environment, IDE) pont ez a feladatuk! Az IDE-k legfontosabb részei az alábbiak:

  • Szövegszerkesztő: itt is ugyanúgy lehet elkészíteni a szöveget mint bármely másik, általános célú szövegszerkesztőben, viszont kifejezetten a programozásra kiegyezett tulajdonságokkal rendelkezik. Pl. kiemeli az adott programozási nyelvben a kulcsszavakat (ezt még tudja mondjuk a Notepad++ is, de a Notepad már nem); jelzi a szintaktikai hibákat; segítséget nyújt a szerkesztésben, pl. egy adott objektum esetén egy lenyíló ablakban megjelennek a meghívható függvények, és elég onnan kiválasztani; lehetővé teszi a gyakori kódelemek legenerálását; automatikus formázásokat hajt végre, és a sor még lehetne folytatni.
  • Fordító, futtató: az IDE folyamatosan fordítja a programot, és már a beíráskor visszajelzést kapunk az esetleges szintaktikai hibákról. Innen el is tudjuk indítani, és ez igaz nemcsak a főprogramra, hanem pl. az egységtesztekre (adott esetben vizuálisan jelezve a kód lefedettséget) vagy az alkalmazásszerverben futó programokra is.
  • Hibakereső: a legtöbb IDE lehetővé teszi azt, hogy hibakereső (debug) módban egyesével lépkedjünk a programsorokon, és közben nézzük a változók és egyebek aktuális értékét. Általában lehet megálló pontokat közbeiktatni, ahol feltételeket adhatunk meg (pl. csak akkor álljon meg, ha egy adott változó értéke ez és ez).
  • Létrehozó: egy projekt elég összetett tud lenni, sok mindent be kell állítani, és ezek legenerálásában segít a legtöbb IDE. Létre tudunk hozni vele új projektet (vagy létezőt betölteni), forrásfájlokat hozzáadni stb.
  • Verziókövető: a fejlesztőeszközök többsége lehetővé teszi a verziókövetővel való integrációt, és akár segíthet pl. a merge során fellépő konfliktusok feloldásában is.

Az alábbiakban pár általános célú fejlesztőeszközt vizsgálunk meg.

Eclipse

Kezdeti lépések

Az Eclipse talán a legnépszerűbb fejlesztő környezet, különösen a Java világban. A https://www.eclipse.org/ oldalról tölthető le. Javasolom, hogy ne az exe telepítőt töltsük le, hanem a zip csomagolt fájlt (https://www.eclipse.org/downloads/packages/ → Eclipse IDE for Enterprise Java Developers, Windows 64 bit), legalábbis nekem szinte mindig problémám volt a telepítőssel. Csomagoljuk ki egy könyvtárba (pl. c:\programs\eclipse\), majd indítsuk el az eclipse.exe-t. Sajnos van neki pár (egyre több…) problémája; az alábbiakat célszerű végrehajtani használatba vétel előtt:

  • Kapcsoljuk ki ezt: "Always show Welcome at start up" (még ez is hibát okoz a működésben!)
  • Windows → Preferences → General → Keys → unbind Skip All Breakpoints (Ctrl + Alt + B) (ha ezt nem tesszük meg, akkor magyar billentyűzettel nem fogunk tudni { karaktert írni.)
  • Windows → Preferences → General → Editors → Text Editors → Insert spaces for tabs (bár ez ízlés kérdése, és projektről projektre eltérhet; alapvetően szóközöket szokás használni tabulátor helyett)
  • Windows → Preferences → Java → Code Style → Formatter → Edit… → Intendation → Tab policy → Spaces only (ugyanez; legyen egységes)
  • Windows → Preferences → Java → Editor → Save Actions → Perform the selected actions on save → Additional Actions → Configure → Remove trailing whitespace, All lines (ne maradjon szóköz a sorok végén)
  • Jobb kattintás a betöltött projekten → Properties → Java Build Path → Libraries → töröljük ki az 1.5-ös könyvtárakat → Add Library… → JRE System Library → Next → Workspace default JRE → Finish (alapértelmezésben még mindig az 1.5-ös Java verzióban fordít, ami különösen az 1.8 óta problémás)

Projektek kezelése

Új projektet a File → New → Other… (Ctrl + N) menüpont kiválasztásával tudunk létrehozni. Itt a leggyakrabban használt változatok a Java → Java Project (ez esetben Eclipse specifikus projekt jön létre) és a Maven → Maven Project (ez esetben Maven projekt jön létre, amit más fejlesztőkörnyezetekből is használhatunk). A leggyakrabban használt lehetőségek közvetlenül elérhetőek a File → New kiválasztásakor.

Létező projektet kétféleképpen tudunk betölteni. Az egyik: File → Open Proects from File System, amely a könyvtár kiválasztásával felderíti a forrásokat. A másik - egyébként gyakrabban használt - megoldás az importálás: File → Import… → itt tipikusan a Maven → Existing Maven Projects lehetőséget szoktuk választani, majd Next után ki kell választani azt a könyvtárat, ahol a pom.xml található, és az Eclipse ennek alapján betölti a szükséges dolgokat. Szükség esetén ez azt is jelenti, hogy letölti az internetről. Ehhez megfelelően beállított internetkapcsolatra van szükség. Szükség esetén a proxy-t a Window → Preferences → General → Network Connections alatt tudjuk beállítani.

Forráskód elemek hozzáadása

Csomagot, forrásfájlt és egyéb elemeket a következőképpen tudunk hozzáadni: a kívánt helyen (pl. src/main/java) jobb kattintás → New → itt válasszuk ki a megfelelőt. (Ha nem látjuk, amit szeretnénk, akkor az Other-ben keressük meg) Példák:

  • Package: csomag létrehozása.
  • Class: osztályt, azaz tulajdonképpen Java forrásfájlt tudunk létrehozni. Itt megadhatjuk, hogy legenerálja nekünk a public static void main belépési függvény vázát.
  • Interface, Enum: értelemszerűen.
  • File: bármilyen fájlt létre tudunk hozni ezzel, pl. szöveges vagy konfigurációs fájlt.

Szerkesztés

Szerkesztés során számos segítséget nyújt a környezet:

  • Lehetővé teszik a szokásos szövegszerkesztési műveleteket: beírás, törlés, kivágás, másolás, beillesztés stb.
  • Különböző színekkel és formákkal jelöli az egyes elemeket. Példák:
    • Kulcsszavak: vastagítva, lilás színnel jelennek meg.
    • Az osztály attribútumai kékek.
    • A felsorolás elemei vastagon, kék dőlt betűkkel látszódnak.
    • A megjegyzések általában világoszöldek. Kivétel az API specifikáció, amely világoskék, és szürke vastag betűkkel vannak jelölve a @ karakterrel kezdődő részek.
    • Az annotációk szürkék.
    • Ha egy függvény deprecated, akkor áthúzva jelenik meg.
    • A stringeket kékkel jelzi.
    • A lokális változókat és paramétereket sötétszürkével jeleníti meg.
    • A statikus függvényeket és változókat dőlttel jelzi.
    • Ami talán a legfontosabb: a szintaktikai hibákat pirossal aláhúzza, és ezt a bal oldali Package Explorerben is jelzi.
    • A figyelmeztetéseket sárgával jelöli.
    • A TODO-kat kiemeli világoskékkel.
  • A szerkeszt során is számos segítséget kapunk:
    • A beírás során segítséget kapunk a lehetőségekről. Pl. hosszú változóneveknél kérhetünk kiegészítést, egy függvényhívás esetén megadja a lehetséges paramétereket stb. Ez sok esetben automatikus, de Ctrl + Enter kombinációval külön kérhetjük is.
    • Ha a függvényhez tartozik API specifikáció, akkor azt kijelzi.
    • Ha egy absztrakt osztályból öröklődünk, akkor felajánlja, hogy legenerálna a szükséges függvények fejléceit. Ill. úgy általában: hibák esetén lehetőségeket kínál fel. Pl. nem létező osztályra hivatkozás esetén felkínál hasonló nevűeket; ha megtalálja a classpath-on, akkor a megfelelő importot, vagy új osztály létrehozását.
    • Automatikusan beállítja a behúzást.
    • A szövegeken (kommentek, stringek) helyesírás ellenőrzést hajt végre.
  • További lehetőségek szerkesztés során:
    • Jobb kattintás az osztálynéven → Source → itt tudunk gettereket és settereket, konstruktorokat, equals()-t, hashCode()-ot, toString()-et stb. generálni.
    • Jobb kattintás bármelyik elemen (pl. osztálynév, függvénynév, változónév stb.) → Refactor: itt tudjuk átalakítani a kódot. Talán a leggyakrabban használt lehetőség a Rename, ami végrehajtja a teljes átnevezést. Ez azt jelenti, hogy a használati oldalon (akár más forrásfájlokban) is végrehajtja a módosítást. Az osztálynév átnevezésekor a fájlt magát és átnevezi. A csomagok átnevezésekor az összes package és import megfelelően változik.
    • A Ctrl-t nyomva tartva rá tudunk kattintani a definícióra. Lépkedni oda-vissza az Alt + nyilakkal tudunk.
    • Az előző fordítottja az, hogy az adott elemet ki használja. Ezt a következőképpen tudjuk végrehajtani: jobb kattintás → Open Call Hierarchy.
    • Ha kódrészletet másolunk egyik helyről a másikra, akkor a szükséges importokat is átmásolja.
    • Részletesebb keresést tesz lehetővé a Search → Search… Gyakran használt ezek közül a File Search, amely minden fájlban keres.

Fordítás, futtatás, hibakeresés

A környezet beíráskor automatikusan fordít. Ez egyben azt is jelenti, hogy letölti a szükséges könyvtárakat. Ezt ki-be lehet kapcsolni a Project → Build automatically menüpontban. Ugyanott lehet törölni a korábbi fordítás eredményét (ezzel kikényszerítve az újbóli fordítást), ill. explicit megadni a fordítást.

A programot futtatni is tudjuk pl. úgy, hogy jobb egérgombbal kattintunk a futtatni kívánt elemen (pl. main függvényen vagy egységteszten, majd Run As, és itt kiválasztjuk a megfelelőt, pl. Java Application vagy Unit Test. Ha az indításhoz paramétereket szeretnénk beállítani, akkor megtehetjük itt vagy a főmenüből, mindkét esetben a Run → Run Configurations-t kiválasztva (Arguments → Program arguments).

Az IDE-k egyik leghasznosabb tulajdonsága a hibakereső (debug) futtatási lehetőség. Ehhez leállási pontokat (breakpoint) állíthatunk be, a program sorszám előtti részre kattintva. indítsuk el a programot debug módban: jobb kattintás a fő függvények → Debug As → Java Application (vagy a megfelelő). EKkor felajánlja a perspektíva váltást (erről később még lesz szó), most fogadjuk el (Switch). Ha megállt a program, akkor le tudjuk kérdezni a változók pillanatnyi értékét. Lépkedni is tudunk a programban, ld. a Run menüt. Lehetőségek:

  • F5: belelépés a függvénybe.
  • F6: a következő utasításra lépés. Tehát ha az aktuális sor egy függvényhívás, akkor azt lefuttatja, és megáll a következő utasításon. Kivéve, ha abban is van leállási pont.
  • F7: kilép az aktuális függvényből.
  • F8: folytatja a rendes futást.

A megállópont lehet feltételes. Kattintsunk a jobb egérgombbal a megállópont kis gombóc ikonján, itt kapcsoljuk be a Conditional-t, és adjuk meg egy akármilyen bonyolult feltételt (pl. input.equals("start") && f(i) == 2).

A Run Configuration párja itt a Debug Configuration.

Igen hasznos tulajdonság a Coverage: ez aut mutatja meg, hogy futás során mely sorok futottak le. Különösen az egységteszteknél érdemes használni, hogy kiderüljön, van-e le nem fedett ág. A fentiekhez hasonlóan az indítása: Coverage As.

Nézetek és perspektívák

Az Eclipse-ben számos nézet van, melyeket a Window → Show View menüpont kiválasztásával tudunk aktiválni. A leggyakoribb nézetek külön fel vannak sorolva, az Other… menüpontot kiválasztva pedig további nézeteket találunk. Néhány példa:

  • Type hierarchy: típushierarchia. Megmutatja, hogy mi miből öröklődik.
  • Call hierarchy: hívás hierarchia: mi mit hív.
  • Breakpoints: leállási pontok hibakeresésnél.
  • Tasks: kigyűjti a TODO-kat.
  • Console: a futás eredménye látható itt.
  • Package Explorer: csomag nézet; a forrásokat nem fájlrendszerként, hanem csomaghierarchiaként illusztrálja.
  • Outline: áttekintést nyújt az osztály attribútumairól és metódusairól.
  • Servers: az alkalmazásszerver beállításokat láthatjuk itt.

A listát lehetne még hosszasan sorolni. Ez olyan, hogy az emberre idővel "ráragadnak" a leghasznosabbak.

Az se jó, ha egyszerre túl sok információt látunk, mert elveszünk benne, így a nézetek csak egy részét érdemes használni. Az, hogy pontosan melyik részét, az attól is függ, hogy mikor: mást kell fejlesztés során, és mást hibakereséskor. A nézetek nevesített részhalmazait perspektíváknak hívjuk. A fent említett perspektíva váltás pl. a Java fejlesztésről a hibakeresésre történt, ahol megjelentek a leállási pontok, a változók értékeit bemutató nézetek stb., és néhány a hibakereséshez kevésbé fontos nézet eltűnt. Perspektívát a jobb felső sarokban található ikonok segítségével, vagy a Window → Perspective → Open Perspective menüpontot kiválasztva tudunk váltani. Mi magunk is tudunk perspektívát létrehozni, bár ilyet ritkán szoktunk tenni.

Beépülők

Ennek a leírásnak nem célja az Eclipse részletes bemutatása, épp hogy a felszínt karcoltuk. De így is látható ennek a rendszernek a rendkívüli gazdagsága. A beépülőkkel a lehetőségek tárháza tovább bővül. A Help → Eclipse Marketplace… menüpont kiválasztásával tudunk beépülőket telepíteni.

NetBeans

IntelliJ IDEA

Tervezőeszközök

A szoftvereket a megvalósításuk előtt érdemes megtervezni. Tapasztalatom szerint a tervezési hiányosságok keményen megbosszulják magukat, azon nem érdemes spórolni. (Ez egyébként igaz az élet más területeire is.) Ebben a fejezetben néhány tervezőeszközt mutatok be.

UML

Az UML a Unified Modelling Language rövidítése. Ez talán a legelterjedtebb modellező nyelv. Ennek segítségével diagramokat tudunk készíteni. A diagram fajtákat két fő kategóriába sorolhatjuk:

  • Strukturális diagramok (structural diagram): ezek statikus jellegű diagramok, amelyek a rendszer adott állapotát illusztrálják.
    • Osztálydiagram (class diagram): segítségével az objektumorientált nyelvek osztályait, azok tulajdonságait, egymáshoz való viszonyait tudjuk ábrázolni. Az egyik leggyakoribb diagram típus.
    • Komponensdiagram (component diagram): a rendszer fizikai komponenseit, azok kapcsolatait ábrázolja. Tapasztalatom szerint ez nem túl gyakori.
    • Összetett struktúradiagram (composite structure diagram): az osztályok belső szerkezetét mutatja. Ritka diagramtípus, "élesben" még sohasem találkoztam vele.
    • Telepítési diagram (deployment diagram): azt mutatja meg, hogy melyik hardveren melyik szoftverkomponens lesz (van) telepítve. Viszonylag gyakori.
    • Objektumdiagram: ez egy dinamikus állapotot tükröz, amikor létrejöttek az objektum példányok, és azok egymáshoz való viszonyát mutatja be. Ritkán lehet vele találkozni.
    • Csomagdiagram: azt mutatja meg, hogy melyik osztály melyik csomagban van. A valóságban nincs éles határ az osztály- és csomagdiagram között; ha az osztálydiagramon már elég sok osztály van, akkor azt csomagokba szokás szedni. Az UML eszközök többnyire ezt lehetővé teszik.
  • Viselkedési diagramok (behavior diagram): ezek dinamikus jellegű diagramok, amelyek a rendszerben végbemenő folyamatokat illusztrálják.
    • Aktivitásdiagram (activity diagram): ezek a munkafolyamatot modellezik. Leginkább azokra a diagramokra emlékeztet, amelyeket évtizedekkel ezelőtt használtak az informatikakönyvekben a program folyamatának bemutatásához (aminek egyébként semmi értelme nem volt, mert egy jó olvasható, pár soros programot bonyolítottak el vele). Nem túl gyakori diagramtípus.
    • Állapotgép diagram (state machine diagram): ha egy rendszernek vannak jól meghatározott állapotai és átmenetei, akkor ezt érdemes használni. Az olyan jellegű szoftverek megértését nagyban segíti.
    • Használati eset diagram (use case diagram): a program fő funkcióit mutatja be a végfelhasználó szempontjából. A felhasználót egy pálcika ember szimbolizálja; ez igen jellegzetes eleme ezeknek a diagramoknak. Ez az egyik leggyakoribb, és a tervezés kezdeténél leghasznosabb diagramtípus.
    • Interakciós diagramok (interaction diagram): a rendszerelemek közötti kommunikációt mutatják be. A következők tartoznak ide:
      • Szekvencia diagram (sequence diagram): ezzel gyakorlatilag a hívási láncot lehet illusztrálni. A diagramban az egyes szereplők egymás mellett vannak, és azok idővonalai függőlegesek, egymással párhuzamosak. A hívásokat vízszintes nyilak illusztrálják, és az adott időszakban aktív elem idővonalát vastagabban rajzolják. Igen gyakori diagram típus.
      • Kommunikációs diagram: az objektumok közötti kommunikációt illusztrálja. Az objektumok szimbóluma egy-egy téglalap, köztük nyilak találhatóak, a nyilakon pedig általában van egy sorszám és egy felirat. Korábban ezt kollaborációs diagramnak hívták, viszont mivel az negatív érzéseket vált ki, egyrészt átnevezték, másrészt egyszerűsítettek is rajta. Közepesen elterjedt diagram típus. Lehet hasznos, de túl is komplikálhatja a tervet.
      • Interakció áttekintő diagram (interaction overview diagram): az aktivitás diagramra hasonlít, viszont itt egy-egy komponensen belül lehetnek interakciós diagramok, pl. egy rövid szekvencia. Az UML 2.0-ban jelent meg. Még sohasem találkoztam ilyennel a valóságban, de ígéretes.
      • Időzítő diagram (timing diagram): segítségével precíz, akár ezredmásodpercre lebontott időzítést lehet illusztrálni. Ehhez hasonló diagramokkal gyakran lehet találkozni, leginkább a hardverközeli programozásban (pl. Arduino), de úgy mint UML 2.0 diagram, még számomra is újdonság.

Ezeket a diagramokat alapvetően két filozófiai megközelítéssel lehet használni:

  • Részletesen, precízen ki lehet dolgozni a rendszer majdani viselkedését. Egyes eszközök kódot is generálnak belőle.
  • A rendszer magas szintű áttekintését ehet vele illusztrálni, a legtöbb esetben kihagyva a részleteket.

Személy szerint ez utóbbit tartom hasznosabbnak, több okból is:

  • Sokkal gyorsabban elkészíthető. (Nem kell túlzottan törődnünk a precizitással, szabadabban szárnyalhatnak a gondolataink.)
  • Kisebb módosulás esetén nem feltétlenül kell a terveket is módosítani. (Ha az első megközelítést alkalmazzuk, akkor minden apró változtatás maga után vonzza a tervek módosításait is. Ehhez meg kell találnunk az eredeti szoftvert, amivel készült, adott esetben meg kell vele ismerkedünk, esetleg még licenszt is szereznünk kell.)
  • Sokkal áttekinthetőbb. (A részleteiben kidolgozott diagram általában egy nagy áttekinthetetlen katyvasz.)
  • Rosszak a tapasztalataim a generált kódokkal, azok karbantarthatóságával. (Elkerülhetetlen, hogy utólag bele kelljen írni, és ez problémát jelent az újragenerálásnál.)

Lent látni fogunk UML modellező eszközöket; egy összefoglaló lista a Wikipédián ezen az oldalon található: https://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools.

Elmetérkép

Az elmetérkép (angolul mindmap) egy hierarchikusan, fa szerkezetben felépített diagram, melynek mindig van pontosan egy központi eleme, ahhoz kapcsolódnak fogalmak, majd azokat is tovább lehet bontani. Az elmetérképeken általában lehet színezni úgy az elemeket mind a kapcsolatokat, és ennek segítségével jól áttekinthető ábrákat lehet készíteni.

Adatmodellezés

Segítségével SQL táblákat, azok oszlopait, egyéb tulajdonságait, valamint az egyes táblák közötti kapocslatokat lehet illusztrálni. Általában egyszerűbb mint a megvalósítás, mert az m-n kapcsolatokat is egy (megfelelő alakú) szakasz ábrázolja (tehát nem kell külön kapcsolótáblát létrehozni), ill. a hivatkozásokat is elég az adott táblát illusztráló téglalapból kiinduló egyenesekkel ábrázolni.

Az UML-ez képest még hangsúlyosabban merül fel az a kérdés, hogy hogyan szeretnénk használni: ebből szeretnénk generálni a sémát létrehozó SQL scripteket, vagy inkább csak a rendszer adatmodelljének az általános bemutatására használjuk. Én ez utóbbit részesítem előnyben, így a megértés szempontjából lényegtelen táblákat előszeretettel hagyom ki.

Gantt-diagram

Klasszikus projektmenedzsment eszköz, melynek segítségével az tervezhető, hogy mikor ki mivel fog foglalkozni. Általában jól kezelhetőek vele a függőségek, és segítségével egyből látszik, hogy egy újabb feladat mennyivel tolja ki a projekt elkészültét.

Itt is felvetődik az, hogy mire, mennyire precízen szeretnénk használni. A problémát az okozza, hogy sokkal precízebben lehet tervezni a mostani feladatokat, mint a több hónappal későbbieket, erre a bizonytalanságra viszont pont nincs felkészítve. Pl. nem lehet neki olyat mondani, hogy "ez a feladat olyan 6-8 napig fog tartani, de ha pont az a fejlesztő, aki jól ért hozzá, épp szabadságon lesz, akkor érdemes inkább 10 nappal számolni, de elkezdeni csak akkor tudjuk, ha az a második feladat 80%-os készültségen van". Valószínűleg emiatt kopott ki a gyakorlatból. Személy szerint én magas szintű tervezésre használtam, pl. negyedéves vagy max. havi lebontásban, és ennek megfelelően nagyobb tevékenységekre. A feladatokra történő alábontás más módon történt.

Szoftverek

Lássunk néhány tervezőszoftvert!

  • Visio: egész sokféle ábrát lehet segítségével készíteni. Az UML szabványt - fogalmazzunk finoman - nem veszi túl komolyan, valójában egy adott diagramra mindenféle ikont rá tudunk helyezni. Segítségével gyorsan tudunk látványos (bár nem feltétlenül 100%-ban precíz) ábrákat készíteni. Sajnos fizetős, és noha a Microsoft Office csomag része, a tapasztalatom szerint szinte alapból szinte soha nincs feltelepítve.
  • DIA: a Visio ingyenes párja. Kicsit kevesebbe tud, kicsit csúnyább is az eredmény, viszont (érzésem szerint) valamelyest precízebb annál. Sokféle diagramot lehet segítségével létrehozni, szívesen használom.
  • PlantUML: ahogy a nevéből sejthető, ezzel UML diagramokat lehet készíteni. A legtöbb UML tervezővel szemben itt nem egy WYSIWYG szerkesztőt használunk, hanem szövegesen kell megadnunk a tervet. Számos beépülője van, pl. a Confluence oldalakra, vagy Word-be is. A http://plantuml.com/ oldalon egy nagyon jól használható, példákkal alátámasztott tananyag található. Elég gyorsan meg lehet szokni, és igen szerethető!
  • ArgoUML, StarUML: ez két ingyenes WYSIWYG UML szerkesztő, melyekkel tényleg csak UML diagramokat tudunk készíteni. Ha ki szeretnénk zárni még a kísértését is annak, hogy ne UML ábrát készítsünk, hanem csak UML elemeket is tartalmazó akármilyen ábrát, akkor ezeket érdemes használni. Viszonylag gyorsan tanulhatóak.
  • Enterprise Architekt: régebben ez volt a kedvencem. Segítségével precíz UML ábrákat, adatmodelleket és elmetérképeket is lehetett készíteni. Sajnos fizetős, bár amikor használtam, úgy éreztem, hogy megérte az árát.

Adatbázis kezelők

Az adatbázisokról részletesebben van szó a megfelelő oldalon. Ebben a szakaszban az adatbázis kezelőkkel foglalkozunk. Az adatbázis kezelőkkel tipikusan az alábbi műveleteket lehet végrehajtani:

  • adatok megtekintése és módosítása,
  • a megszorítások, indexek, kiváltó utasítások, nézetek stb. megtekintése,
  • adatbázis mentése, betöltése,
  • SQL kód generálása (pl. adattábla létrehozására),
  • adatmodell rajzolása,
  • jogosultság kezelés,
  • és sok minden más.

Néhány adatbázis kezelő szoftver:

  • SQL developer: az Oracle terméke, elsősorban az ő adatbázisuk kezeléséhez, bár más adatbázishoz is tud csatlakozni. Személyes véleményem róla az, hogy ahhoz képest, hogy az Oracle AZ adatbázis, ez a kezelőfelület igen szerényre sikeredett, persze funkcionálisan megfelelően működik.
  • Microsoft SQL Server Management Studio: a Microsoft SQL Server és egyéb Microsoft termékek (Analysis Services, Integration Services, Reporting Services) kezelésére szolgál. Más gyártók adatbázisához szerintem felesleges próbálkozni vele csatlakozni. Szerintem eléggé komplikált, sok helyen logikátlan, de ez legalább illik a nehézsúlyú fő termékéhez.
  • MySQL Workbench: a MySQL adatbázis kezelő felülete. Szerintem ez ey egyszerű és nagyszerű szoftver; ilyennek kell lennie!
  • HeidiSQL: a MariaDB adatbázis kezelője. Őszintén szólva komoly tapasztalatom nincs benne, mert a MySQL-lel elégedett vagyok. Egyszer használtam, akkor rendesen működött.
  • pgAdmin: a PostgreSQL kezelőfelülete. Kissé furcsa, hogy webes felületként működik, ennek megfelelően a használata is kissé nehézkesebb.

Tesztelő- és hibakereső eszközök

Debugging

Lefedettség mérése

TODO: emma (unit test coverage)

GUI tesztelés

TODO: Selenium

API tesztelés

Webes alkalmazások fejlesztésekor igen gyakran szükség van arra, hogy - elsősorban tesztelési céllal - lekérdezéseket hajtsunk végre. Lássunk néhány lehetőséget!

  • Böngészők: nyilvánvaló választás lenne, a tesztet ezzel érdemes kezdenünk, de a nem HTTP protokollt gyakran nem kezeli, így más eszköz után kell néznünk.
  • cURL: parancssori alkalmazás, mellyel HTTP lekéréseket tudunk végrehajtani, pl. curl faragocsaba.hu. (Kiejtése hivatalosa 'körl', de lehetne úgy is, hogy 'szí júerel', ami némi áthallással azt is jelenten, hogy URL megtekintése.)
  • Putty, vagy tetszőleges más telnek kliens: letölthető innen https://www.putty.org/. Elsősorban távoli terminál elérésre lett kifejlesztve, viszont ha beállítjuk a portot, a kapcsolat típusát raw-ra állítjuk, akkor bármely weben elérhető szolgáltatás elérését tudjuk ellenőrizni segítségével.
  • Postman: önálló alkalmazásként (https://www.getpostman.com/) vagy Google Chrome beépülőként (https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop?hl=hu) is fel tudjuk telepíteni. Ahogy a nevéből is következtethetünk, elsősorban a HTTP POST hívások tesztelését könnyíti meg, ahol nemcsak lekérdezünk, hanem adatot is küldünk. De mindenféle HTTP kérés végrehajtására alkalmas, a fejlcé informácikat is be tudjuk állítnai.
  • Visual Studio Code REST client beépülő: a Visual Studio Code egy szövegszerkesztő, ami innen letölthető: https://code.visualstudio.com/. A REST kliens itt található: https://marketplace.visualstudio.com/items?itemName=humao.rest-client. Ha feltelepítjük, és beírunk egy URL-t, majd kijelöljük és Ctrl+Alt+R-t nyomunk, akkor végrehajtja a letöltést, és a HTTP protokoll háttér üzeneteit is megjeleníti.
  • SoapUI: web szolgáltatások tesztelésére alkalmas. Az open source verziót töltsük le a https://www.soapui.org/ oldalról.

HTML tesztelés

TODO: F12

Üzenetküldő rendszerek tesztelése

HermesJMS

Hálózat figyelés

A hálózati forgalom figyelésére ún. sniffer programokat tudunk használni. Ilyen például a WireSHark (https://www.wireshark.org/), mely számos protokollt ismer.

TODO: kipróbálni, rövid összefoglaló a használatáról

Profiling

Integrációs eszközök

Az integrációs eszközök (angolul: continuous integration) célja többrétű:

  • Új verzió létrehozása ("szép magyar" kifejezéssel release-elés). Sokféle hibát okozhat az, ha valakinek a fejlesztői számítógépén készülnek a verziók; azt egy független szerveren érdemes végrehajtani. Egy integrációs eszköz erre tökéletes; valójában ez a legfontosabb feladata.
  • Folyamatos ellenőrzés. Ha valaki egy új verziót tölt fel a közös kódbázisba, akkor az integrációs eszköz azonnal lefordítja. Ha hibát talál benne, akkor azonnal küld értesítést. Hibát akár egy elrontott egységteszt is okozhat, vagy egy olyan forrásfájl, melyet elfelejtett a fejlesztő feltölteni. De merészebbet is gondolhatunk: egyes integrációs eszközök esetén azt is be lehet állítani, hogy akkor is hibásként jelezze a fordítást, ha kódolási szabálysértés került bele, vagy mondjuk az egységtesztek nem fedik le kellő arányban a kódot.
  • Verziózás. Egyes integrációs eszközös képesen automatikusan növelni a verziószámot, így biztos nem marad el.
  • Ütemezett futtatás. Lehetnek olyan műveletek a forráskódon, melyet rendszeres időközönként, pl. naponta vagy hetente egyszer végre kell hajtani; általában erre is használhatjuk az integrációs eszközöket. Például egy nagyobb erőforrás igényű rendszerteszt végrehajtását érdemes éjszakára ütemezni, hogy ne zavarja a napi munkavégzést, és reggelre meg legyen az eredmény.
  • Monitorozás. Az integrációs eszközök alapfeladata elsősorban nem a monitorozás, de alapvető monitorozási feladatok végrehajtására általában kiváló. Például a már említett automatikus figyelmeztető üzeneteket tekinthetjük egyfajta monitorozásnak, ill. általában egyszerűbb kimutatásokat is készít, pl. arról, hogy az elmúlt x fordításból mennyi volt sikeres.

Ez az oldal jól összefoglalja az integrációs eszközöket: https://en.wikipedia.org/wiki/Comparison_of_continuous_integration_software. Közülük a Jenkins-t ismerem (ilyet már telepítettem is, ill. hoztam létre benne jobokat), ill. találkoztam a TeamCity-vel.

Verziókezelő rendszer

SVN

Git

TODO: GitFlow

Sourcetree

Build automatizáló eszközök

Ant

Maven

Gradle

SBT

Repository

TODO: Artifactory

Dokumentum generálás

TODO kidolgozni

Feladatkezelő rendszer

A feladatkezelő rendszerek (angolul issue tracking system) feladata a feladatok menedzselése. A szoftverfejlesztésben a feladatok száma óriási, lehetetlen észben tartani, egy-egy feladat átfutási ideje igen hosszú is lehet, és a feladatok szinte egyáltalán nem ismétlődnek, így elkerülhetetlen valamilyen feladatkezelő eszköz használata. Először lássuk, általában mi mindenre lehet használni a feladatkezelőket!

  • Ahogy a neve is mondja, feladatokat (angolul ezt így hívjuk: ticket) lehet benne létrehozni. Általában meg lehet adni a feladat címét, típusát (pl. egy új funkció kifejlesztése, hibajavítás, valamilyen feladat, esetleg más); azt, hogy melyik programra vonatkozik, annak melyik komponense és melyik verziója az érintett; természetesen a feladat részletes leírását, és még sok minden mást is.
  • Egy-egy feladatnak általában vannak lehetséges állapotai ill. átmenetei. A három legfontosabb a nyitott (még nem foglalkozott vele senki), folyamatban van, ill. kész. Projekttől függően lehetnek további fázisok is, pl. tesztelés alatt, blokkolt stb.
  • A feladatokat általában hozzá lehet rendelni valakihez, lehet fájlokat feltölteni, megjegyzéseket hozzáfűzni, hozzákapcsolni más feladatokhoz, alfeladatokat létrehozni stb.
  • Bizonyos feladatkezelők lehetővé teszik a projekt menedzselését is: pl. határidőket lehet hozzárendelni, órákat lehet rákönyvelni, de olyan is van, hogy egy az egyben támogatja pl. a Scrum módszertant, pl. sprinteket lehet létrehozni benne, a story point-okat lehet benne adminisztrálni stb.

Néhány ismertebb feladtkezelő rendszer:

  • TRAC: egyszerű, nem túl nagy tudású feladatkezelő rendszer, kisebb projekteknél a célnak megfelel.
  • Jira: az írás pillanatában valószínűleg piacvezető. Nagy tudású, jól konfigurálható rendszer, a fent felsorolt tulajdonságok mindegyikével rendelkezik.

Dokumentum kezelő rendszer

Fontos, hogy minden projektnek legyen egy olyan felülete, ahova a projektek során keletkező leírások kerülnek. Egyszerűbb esetekben ez lehet egy egyszerű Word dokumentum egy verziókövető rendszerben, de ha van rá mód, akkor inkább egy mindenki által szerkeszthető online felület a jobb választás. A Confluence ilyen.

Monitorozó eszközök

A monitorozó eszközök folyamatosan figyelik a rendszereket, és jelzik a kieséseket. A céljuk az, hogy probléma esetén mihamarabb kapjunk róla értesítést, hogy legyen esélyünk lépni, mielőtt a végfelhasználó észreveszi. Igen kellemetlen tud ugyanis lenni az, hogy egy egyébként nyilvánvaló probléma (pl. nem elérhető a weboldal) csak a végfelhasználó panaszának következtében jut tudomásunkra. Ezen kívül a cégnek lehetnek vállalásai pl. az elérhetőség tekintetében, és a monitorozó eszközökkel statisztikákat is tudunk készíteni. Néhány példa:

  • Nagios: ez egy klasszikus, nyílt forráskódú monitorozó eszköz, ami jelzi, hogy egy rendszer elérhető-e vagy sem, statisztikát készít, és riaszt is, ha kell.
  • Datadog: elsősorban felhő alapú szolgáltatások monitorozására fejlesztették ki, és a klasszikus monitorozó szolgáltatásokon túl adatelemzést is végez.

Virtualizáció

A virtualizáció azt jelenti, hogy egy program nem az adott operációs rendszeren fut közvetlenül, hanem egy "dobozban", akár más operációs rendszer alatt. A szoftverfejlesztés során gyakorlat, hogy egy program egy ilyen virtuális dobozban fut, lényegében függetlenül a gazda operációs rendszertől. Fontos fogalmak:

  • Gazda (host): a fő operációs rendszer.
  • Vendég (guest): a virtuális operációs rendszer.

A lent bemutatott két elterjedt opció egymást kizáróak. A példában a gazda Windows 10 lesz, a vendég pedig Linux.

VirtualBox

Ahhoz, hogy a VirtualBox-ot használni tudjuk, ki kell kapcsolni a Hyper-V-t: Turn Windows features on and off -> a Hyper-V legyen kikapcsolva. Ha most kapcsoltuk ki, akkor újra kell indítani a számítógépet, különben nem fogjuk tudni használni a VirtualBox-ot. Ezt akkor is meg kell tennünk, ha visszakapcsoltuk a Docker miatt a Hyper-V-t, és csak el szeretnénk indítani egy VirtualBox-os virtuális gépet.

Letöltés: töltsük le a VirtualBox-ot a https://www.virtualbox.org/ oldalról (egy egyértelmű, szép nagy ikon jelzi, hogy mit kell letölteni), és telepítsük fel. Töltsünk le egy Linux képet is, pl. egy Ubuntu disztribúciót, innen: https://www.ubuntu.com/download/desktop (pl. én ezt töltöttem le: ubuntu-18.04.2-desktop-amd64.iso )

A VirtualBox telepítése: figyelmeztet, hogy megszakad az internet kapcsolat, ezt fogadjuk el, valamint valami meghajítót is feltelepít, azt is hagyjuk jóvá.

Új virtuális gép létrehozása: indítsuk el a VirtualBox-ot, és készítsünk egy új virtuális gépet a Machine -> New… menüponttal (Ctrl + N, vagy a megfelelő ikonra kattintva). Adjunk neki egy tetszőleges nevet, válasszuk ki, hogy hol helyezkedjen el (a gazda gépen ez egyetlen könyvtárként, azon belül néhány fájlként fog megjelenni), válasszuk ki az operációs rendszer típusát (pl. Linux) és verzióját (pl. Ubuntu (64-bit)). A Next-re kattintva adjuk meg, hogy mennyi memóriát adunk a rendszernek (az alapértelmezett 1024 MB-tot felnöveltem 4096 MB-ra), az újabb Next után maradjon a választás az, hogy Create a virtual hard disk now -> Create -> itt maradjon a VDI -> Next -> maradjon a Dynamically allocated -> Next -> az alapértelmezett 10 GB-ot kicsinek gondolom, megnöveltem 20 GB-ra -> Create. Indítás előtt kattintsunk a beállításokra (Settings), és a Display alatt a videó memória legyen magasabb érték, valamint a Shared folders-en belül adjon meg egy könyvtárat, amin keresztül a gazda gép és a vendég kommunikálni tudnak.

A vendég telepítése: kattintsunk az indításra (Start), itt válasszuk ki a fent letöltött disztribúciót, és kattintsunk a Start-ra. Ha a vendég "elkapja" az egeret, akkor a gazda gépre a jobb Ctrl billentyű lenyomásával tudunk visszatérni. (Ha nem kapcsoltuk ki a Hyper-V-t és nem indítottuk újra a számítógépet, akkor ezen a ponton végtelen ciklusba esik a telepítés.) Az operációs rendszert a szokásos módon telepítsük: pl. Ubuntu esetén a nyelv maradjon angol (a magyar telepítő sajnos hibás) -> Install Ubuntu -> válasszuk ki a billentyűzetet -> Normal installation -> Continue -> Erase disk and install Ubuntu -> Install Now -> Continue -> Budapest -> Continue -> töltsük ki a nevünket, a jelszavunkat, és állítsuk be, hogy ne kelljen bejelentkezni -> Continue, majd várjuk meg, míg felmásolja a fájlokat. A telepítés végén újra kell indítani a vendég operációs rendszert, de mindez a VirtualBox-on belül lezajlik, a gazda operációs rendszer tudta nélkül.

Utólagos beállítások: a telepítés után, amikor fut a vendég operációs rendszer, abban a VirtualBox ablakban (tehát a gazda operációs rendszer szinten) válasszuk ki a Devices -> Insert Guest Addons CD Image… menüpontot, majd a vendég operációs rendszerben ezt telepítsük fel. Ha a gazda gépen be is állítottuk az automatikus felcsatolást, a tapasztalatom szerint ez nem működik, a vendég operációs rendszeren kell beállítani, pl. a következő módon (feltéve, hogy a megosztott könyvtár megnevezése share): jobb egérgombbal -> Open Terminal, majd

sudo mkdir /media/windows-share
sudo mount -t vboxsf share /media/windows-share

A megfelelő könyvtárba írva azt látni fogjuk a másikon. Megjegyzés: nem sikerült beállítanom azt, hogy újraindulás után is megmaradjon a felcsatolás. A gazda gépen a Shared Folders-ben hiába állítottam be az Auto-mount-ot és a Make permanent-et, nem működött, és a vendég gépen a neten talált megoldások egyike sem működött. Így létre hoztam egy winshare futtatható fájlt (ld. a gedit szövegszerkesztőt), a fenti mount paranccsal, amit indulás után ki kell adni.

Érdemes beállítani a megosztott vágólapot (Devices -> Shared Clipboard -> Bidirectional) és a megosztott fogd és viddet is (Devices -> Drag and Drop -> Bidirectional). A vendég gép újaindítását követően lép életbe.

A vendég pont ugyanúgy éri el az internetet, ahogyan a gazda. Ha proxy-t kell megadni, akkor a vendég gépben is ugyanúgy meg kell adni. Pl. a Firefox böngészővel tudjuk ezt kipróbálni.

Érdemes még beállítani azt, hogy ne kapcsolódjon le a vendég gép automatikusan: a jobb felső sarokban található lefele nyílra, majd a lenyíló menüben a bal alsó ikonra kattintsunk (Settings), itt válasszuk ki a Power-t, és ott értelemszerűen állítsuk át az értékeket arra, hogy Never.

Docker

A Docker egy olyan virtualizációs eszköz, amelynek segítségével egy adott programot lehet futtatni (ellentétben a VirtualBox-szal, amelyben egy teljes virtuális operációs rendszert telepítünk, és azon belül telepítjük a programokat). Sajnos egyszerre nem működik a Docker és a VirtualBox, a kettő kizárja egymást (egészen pontosan a Docker kizárja a VirtualBox-ot). Használata nem egyszerű. Lássuk!

Windows 10 operációs rendszer alatt a hivatalos telepítési dokumentációs ez: https://docs.docker.com/docker-for-windows/install/. Ha nem lenne egyértelmű, ezt kell letölteni: https://download.docker.com/win/stable/Docker%20for%20Windows%20Installer.exe. Korábbi operációs rendszerek alatt a Docker nem működik, helyette a Docker Toolbox használható: https://docs.docker.com/toolbox/toolbox_install_windows/.

Telepítés előtt végre kell hajtani pár lépést:

  • BIOS szinten engedélyezni kell a virtualizációt (ez általában alapértelmezésben engedélyezve van).
  • Operációs rendszer szinten engedélyezni kell a Hyper-V-t (ez alapértelmezésben nincs engedélyezve): Turn Windows features on and off → itt a Hyper-V-t kapcsoljuk be (mindet) → OK, majd újra kell indítani a számítógépet. Ezzel egyébként lehetetlenné tesszük a VirtualBox indulását, így ha azt szeretnénk használni, akkor ki kell kapcsolni a Hyper-V-t, és természetesen ismét újra kell indítani a számítógépet.
  • Telepítsük a Docker for Windows-t. A konténer típusára rá fog kérdezni; az legyen Linux.
  • Indítsuk el a programot. Az ikonja egy megrakott teherhajó és ha fut, akkor a jobb alsó sarokban látható. Kattintsunk jobb egérgombbal → Settings → itt beállíthatjuk az alapértelmezett dolgokat (Proxy, ilyesmi).
  • Hozzunk létre egy azonosítót a https://hub.docker.com/ oldalon.
  • Elvileg van egy grafikus felhasználói felülete, a Kitematic, de nekem nem sikerült működésre bírnom.
  • Elvileg meg lehet osztani könyvtárakat a gazda és a vendég között, de ez nálam nem működött. Ha valaki próbálkozni szeretne ezzel, akkor annak ajánlom a következő oldalt: https://blog.olandese.nl/2017/05/03/solve-docker-for-windows-error-a-firewall-is-blocking-file-sharing-between-windows-and-the-containers/.

Használata. Command line-ból adjuk ki az alábbi parancsokat:

  • Ellenőrizzük, hogy működik-e, a verzió kiíratásával: docker version
  • Lépjünk be az azonosítónkkal: docker login
  • Böngésszünk a képfájlok között: https://hub.docker.com/search/?type=image
  • Listázzuk ki a letöltött képeket: docker images
  • Töltsünk le egy képet: docker pull [imagename]
  • Indítsunk el egy letöltött képet: docker run [imagename]
  • Listázzuk ki a futó konténereket: docker ps -a
  • Másoljunk fájlt egy futó konténerbe: docker cp foo.txt [containerID]:/foo.txt

Ha már van telepítve Docker, és szeretnénk teljesen újratelepíteni, akkor az uninstall futtatása után kézzel ki kell törölni az alábbi két könyvtár tartalmát is: c:\Users\[username]\.docker, c:\Users\Public\Documents\Hyper-V, valamint a DOCKER kezdetű környezeti változókat, különben nem fog működni.

TODO: folytatni

Linux grafikus felület megjelenítése Windows-on

Xming

Szoftverbiztonság

Távoli elérés

Belépés távoli gépre konzolosan

A konzolos elérés több évtizedes múltra tekint vissza, mondhatni egyidős a számítógépes hálózatokkal. Az első ilyen protokoll a telnet, melyet az ugyanilyen nevű programmal lehetett használni. Az alapértelmezett telnet port távoli belépésre a 23, bár magával a programmal bármely portot el tudjuk érni.

A titkosítás problémája igen korán jelentkezett, mert titkosítatlanul érzékeny adatok (pl. jelszavak) kerülhetnek illetéktelen kezekbe. A titkosított csatornán történő távoli elérés protokollja az ssh (Secure Shell), aminek az alapértelmezett portja a 22.

A legnépszerűbb telnet ill. ssh kliens Windows-on (az egyébként grafikus) PuTTY (https://www.putty.org/), Linuxon pedig a telnet ill. ssh. Klasszikusan azonosítóval és jelszóval tudunk belépni távoli szerverre, az ssh viszont lehetővé teszi a kulcsokkal történő belépést. Ez a következőképpen történik: a felhasználó generál magának egy publikus és egy privát kulcs párt, pl. a PuTTYgen program segítségével. A publikus kulcsot elküldi a távoli szerver rendszergazdájának, aki beregisztrálja a /home/[user]/.ssh/authorized_keys fájlba. Itt egy sor egy bejegyzés, ami ssh-rsa-val kezdődik. A privát kulcsot titokban kell tartani. A PuTTY kliensben a Connection → SSH → Auth → Private key for authentication alatt kell beállítani. Windows-on a privát kulcs tipikus helye c:\Users\[user]\.ssh\private.ppk.

A privát kulcsot célszerű jelszóval védeni. A Pageant nevű program segítségével tudjuk a jelszót memóriában tartani, így nem kell minden egyes alkalommal begépelni.

Távoli grafikus elérés

TODO: Remote Desktop

A jump szerver fogalma

Fájlok másolása számítógépek között

Klasszikus feladat fájlok átmásolása egyik szerverről a másikra. Az ftp-t (file transfer protocol) használhatjuk erre a célra, ami egyébként az olyan fájlkezelő szoftverekben is megtalálható, mint pl. a Total Commander. Linux operációs rendszeren általában parancssorosan létezik ftp program; ez esetben az ftp a file transfer program rövidítése. Amilyen egyszerűnek hangzik a feladat, olyan sok fejtörést okozott egyébként az idők folyamán. Mindennek az oka az, hogy a Windows rendszereken a a sor vége \r\n (tehát kocsi vissza + új sor), míg a Linux rendszereken \n (ami kocsi vissza és új sor egyszerre). Ma már többnyire képesek mindkét oldalon kezelni a programok az eltérést, de volt idő, amikor egy az egyben történő átmásolásnál (Windows-ról Linuxra) megduplázódtak a sorok, mert a Linux rendszerek a \r-t is új sorként értékelték. Erre találták ki a szöveges másolási módot,amivel nagyobb bajt nem is tudtak volna okozni: ettől kezdve ugyanis előfordult, hogy bináris fájlokat (pl. képeket) véletlenül szöveges formában továbbítottak, minek következtében a célszerveren használhatatlanná vált.

Idővel a biztonsági kérdések váltak jelentőssé. Ne feledjük, hogy az interneten ha rácsatlakozunk egy szerverre, a kapcsolat a legritkább esetben közvetlen, az adat számos köztes szerveren halad keresztül, ráadásul a pontos útvonal legtöbb esetben nem is determinisztikus. Ha bizalmas adatokat másolunk egyik szerverről a másikra, akkor könnyen lehet, hogy egy köztes szerver azokat "lehallgatja". Ennek kezelésére találták ki az sftp-t (secure file transfer protocol). Ez a kliens oldalon titkosítja az adatokat, és szerver oldalon visszafejti, a köztes szerverek nem tudják az adatot visszafejteni. Linux alatt az scp, míg Windows alatt a WinSCP a legnépszerűbb sftp kliens. Az ssh-hoz hasonlóan az autentikáció itt is történhet azonosítóval és jelszóval, vagy publikus-privát kulcspárral.

Az ftp fel- és letöltésre is egyaránt alkalmas, és tipikusan mindkét irányban használják is.

Több fájl letöltésére, ill. leginkább egy weboldal tükrözésére használható a parancssoros wget nevű program. Ez csak letöltésre használatos. A html oldalakon követi a linkeket. Megadható, hogy milyen mélységben kövesse, ill. hogy kiléphet-e az adott domain-ről.

Windows alatt ingyen elérhető a HTTrack, mely ugyanezt a célt szolgálja, de grafikus felhasználói felülettel rendelkezik.

Virtuális privát hálózat

VPN

Lokálisan futó web interfész távoli elérése

Előfordulhat, hogy egy rendszer lokálian fut, és (leginkább tesztelés céllal) kívülről el szeretnénk érni. Ehhez használhatjuk a https://ngrok.com/ oldalt, amelynek segítségével elkészíthetünk egy ilyen átirányítást. Használat: töltsük le a programot, majd indítsuk el a következőképpen:

ngrok http 8080

URL rövidítés

Ha szükségünk van rövidebb URL-re, vagy gyorsan lére szeretnénk hozni egy átirányítást, akkor az URL rövidítő szolgáltatásokat használhatjuk. Néhány példa:

Konferencia eszközök

Egyre inkább elterjednek az atipikus munkavégzési módszerek, például az esetenkénti Home Office vagy az állandó távmunka. Ezeket segíti elő a konferencia eszközök, amelyek segítségével üzenetek tudunk küldeni egymásnak, hang vagy akár videó konferenciákat tudunk indítani, meg tudjuk osztani a képernyőnket, és ezáltal tényleg egyre kisebb jelentősége van a munkavégzés helyszínének.

Íme néhány konferencia eszköz, melyeket leginkább munkahelyi célokra szokás használni:

  • Skype: egy hor ez volt "a" konferencia eszköz, de amióta a Microsoft felvásárolta, nekem csak rossz tapasztalataim vannak vele. Magán célra azóta inkább Viber-t használok. A nagyvállalatoknál gyakran előírás a Microsoft termékek, így a Skype használata is, és valószínűleg e kötelezettség miatt nem szűnik meg olyan gyorsan. Elméletben tud mindent, amit egy konferencia eszköznek tudnia kell, de igen megbízhatatlanul teszi. A korábbi beszélgetések eltűnnek (ez szándékos), a kapcsolat konferencia közben gyakran váratlanul megszakad, eléggé nehézkes a bejelentkezés, így nem csoda, hogy az emberek elpártolnak.
  • Slack: a Skype bénázása előtérbe hozta a Slack-et. Ebben logikus rendben vannak a dolgok: legfelül a munkaterület (workspace) található, melyen belül csatornákat (channel) lehet kialakítani (ami lehet publikus vagy privát), ill. magánbeszélgetéseket is lehet folytatni. Az elküldött üzeneten lehet utólag módosítani, azokat lehet formázni, az üzenetek megmaradnak, lehet audió- és videókonferenciát létrehozni, képernyőt megosztani stb. Tehát nemcsak hogy funkcionálisan is többet tud mint a Skype, de azt stabilan teszi, így nem csoda, hogy - noha általában hivatalosan nem támogatott - átveszi a Skype helyét.
  • WebEx: hasonló mint a Slack, de kissé nehézkesebbnek érzem. A korábbi beszélgetések eltűnnek, legalábbis én nem találom. (Márpedig ha egy felhazsnáló nem találja, azok bizony definíció szerint eltűnnek!)
  • Teams: ilyen is van, nincs vele tapasztalatom; ha lesz, megírom. Állítólag jó.

Fejlesztési módszerek

Elvileg lehetséges különösebb módszertan nélkül is fejleszteni, viszont a tapasztalat azt mutatja, hogy egy adott módszer következetes alkalmazása hatékonyabb annál, mintha nem használnánk semmit. Sokféle fejlesztési modell létezik. Vannak általános modellek, és cég specifikus modellek is. Ezekből kettőt mutatok be, melyek filozófiájukban is jelentősen eltérnek.

Vízesés modell

Ez a modell egy régi modell, amit tipikusan nagy projektek esetén alkalmaznak. Az átfutási ideje éves nagyságrendben mérhető, és a szoftver újabb verziója a végén lesz kész. 5 fő fázist különböztetünk meg:

  • követelmények meghatározása,
  • rendszer- és szoftvertervezés,
  • implementáció és egységteszt,
  • integráció és rendszerteszt,
  • működtetés és karbantartás.

Ezek a fázisok alapvetően egymás után, valamelyest átlapolva követik egymást. Konkrét esetekben meghatározzák, hogy melyik dátumig melyik fázisnak milyen elkészültségi szinten kell lennie. Pl. lehet, hogy a rendszer- és szoftvertervezés fázis elkezdődhet akkor, ha a követelmények meghatározása elért egy bizonyos arányt, de az implementáció és egységteszt csak akkor kezdődhet, ha a követelmények meghatározása már 100%-os. Ha függőlegesen ábrázoljuk az elkészültséget, felül van a 0, alul a 100%, a fenti 5 fázist egymás mellé helyezzük, és az idő függvényében animáljuk, akkor az eredmény kb. úgy nézne ki, hogy először a legbaloldalibb kezdene lefelé haladni, utána a második bizonyos fáziskéséssel stb., és az egész egy vízesésre hasonlít.

Agilis fejlesztés

A vízesés modellnek - kétség kívüli előnyei ellenére - van egy óriási hátránya: a megrendelő túl későn lát belőle valamit. Egy-két év túl hosszú idő az informatikában, ennyi idő alatt sok minden történik, sok minden elavul, és ha mondjuk 200 fejlesztő 2 évnyi munkája után derül ki, hogy a megrendelő valójában nem is ezt akarta, akkor az óriási veszteség. Ezekre a problémákra jelentek meg az agilis fejlesztési módszerek, mindenekelőtt a Scrum, melyben (ideális esetben) a megrendelő is be van vonva a folyamatba, folyamatosan látja a fejlődést, a szoftver nagyon sok kicsi, használható iterációban épül fel. A fejlesztés a következőképpen történik:

  • A scrum csapat pár fős, és egy scrum master vezeti.
  • A módszer legfontosabb fogalma a sprint: ez az az időtartam, ami alatt elkészül a következő demózható változat. A spring hossza változó, tipikusan 2-4 hét.
  • A sprint tervezéssel kezdődik: ennek során meghatározzák a következő pár hétben megvalósítandó feladatokat. Ennek egy része az ún. esztimációs póker: minden feladatra, miután valaki ismertette, megpróbálják megbecsülni az összetettségét, mégpedig úgy, hogy minden csapattag titokban választ egy Fibonacci számot, és egyszerre felmutatják. A végén konszenzusra kell jutni.
  • A fejlesztés során napi megbeszélést tartanak a résztvevők (ha fizikailag együtt ülnek, akkor általában állva, emiatt hívják ezt daily standup meeting-nek), melyben mindenki elmondja, hogy mit csinált a legutóbbi megbeszélés óta, van-e valami, ami akadályozza, és mit tervez a következő napra. Ezeknek a megbeszélésnek a hossza kb. negyed óra.
  • A feladatok alapvetően a csapathoz vannak rendelve, és (ideális esetben) a csapattagok helyettesíteni tudják egymást. (A valóságban persze mindenkinek kialakul egy területe, és általában nem kérdés, hogy ki fog elvégezni egy adott feladatot, de addig mindenképpen eljutnak a csapattagok, hogy legalább nagy vonalakban értsék egymás feladatait.)
  • Ideális esetben a sprint tartalma nem változik, és a közben felmerülő feladatok az ún. backlog-ba kerülnek. Ez képezi a következő sprintek bemenetét. (A valóságban ezt nem lehet teljesen következetesen végigvinni, mert vannak tényleg halaszthatatlan feladatok, emiatt érdemes némi puffert hagyni a tervezésnél a nem várt feladatokra.)
  • A sprint review-val végződik: amikor átnézik, hogy mit hogyan teljesítettek. Ideális esetben lehet demózni az eredményt, és ugyancsak ideális esetben ezen a demón a megrendelő is részt vesz. Ez mindenkinek jó, mert a vevő látja a fejlődést, és azonnali visszajelzést tud adni, ami nyilván hasznos a csapatnak is. Ezzel a módszerrel elkerülhető az, hogy hónapok, évek elteltével derüljön ki, hogy nem azt kapja a vevő, amit várt.
  • A sprint a retrospective-vel zárul, melynek során a csapat visszatekint az elmúlt sprintre, mindenki elmondja, hogy mi volt benne a jó és hol lehetne még javítani, majd a javítandó pontokról szavaznak, és a legtöbb szavazatot kapott problémákhoz akciótervet készítenek.

Szoftverminőség

Áttekintés

A szoftverfejlesztésnek van egy olyan területe, amely többnyire nem kap elég hangsúlyt: ez a szoftverminőség. Az idő előrehaladtával szerencsére egyértelmű javulás tapasztalható ezen a területen, de még messze vagyunk az ideális állapottól. A szoftverfejlesztés más területeit a rövid távú érdek vagy a kényszer hangsúlyossá teszik (gondoljunk pl. az intergrált fejlesztőeszközök nyújtotta kényelemre vagy a szoftverbiztonsági problémákból adódó kényszerre), a minőség viszont egy nehezen megfogható dolog, melynek a haszna is közvetett. Egészen pontosan: a jó minőségű szoftvernek önmagában nincs is haszna, hanem a rossz minőségű szoftver okozhat óriási károkat. És itt nem véletlenül használtam a feltételes módot: okozhat, de nem biztos, hogy okoz. Emiatt a menedzserek nem szívesen áldoznak erre erőforrást, pénzt, mivel mindig van valami fontosabb.

Az akadémiai világnak viszont a szoftverminőség egy mondhatni kedvenc témája: hatalmas mennyiségű publikáció született ezen a területen. (Az én PhD-m is a téma egy kis szegletéből készült.) A Nemzetközi Szabványügyi Hivatal, az ISO is foglalkozott a témával, megalkotta a 9126-os számú szabványt, melyet azóta felváltott a tovább fejlesztett 25010-es. Az eredeti szabvány a szoftverminőségnek az alábbi 6 területét definiálta:

  • Funkcionalitás (functionality): ez azt jelenti, hogy a szoftver valóban azt csinálja, amit magáról állít. Részei: megfelelés, pontosság, együttműködés (más rendszerekkel), biztonság. A megfelelés valószínűleg a minőség legfontosabb része, mert ha mondjuk egy rajzoló programmal nem lehet rajzolni, akkor nincs értelme a programnak.
  • Megbízhatóság (reliability): adott körülmények között adott ideig adott teljesítményt nyújt. Részei: érettség, visszaállíthatóság, hiba tolerancia. Ha egy szoftver kezdetben jól működik, de nem sokkal a telepítés után használhatatlanná válik, az adatokat nem lehet kimenteni és visszaállítani, akkor az nem megbízható.
  • Használhatóság (usability): arról szól, hogy a szoftver célközönségének mennyi energiára van szüksége ahhoz, hogy használni tudja a szoftvert. Részei: érthetőség, tanulhatóság, kezelhetőség, vonzó külső. Gyakran előfordul, hogy egy, funkcionálisan jól és megbízhatóan működő szoftver annyira bonyolult, hogy nem szívesen használjuk.
  • Hatékonyság (efficiency): a szoftver által használt erőforrásokról szól. Részei: idő és erőforrás. Elvárjuk egy szoftvertől, hogy hatékonyan bánjon az erőforrásokkal, mert az nem elfogadható, hogy ha a legegyszerűbbnél egy picivel bonyolult műveletet hajtunk végre, akkor minden erőforrást "felzabál".
  • Karbantarthatóság (maintainability): arról szól, hogy mennyi munkára van szükség ahhoz, hogy módosítsunk rajta. Részei: elemezhetőség, módosíthatóság, stabilitás, tesztelhetőség. Egy szoftver a legritkább esetben tekinthető véglegesnek; az idők folyamán új igények merülnek fel, vagy hibák jönnek elő. Ha túl komplikált a kód, nehéz áttekinteni, adott helyen történő módosítás nem várt hatást vált ki máshol, gyakran elszáll, nehézkes kipróbálni, akkor drága és veszélyes lehet a legegyszerűbb továbbfejlesztés is.
  • Hordozhatóság (portability): a szoftver különböző környezetekbe történő telepíthetőségéről szó. Részei: alkalmazhatóság, telepíthetőség, együttlétezés, cserélhetőség. Az nem jó szoftver, ha csak adott operációs rendszer adott verziójának adott nyelvi változatával működik, nehézkes a telepítése, bizonyos szoftvereket nem szabad feltelepíteni, hogy használhassuk, és lehetetlen kiváltani mással.

Ezek egyben a szoftver nemfunkcionális részei. Érdemes felsorolni azokat az elemeket, amelyeket az Oracle definiál. Ez részben átfedésben van a fenti szabvánnyal; vannak elemek, amelyeket a szabvány egy alkategóriaként kezel, és olyan is van, ami nem része a szabványnak.

  • Teljesítmény (performance): ez alatt válaszidőt kell érteni, tehát pl. mennyi ideig kell várni egy képernyőkattintás után a válaszra.
  • Skálázhatóság (scalability): azt jelenti, hogy a terhelés növekedésével is ki tudja szolgálni a rendszer a kéréseket. Mivel egyre nagyobb mennyiségben keletkezik az adat, ennek a jelentősége csak fokozódik.
  • Megbízhatóság
  • Rendelkezésre állás (availability): ideális esetben azt jelenti, hogy folyamatosan elérhető. A valóságban ez egy arányt jelent, hogy az idő hány százalékéban érhető el a rendszer ténylegesen. Pl. az nem elfogadható, hogy egy rendszer leálljon és elérhetetlen legyen napokon át, de mondjuk egy alapnak számító, 99,5%-os rendelkezésre állás már igen. Egyébként A tipikus rendelkezésre állásnak a formája 99, 9..95%. Ezt egy számmal adják meg, ami a kilencesek száma az 5-ös előtt.
  • Kiterjeszthetőség (extensibility): anélkül lehessen új funkciót hozzáadni, hogy a már meglevő funkcionalitást módosítani kelljen.
  • Karbantarthatóság
  • Kezelhetőség (manageablility): ez alatt az adminisztrátori szintű kezelést kell érteni, hogy folyamatosan biztosítani lehessen a többi nemfunkcionális követelményt.
  • Biztonság (security): ne lehessen a rendszert veszélyeztetni.

Clean Code

Robert C. Martin Clean Code című könyve az áttekinthető forráskód alapműve, emiatt adtam ezt a címet ennek a szakasznak. Nem célom a könyv ismertetése, hanem annak koncepciója: az, hogy nagyon fontos, hogy a kód olvasható legyen.

Íme a saját listám!

  • Kódolási konvenciók: nincsenek kőbe vésett szabályok, kivéve egyet: legyen konzisztens! Érdemes a profiktól is lesni: a Google kódolási stílusa pl. az alábbi: http://google.github.io/styleguide/javaguide.html.
    • Behúzás: döntsük el, hogy tabulátorokat vagy szóközöket használunk, ill. ez utóbbi esetben mekkora legyen. Vannak programozási nyelvek (pl. Python), mely megköveteli a pontos formát, de többnyire szabad kezet kapunk. Kezdetben a tabulátor híve voltam, ma inkább 4 szóközt használok.
    • Blokk eleje és vége: a kérdés az, hogy hova tegyük a blokk elejét jelző elemet (általában kapcsos zárójelet): az előző sor végére vagy egy új sor elejére. Én az előz sor végére szoktam tenni, mert úgy szoktam meg, az a gyakoribb, és tömörebb kódot ad, de a másiknak is van létjogosultsága, pl. az, hogy ugyanolyan mélyen van a nyitó és a csukó zárójel. Válasszunk egyet, és legyünk konzekvensek!
    • Egy osztály elrendezése: itt arról van szó, hogy milyen sorrendben legyenek az attribútumok, konstruktorok, lekérő és beállító függvények, egyéb függvények, generált kód stb. Én a felsorolt sorrendben szoktam megadni. Ill. ide sorolnám még azt is, hogy a tagolás aszerint történjen, hogy előbb jönnek a publikus, utána a protected, végül a privát metódusok, vagy a csoportosításuk logikai (én ez utóbbit szoktam alkalmazni). A legfontosabb itt is a konzekvencia.
    • Központozás: arról szól, hogy hova teszünk szóközt. Ezeket a szabályokat egy picit erősebbnek érzem a többinél, melyek a következők. A kulcsszó és az azt követő zárójel közé mindig szóköz kerül. Ha a vessző ill. pontosvessző után van még a sorban valami, akkor mindig van szóköz közöttük, előtte viszont soha. Az egyenlőségjel előtt és után mindig van szóköz. A műveletek körül van szóköz. A függvénynév és a paraméterlista között nincs szóköz.
    • Kisbetű és nagybetű: a függvénynév kisbetűvel kezdődik, és ún. Camel Case módon folytatódik, tehát az új szó kezdőbetűje benne nagybetű, így: ezEgyFüggvény(). A változó név szintúgy (beleértve az osztály attribútumokat és a függvények paramétereit is). Az osztálynév nagybetűvel kezdődik, utána Camel Case. A csomag név csupa kisbetű. A felsorolás típus, valamint a szöveg konstans csupa nagybetű. Az már vita tárgya lehet, hogy ha egy rövidítés fordul elő mondjuk egy függvénynévben, akkor azt hogyan használjuk, pl. formatToJson() vagy formatToJSON(); én az elsőt használom (ennek az oka az, hogy ha a kis kezdőbetűs változó elejére kerül egy ilyen, akkor a jsonFormattedValue szerintem jobban néz ki, mint az, hogy jSONFormattedValue), de itt is a konzisztens használat a lényeg.
    • Maximális sorszélesség: személy szerint nem szeretem lefixálni a sor szélességének a maximumát. Kezdetben pl. 80, később 120 karakter volt, de pl. a mostani monitoromon kb. 200 karakter kényelmesen elfér. Ezt a fejlesztőre érdemes bízni. Vannak pl. olyan sorok, melyeknek az olvashatósága lényegtelen: pl. egy debug log üzenet megformázása: az lehet akármilyen széles, nem érdekes. De lehetne olyan részek, ahol fontos, hogy jól lássuk az egészet, ott kell a sortörés úgy, hogy egy átlagos monitoron ne kelljen mozgatni a szöveget.
    • Felsorolások: ez szorosan kapcsolódik a maximális sorszélességhez, és az a dilemma, hogy mondjuk egy függvény paraméter listát egy sorba tegyünk-e, vagy a paramétereket egymás alá. Itt nem használok túl éles szabályt: ha úgy látom, hogy a felsorolás jól áttekinthető egy sorban is (pl. 2-3 elemből áll), akkor ezzel tömörítem a kódot. De ha áttekinthetetlenné válik (pl. 10 elemű lista), akkor egymás alá írom, mégpedig úgy, hogy mindegyik elem pontosan ugyanazon a behúzáson legyen, és előtte csak szóközök legyenek. (Egyes kódgenerátorok pl. az első paramétert rögtön a nyitó zárójel után teszik; ha a többi paraméter is új sorban van, akkor az első is kerüljön új sorba.)
  • Elnevezések
    • Minden név legyen informatív! Kerüljük az olyan változóneveket, hogy a, b vagy l1 (egybetűs változóneveket kizárólag ciklusváltozóként használjunk: i, j és max. {k}}). Az olyan egybetűs változóneveket különösen kerüljük, amelyek összetéveszthetőek valamilyen számmal, pl O, l vagy I. Nyugodtan használhatunk hosszú, több szóból álló megnevezéseket, a kezdeti programozási nyelvek korlátai már rég nem érvényesek. Személy szerint én különösen hosszú neveket szoktam adni a változóknak, függvényeknek, hogy messziről "sikítson", miről van szó.
    • Szófajok: az osztálynév legyen főnév, a függvénynév ige, a változónév főnév, a csomagnév adott része főnév (ez ne legyen összetett szó).
    • Ne tegyünk bele felesleges információt a változónévbe, pl. ami a típusára vonatkozik, vagy felesleges prefixeket.
    • Legyen a név kiejthető! Amikor valaki olvassa a kódot, akkor magában úgymond "felolvassa"; ügyeljünk arra, hogy ezt meg tudja tenni.
    • Az egyes nevek jelentősen különbözzenek egymástól! Ügyeljünk arra, hogy ne hozzunk létre hosszú neveket úgy, hogy csak 1-2 karakterben térnek el egymástól. Ránézésre legyen egyértelmű, hogy mire vonatkozik.
    • Gondoljunk arra, hogy ha rákeresnénk később valamire, akkor mire keresnénk rá. A megnevezések legyenek kereshetőek. Így a gépelési hibákra is ügyeljünk!
  • Függvények
    • Egy függvény legyen rövid! Ez számomra olyan, hogy jó, ha rövid, de nem mindenáron. Mert ha van egy mondjuk 200 soros függvény, ami egy jól meghatározott feladatot csinál, azt nyilván szét lehetne szabdalni sok pár soros függvénybe, de azokat szét kellene szabdalni több osztályba, mert az se jó, ha túl sok függvény van egy osztályban, ahhoz már külön csomagot kell létrehozni, és 2-3 ilyen függvény átszervezésének egy közép program érzetű lesz az eredménye. Tehát számomra ideális esetben egy függvény nem több 10 sornál, de számomra ez nem szigorú szabály.
    • Egy függvény egyetlen dolgot csináljon! Persze az, hogy mi számít egyelten dolognak, már a programozóra van bízva. Számomra belefér az, hogy felépíti az adatkapcsolatot, elküldi az adatot és lebontja az adatkapcsolatot, feltéve, hogy mindez csak itt történik.
    • Egy függvénynek ne legyenek mellékhatásai! Persze elkerülhetetlen, hogy egyetlen függvénynek se legyen mellékhatása, mert pl. egy adatbázisba írás is mellékhatás, de azok legyen elkülönítve. A legtöbb függvény úgy épüljön fel, hogy lehessen egységtesztelni.
    • Egy függvénynek ne legyen túl sok paramétere. Általában a 3 vagy több paramétert nem szokták szeretni; számomra ez olyan, hogy lehetőleg ne legyen sok paramétere. De kivételes esetek lehetségesek.
    • Az elnevezések legyenek informatívak! Itt elsősorban a függvénynévre és a paraméterek neveire gondolok, de a típus is fontos lehet. Arra is gondolni kell, hogy a hívó oldalon jól olvasható legyen a kód. Gondoljunk csak bele, hogy egy kód átnézése során ezt találjuk: x = f(1, true, null); fogalmunk sincs, hogy ez micsoda! Pl. a paraméter valamilyen szám vagy logikai helyett lehet felsorolás típusú.
    • A függvénynek ne kelljen a hibás (pl. null) értékekkel foglalkoznia! Ha egy paraméter egy értéket nem vehet fel, és mégis azt kapja, akkor az a hívó és nem a hívott hibája legyen, a hívó oldalon javítsuk!
    • A visszatérési érték mindig a fő sikeres forgatókönyv eredménye legyen, és sohasem valamilyen hibakód. Az egy rossz gyakorlat, hogy a visszatérési érték a lefutás sikerességét jelzi, és a tényleges eredmény mellékhatásként jelenik meg egy globális változóban. Ha hiba lép fel, akkor arra használjuk a kivételkezelést!
    • Kivételkezelés: mindig olyan kivételt kapjunk el, amit egy meghívott függvény dob, és nem mi magunk, valamint csak olyat, amivel tudunk is mit kezdeni. Amivel nem tudunk érdemben mit kezdeni, azt dobjuk automatikusan tovább. Létezhet egy olyan céges szabály, hogy a külső vagy rendszer kivételeket be kell csomagolni egy saját, projekt specifikus kivételbe. Ezzel én nem értek egyet, de ha a projekt úgy kívánja, betartom.
    • Ne legyenek a kódban elérhetetlen függvények, ill. függvényen belül elérhetetlen programsorok, azokat töröljük ki.
  • Osztályok
    • Egy osztály egyetlen témára fókuszáljon! Ha oda nem illő függvények vannak (pl. string feldolgozás az adatbázis kapcsolatért felelős osztályon belül), akkor nehéz megtalálni.
    • Legyen erős a kohézió! Ez gyakran (de nem féltétlenül csak) abban nyilvánul meg, hogy a függvények egymást hívogatják, sok függvény hivatkozik ugyanarra az osztály változóra. Ha egy osztályban több, egymástól független rész van, akkor megfontolandó az, hogy külön válasszuk őket.
    • Legyen gyenge a kötés az osztályok között! Ha túls ok kapcsolat van két osztály között, ráadásul kétirányú a kapcsolat, akkor megfontolandó a két osztály valamilyen értelembe vett összevonása.
  • Megjegyzések: ezek a kódnak azon részei, amelyek csak az embernek szólnak, a gép figyelmen kívül hagyja. (Majdnem mindig.) A programozási nyelvek dönt többségében lehet megjegyzést írni. A klasszikus iskola azt mondta, hogy nem tudunk túl sok megjegyzést írni, írjunk amennyit csak akarunk, még az is kevés lesz. A Clean Code mást állít, és ezt maximálisan osztom.
    • A megjegyzés rossz! Próbáljuk meg úgy megírni a kódot, hogy egyáltalán ne kelljen megjegyzést fűznünk hozzá.
    • Persze vannak kivételek. Az egyik eset, amikor mindenképpen megengedett a megjegyzés, az a publikus elemek Javadoc jellegű kommentelése: ebből generálódik ugyanis a dokumentáció. Viszont azokat a komponenseket felesleges Javadoc megjegyzésekkel ellátni, amelyekről nem szeretnénk dokumentációt generálni. A másik, ami szerintem megengedett az az, amikor egy tényleg nem nyilvánvaló kódrészletet szeretnénk magyarázni. Pl. egy első ránézésre logikátlan, ugyanakkor fontos megoldás magyarázata. Vagy ha egy függvény, osztály nem nyilvánvaló, hogy pontosan mit csinál.
    • Ne soroljuk fel a verziótörténetet! Régebben gyakorlat volt az, hogy a programforrás elején felsoroltuk a változásokat; hogy ki mikor mit adott hozzá. Erre ott van a verziókövető, a forráskódba ne tegyünk ilyesmit.
    • Sok esetben egy hosszú copyright szöveggel indul a kód, amit én teljesen feleslegesnek gondolok, úgyse olvassa el senki.
    • Ne maradjon a forrásban kikommentezett kód! Bátran töröljük ki, az megmarad a verziókövetőben.
  • Elrendezés: arról szól, hogy milyen legyen a kódkép.
    • Alapvetően szeretem a tömör kódot, melyben minél kevesebb a felesleges dolog. Az elnevezések jó hosszúak, így többnyire megjegyzés sem kell.
    • Vízszintes elrendezés: az, hogy milyen széles a kódsor, számomra attól függ, miről szól az a sor. A maximális sorszélesség kérdésről már volt szó, magamtól az ott leírtakat alkalmazom.
    • Függőleges elrendezés: a pár soros függvényt üres sor nélkül készítem, de ha hosszabb a függvény, akkor üres sorokat hagyok a nagyobb logikai egységek között. Két függvény között mindig hagyok egy üres sort. Ha létezik a függvényeknek logikai csoportosításuk, akkor a csoportok között kettőt is. Általában nem szeretem a rövid megjegyzéseket a függvények előtt, mert többnyire nem túl informatívak, viszont rontják az összképet. Az osztály attribútumait általában üres sorok nélkül szoktam felsorolni de ha több logikai egységbe lehet őket sorolni, akkor hagyok egy üres sort a logikai egységek között.
  • Egység teszt: miket vegyünk figyelembe a unit tesztek írásakor?
    • Lefedettség: a kód minél nagyobb területét fedjük le, akor triviális egységtesztekkel.
    • Egy unit teszt felépítése: egy logikai tesztelést hajt végre. Ez persze nem minden esetben jelenti azt, hogy pontosan egy assert hívás van. Jól elkülönül a felépítés, a teszt végrehajtása és az eredmény kiértékelése.
    • F.I.R.S.T: Fast (gyors), Independent (független), Repeatable (ismételhető), Self-validating (önértékelő; ez azt jelenti, hogy az eredménye egyértelműen igaz vagy hamis); Timely (az elkészítés időpontjára vonatkozik: az üzleti logika megvalósítása előtt hozzuk létre az egységtesztet).

Az is egy jó kérdés, és ide tartozik, hogy az integrált fejlesztőeszközök általában nyújtanak automatikus kódformázást, ami beállítható. (Meglepő egyébként, hogy az alapértelmezett formázási stílus nemigazán szép; a legegyszerűbb az lenne, ha mondjuk az Eclipse és az IntelliJ IDEA közösen tökéletesre csiszolná az alapértelmezettet, és mindenki azt használná.) Ennek a kötelezővé tétele viszont nem jó szerintem, melynek több oka is van:

  • Lelassítja a fejlesztő környezet beállítást. Ill. mivel nincs semmilyen mechanizmus, ami ezt kikényszerítené, óhatatlanul előfordul, hogy valaki elfelejti.
  • Mindig vannak "renitens" fejlesztők, akik nem a megszokott eszközöket használják. Hiába van egy tökéletesre csiszolt Eclipse szabályhalmaz, ha valaki NetBeans-t használ.
  • Nagyobb rendszereknél a generált kód kikerülhetetlen. Ez esetben viszont jó kérdés, hogy a generáltat használjuk-e, vagy a fejlesztőkörnyezet által átformázottat. És az szinte törvényszerű, hogy valakinél el fog csúszni.

Valójában érdemes megegyezni a szabályokban, de a túl szigorú átverés a rendszeren kontraproduktív.

A szoftverminőséget elősegítő eszközök

A SonarQube a legnépszerűbb olyan eszköz, amely statikus kódelemzést végrehajtva hívja fel a figyelmet a kódolási szabálysértésekre. A használata kissé nehézkes. A telepítéshez hajtsuk végre az alábbi lépéseket:

  • Töltsük le a programot innen: https://www.sonarqube.org/downloads/, majd csomagoljuk ki.
  • Indítsuk el a bin\windows-x86-64\StartSonar.bat fájlt.
  • Nyissuk meg a http://localhost:9000 oldalt és lépjünk be admin felhasználónévvel és admin jelszóval.
  • Hozzunk létre egy új projektet (ezt a későbbiekben a jobb felső sarokban található + ikonra kattintva tehetjük meg)
  • A létrehozáskor felajánlja, hogy generáljunk egy tokent, ezt tegyük meg. Ezt meg kell adni a Maven-nek paraméterül, ahogyan azt a rendszer kiírja, pl. nálam:
mvn sonar:sonar -Dsonar.projectKey=adder -Dsonar.host.url=http://localhost:9000 -Dsonar.login=fdd56032c9d74a8c2a626c78df39be853521bccb
  • Az eredmény automatikusan megjelenik a fenti oldalon: mindenféle statisztikák, valamint a kódolási szabálysértések.

Alapértelmezésben - ahogy erre figyelmeztet is - egy beépített adatbázisba menti az adatokat. Produkciós környezetben ezt célszerű lecserélni egy másikra. Számos programozási nyelvet támogat, a Java támogatása a legszéleskörűbb. Alapértelmezésben egész sok szabály található benne, bár a súlyosság megállapítása sokszor igen furcsa. Kétségkívül óriási előnye viszont a kiterjeszthetőség: számos kiegészítő létezik hozzá, pl. ez: https://www.sourcemeter.com/.

Code review

Az egyik legjobb módszer a kódminőség megfelelő szinten tartására a kód review. Ez nemcsak amiatt hasznos, mert "több szem többet lát", hanem mert ha a fejlesztő azzal a tudattal fejleszt, hogy a végén nemcsak funkcionálisan kell megfelelően működnie, hanem a kód minőségét is meg kell védenie, akkor ösztönösen igyekszik jobb kódot készíteni.

A kód review-t is számos eszköz segíti, nekem a Crucible-lel, valamint az azt támogató FishEye-jal van némi tapasztalatom. De külön eszköz nélkül is tudunk kód review-t tartani.

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