Törekedj a már létező megoldások újrafelhasználására

Bevezetés

• Az újrafelhasználás előnyei a szoftverfejlesztésben

Az újrafelhasználás az általános fejlesztési módszertan egy fontos eleme, amely előnyöket nyújt az idő, a költség, a minőség és a fejlesztői produktivitás terén. Az újrafelhasználhatóság (code reuse) rendkívül fontos és előnyös a szoftverfejlesztésben, több szempontból is:

Hatékonyság és időmegtakarítás: Az újrafelhasználás lehetővé teszi, hogy már meglévő, jól tesztelt és bevált kódot újra felhasználjunk más projektekben. Ez csökkenti az ismétlődő munkát és időt takarít meg, mivel nem kell mindig újra megírni vagy újratervezni a már meglévő funkciókat vagy komponenseket.

Konzisztencia és megbízhatóság: Az újrafelhasználható kód általában jól tesztelt, és azáltal, hogy ugyanazt a kódot többször használjuk, elősegítjük a hibák felderítését és javítását. Ezáltal a kód megbízhatóbbá válik, és a fejlesztők könnyebben megőrizhetik a konzisztenciát a különböző projektekben.

Karbantarthatóság: Az újrafelhasználható kód jobban karbantartható, mivel a változtatásokat csak egy helyen kell elvégezni, és a változtatások az összes helyen automatikusan érvénybe lépnek, ahol az adott kódot használják. Ez egyszerűsíti a hibajavítást, a fejlesztéseket és a frissítéseket, és minimalizálja a mellékhatásokat.

Rugalmasság és skálázhatóság: Az újrafelhasználható kód rugalmasságot és skálázhatóságot biztosít. Azáltal, hogy jól elkülönített komponenseket vagy modulokat használunk, könnyebben lehet fejleszteni és bővíteni a rendszert. Új funkciókat adhatunk hozzá vagy meglévőket módosíthatunk anélkül, hogy a teljes kódbázist érintenénk.

Közösségi együttműködés: Az újrafelhasználás elősegíti a közösségi együttműködést a szoftverfejlesztésben. Nyílt forráskódú projektekben vagy fejlesztői közösségekben az újrafelhasználható komponensek és könyvtárak közzététele más fejlesztők számára lehetővé teszi azok használatát, javítását és fejlesztését. Ez hozzájárul a tudás és az innováció megosztásához.

Azonban fontos megjegyezni, hogy az újrafelhasználásnak megfelelő tervezésre és dokumentációra van szüksége, valamint figyelembe kell venni a specifikus projektek és igények egyedi kihívásait és korlátait.

Fogalmak, definíciók

• Az újrafelhasználás fogalma

Az újrafelhasználás (code reuse) fogalma a szoftverfejlesztésben azt jelenti, hogy meglévő kódot, komponenseket vagy modulokat használunk fel újra más alkalmazások vagy rendszerek fejlesztése során. Az újrafelhasználás célja a fejlesztés hatékonyságának és minőségének javítása, valamint a felesleges kódismétlés elkerülése.

• Nyílt szabvány fogalma

A nyílt szabvány (open standard) fogalma a szoftverfejlesztésben egy olyan technikai specifikációt jelent, amely nyilvánosan hozzáférhető, szabadon használható és bármely fejlesztő vagy szervezet által implementálható. A nyílt szabványok célja a szabványosított kommunikáció és adatátvitel biztosítása különböző rendszerek, alkalmazások és eszközök között.

• Nyílt forráskód

A nyílt forráskód (open source) fogalma a szoftverfejlesztésben egy olyan megközelítést jelent, amelyben a szoftver forráskódja nyilvánosan hozzáférhető és szabadon felhasználható, megtekinthető, módosítható és terjeszthető. Ez azt jelenti, hogy a fejlesztők szabadon hozzáférhetnek és módosíthatják a szoftver forráskódját, és hozzájárulhatnak a projekt fejlesztéséhez.

• Nyílt komponens

A "nyílt komponens" fogalma a szoftverfejlesztésben egy olyan komponenst jelent, amely nyílt forráskódú és nyilvánosan hozzáférhető a fejlesztők és a felhasználók számára. Ez a komponens lehet egy szoftverkönyvtár, keretrendszer, modul, kódfragmentum vagy bármilyen újrafelhasználható egység, amelyet más fejlesztők be tudnak illeszteni a saját alkalmazásaikba vagy rendszereikbe.

• API

Az API (Application Programming Interface) egy olyan interfész vagy programozási felület, amely lehetővé teszi két vagy több szoftverkomponens kommunikációját és adatcseréjét. Az API meghatározza, hogy hogyan kell az alkalmazásoknak vagy szoftverkomponenseknek kommunikálniuk egymással, milyen adatokat lehet lekérni vagy módosítani, és milyen műveleteket lehet végrehajtani.

Az API lehetővé teszi, hogy egy alkalmazás más alkalmazásokkal vagy szolgáltatásokkal kommunikáljon, anélkül, hogy a belső működését vagy implementációját részleteiben ismerné. Az API-k egyszerű, jól dokumentált interfészeket biztosítanak, amelyek definiálják a kérési és válaszüzenetek formátumát, az elérhető műveleteket és az adatok struktúráját.

Az API-k lehetnek webes API-k (HTTP alapú), adatbázis API-k, könyvtári API-k és még számos más típus is. Az API-k széles körben használatosak a szoftverfejlesztésben, mivel lehetővé teszik a különböző alkalmazások, rendszerek vagy platformok közötti integrációt és adatcserét.

Nyílt forráskód

• Egy kis történelem

Az 1950-es években, a számítógépek kezdeti időszakában a szoftverek általában szabadon elérhetők és megoszthatók voltak. A programok forráskódja könnyen hozzáférhető volt, és a fejlesztők egymás között megosztották azokat. Az 1960-as években azonban kezdtek elterjedni a szoftverlicencelési gyakorlatok, amelyek korlátozták a szoftverek felhasználását és terjesztését. Ez a zárt forráskódú szoftverek korszakának kezdete volt.

Az 1980-as évek végén, az 1990-es évek elején a szabadalmazott szoftver volt a legelterjedtebb, forráskódját zárva tartották. Ez egészen addig tartott, amíg Richard Stallman egy alternatív vízióval nem állt elő: ingyenes és nyílt hozzáférést a világ legfontosabb technológiai eszközeihez! 1983-ban megalapította a The Free Software Foundation-t (FSF), amely elindította a GNU Projectet.

A GNU (GNU's Not Unix) projekt egy ambiciózus és jelentős nyílt forráskódú kezdeményezés. Célja egy teljesen szabad operációs rendszer létrehozása volt, amely lehetővé teszi a felhasználók számára a szoftverek szabad használatát és megosztását. A GNU projekt egyike volt az első olyan kezdeményezéseknek, amelyek kiemelten foglalkoztak a szabad szoftverek filozófiájával és jogi kérdéseivel. A GNU projekt része az általa létrehozott GNU General Public License (GPL) licenc, amely biztosítja a szoftverek szabadságát és lehetőséget nyújt a felhasználóknak a szoftverek módosítására és terjesztésére.

Stallman úgy gondolta, hogy a szoftvernek elérhetőnek kell lennie a programozók számára, hogy azt saját belátásuk szerint módosíthassák a jobb fejlesztés érdekében. Megérteni, megismerni és javítani. Bár a GNU operációs rendszer soha nem készült el teljesen, a projekt jelentős hatást gyakorolt a szoftverfejlesztési közösségre és az open source mozgalomra. A GNU projekt hozzájárult a szabad szoftverek elterjedéséhez, az újrafelhasználható komponensek és eszközök fejlesztéséhez, valamint az etikai és jogi kérdések kiemeléséhez a szoftverfejlesztés területén. Ez jelentette a nyílt forráskód történetének kezdetét.

Ahogy egyre több nyílt forráskódú szoftver jelent meg, különböző alapítványok és közösségek kezdtek kialakulni körülötte. A mai napig ezek a nonprofit szervezetek a fejlesztők hozzájárulásának ösztönzésével, a közösségi események támogatásával, az nyílt forráskódú szoftverek kódbázisainak naprakészen tartásával és új verziók kiadásával járultak hozzá a nyílt forráskód fejlődéséhez.

Azóta nehéz elképzelni a világot nyílt forráskód nélkül. A nyílt forráskód mindenütt jelen van.

Íme néhány népszerű és elismert nyílt forráskódú szoftver, amelyek széles körben használnak és nagy közösségek által támogatottak:

Linux: A Linux operációs rendszer nyílt forráskódú kernel, amelyet számos disztribúció (pl. Ubuntu, Fedora, Debian) használ alapul. A Linux rendszer széles körben elterjedt mind az asztali, mind a szerver környezetben.

Apache: Az Apache HTTP szerver a világ legelterjedtebb webkiszolgáló szoftvere. Nyílt forráskódú, és megbízható webes szolgáltatásokat nyújt.

MySQL: A MySQL egy népszerű nyílt forráskódú relációs adatbázis-kezelő rendszer, amelyet széles körben használnak webalkalmazások és más adatbázis-alapú alkalmazások fejlesztésére.

PostgreSQL: A PostgreSQL egy további nyílt forráskódú relációs adatbázis-kezelő rendszer, amely erőteljes funkciókkal rendelkezik, mint például tranzakciókezelés, adatintegritás és lekérdezési rugalmasság.

Mozilla Firefox: A Mozilla Firefox egy nyílt forráskódú webböngésző, amely népszerű alternatíva a Chrome, Safari és más böngészőkkel szemben. Az alapítvány közösségi fejlesztéssel működteti a böngészőt.

WordPress: A WordPress egy nyílt forráskódú tartalomkezelő rendszer, amely lehetővé teszi weboldalak és blogok létrehozását és kezelését. Rugalmas és kiterjedt bővítményrendszerrel rendelkezik.

Git: A Git egy elosztott verziókezelő rendszer, amelyet szoftverfejlesztési projektekben használnak a forráskód követésére és verziókezelésére. A Git széles körben elterjedt és számos nyílt forráskódú projekt, például a Linux kernel is használja.

1. https://hashdork.com/hu/open-source/

2. https://www.codemotion.com/magazine/infographics/the-history-of-open-source/

3. https://www.nytimes.com/1998/03/20/news/qa-richard-stallman-why-software-should-be-free-and-shared.html

4. https://www.freecodecamp.org/news/brief-history-of-open-source/

• Nyílt forráskód használatának előnyei

A nyílt forráskód használatának számos előnye van a szoftverfejlesztés területén. Néhány fontos előnyét emelnénk most ki:

Az átvizsgálhatóság és a megbízhatóság

A nyílt forráskódú szoftverek forráskódja nyilvánosan hozzáférhető, így bárki átvizsgálhatja és ellenőrizheti a kód működését. Ez növeli a szoftver megbízhatóságát és biztonságát, mivel a hibák, sebezhetőségek és biztonsági rések könnyebben felfedezhetők és javíthatók.

A közösség ereje és támogatása

A nyílt forráskódú projektek általában aktív fejlesztői közösséggel rendelkeznek, amely segítséget, támogatást és dokumentációt nyújt a fejlesztőknek. Ez lehetővé teszi a tudásmegosztást, a kérdések feltevését és a problémák megoldását a közösség segítségével.

Rugalmasság és testreszabhatóság

A nyílt forráskódú szoftverek lehetővé teszik a felhasználók számára, hogy módosítsák és testreszabják a szoftvert a saját igényeikhez és előnyeikhez. A nyílt forráskódú projektekben általában rugalmasan módosítható és bővíthető a kód, így az alkalmazások könnyen illeszthetők az adott környezethez vagy üzleti igényekhez.

Költségcsökkentés

A nyílt forráskódú szoftverek általában ingyenesen elérhetők és felhasználhatók, így csökkenthetik a fejlesztési költségeket. A vállalatoknak és fejlesztőknek nem kell licencdíjat fizetni a szoftver használatáért, és kevesebb erőforrást kell fordítaniuk a szoftverfejlesztésre.

Az újrafelhasználás lehetősége

A nyílt forráskódú szoftverek nagyszerű lehetőséget kínálnak az újrafelhasználásra. A fejlesztők szabadon felhasználhatják és beilleszthetik a nyílt forráskódú komponenseket és könyvtárakat a saját alkalmazásaikba, így időt és erőforrásokat takaríthatnak meg.

Innováció és fejlődés

A nyílt forráskódú szoftverek jelentősen hozzájárulnak az innovációhoz és a fejlődéshez a szoftverfejlesztés területén a kreatív közösségi együttműködés által. A kreatív közösségi együttműködés lehetővé teszi az ötletek és tapasztalatok megosztását, ami elősegíti az innovációt.

• Nyílt forráskód használatának hátrányai, kockázatai

Bár a nyílt forráskód használatának számos előnye van, fontos megérteni, hogy van néhány hátránya is.

Közösségi felépítésének és nagyrészt szabályozatlan terjesztésének köszönhetően a nyílt forráskódú szoftverek használata számos kockázattal jár, köztük kiberbiztonsági kockázattal is.

Biztonsági hiányosság

A nyílt forráskódú szoftverek nem járnak jogi kötelezettségekkel, az IT biztonsági igények nem feltétlenül vannak megfelelően megfogalmazva, valamint gyakran hiányozhat a közösségi támogatás, amely segítene a biztonságos implementációban. A szoftver létrehozásáért felelős fejlesztők gyakran nem biztonsági szakértők, és nem feltétlenül értik, hogyan kell a legjobb gyakorlatokat megvalósítani.

Szellemi tulajdonjogi ügyek

Több mint 200 típusú licenc létezik, amelyet nyílt forráskódú szoftverekre lehet alkalmazni, például az Apache, GPL és MIT. Ezek közül sok licenc nem kompatibilis egymással, tehát bizonyos komponensek nem használhatók együtt, mivel minden licencfeltételt be kell tartani a nyílt forráskódú szoftver használatakor. Minél több komponenst használsz, annál nehezebb nyomon követni és összehasonlítani az összes licenc előírását.

Garancia, támogatás hiánya

A nyílt forráskódú szoftverek nem járnak semmilyen garanciával a biztonságuk, támogatásuk vagy tartalmuk tekintetében. Míg a közösség általában segítséget és támogatást nyújt, nem garantált, hogy minden kérdésre vagy problémára választ kapunk, és a fejlesztői közösség is korlátozott erőforrásokkal rendelkezik. Bár sok projektet támogatnak, ezeket általában önkéntesek végzik, és fejlesztésük értesítés nélkül meg is szűnhet.

Mivel a nyílt forráskódú szoftvereket a közösségen belül névtelenül hozzák létre, ezért nehéz ellenőrizni, hogy a beküldött kód eredeti vagy nem harmadik féltől származik-e, amely szellemi tulajdonjogokkal rendelkezik. Ez a gyakorlatban azt jelenti, hogy ha olyan nyílt forráskódú szoftvert használunk, amelyről kiderül, hogy jogsértő kódot tartalmaz, akkor felelősségre vonhatóak leszünk.

Ellenőrzés hiánya

Gyakran előfordul, hogy a csapatoknak egyáltalán nincs folyamatuk az általuk használt nyílt forráskódú komponensek felülvizsgálatára vagy a folyamat, amit alkalmaznak, nem megfelelő. Ugyanannak az összetevőnek több verzióját is használhatják különböző csapatok, vagy a fejlesztők esetlegesen nem tudnak az ütköző funkciókról vagy licencekről.

Ezek a problémák azért fordulhatnak elő, mert hiányzik a szoftver vagy a biztonsági funkcionalitás ismerete, illetve a csapatok vagy csapattagok közötti kommunikáció, illetve a nyomon követést és dokumentációt szolgáló protokollok elégtelenek vagy hiányoznak.

Ellentétben a harmadik féltől származó jogvédett szoftverekkel, amelyek beépített vezérlőkkel megakadályozzák a többszörös vagy nem kompatibilis verziók használatát, a nyílt forráskódú összetevők általában a felhasználóra támaszkodnak a megfelelő használat ellenőrzésekor.

Működési hiányosságok

A nyílt forráskódú komponensek használata sok többletmunkát jelenthet az amúgy is időhiányban szenvedő csapatoknak, és gyakran nem világos, hogy ki a felelős ezért a munkáért. Nyomon kell követnie, hogy milyen összetevőket használnak, milyen verziószámmal, hol használják őket, és hogyan léphetnek kapcsolatba más használatban lévő összetevőkkel.

Ezen túlmenően össze kell hasonlítani a licenceket, és figyelni kell a frissítéseket és javításokat, amint azok elérhetővé válnak, beleértve azt is, hogy milyen hatással lehetnek a funkcionalitásra. Ha a felhasznált komponensek szükségtelen funkcionalitást tartalmaznak, azok haszontalanul összetettebbé tehetik a rendszert.

Rossz fejlesztői gyakorlatok

A fejlesztők akaratlanul is növelhetik a kockázatokat, ha a nyílt forráskódú szoftverekből kódrészleteket másolnak be, ahelyett, hogy teljes összetevőket integrálnának. Ezzel lehetetlenné teszik a kód nyomon követését engedélyezési vagy biztonsági szempontból.

A nyílt forráskódú szoftverek által jelentett kockázatok ismerete – a fejlesztési folyamatba való belépés – segít elkerülni a forráskód tömeges megosztásával kapcsolatos buktatókat.

A kockázatok figyelembevételével és a védelmi stratégiák megvalósításával, a rendszereink biztonságához szükséges egyéb intézkedések mellett hozzájárulhatunk a nyílt forráskódú szoftverek biztonságos használatához.

Nyílt szabványok

• Nyílt szabványok céljai

Ha tehetjük, alkalmazzunk nyílt szabványokat a szolgáltatás tervezése és kiépítése során és csak abban az esetben javasoljuk új szabvány bevezetését, ha nincsen olyan, amely megfelelne az igényeknek.

A nyílt szabványok használata azt jelenti, hogy:

• mindenki számára hozzáférhető,
• könnyebben megoszthatjuk az adatokat a szolgáltatások és rendszerek között,
• elkerülhetjük a szállítói és gyártói függőséget,
• a mások által készített szoftverkomponenseket újra felhasználhatjuk, beleértve a nyílt forráskódú összetevőket is,
• csökkenthetjük a digitális szolgáltatás költségét,
• közösségi együttműködés jöhet létre, amely során megoszthatjuk egymással tapasztalatainkat, javaslatainkat.

Ezen előnyök miatt a nyílt szabványok használata egyre elterjedtebb a szoftverfejlesztésben, és segíti az interoperabilitást, az innovációt és a fenntarthatóságot a technológiai iparágban.

• Mi az RFC?

Az RFC (Request For Comments) egy olyan dokumentum, melyet egy új Internet-szabvány beiktatásakor adnak közre. Az RFC dokumentumok műszaki specifikációkat és szervezeti megjegyzéseket tartalmaznak, amelyeket egy szabványosító szervezet, az Internet Engineering Task Force (IETF) ad ki. A sorozat első dokumentumát, az RFC 1-et 1969-ben írták. Hamarosan következett a többi, köztük azok, amelyek leírják az Interneten ma is használatos IP-protokollt. Ma már több mint 9000 egyedileg számozott dokumentum található a sorozatban.

Az IETF által készített RFC-k a számítógépes hálózatok számos vonatkozását lefedik. Leírják az internet technikai alapjait, mint például a címzési, útválasztási és szállítási technológiákat. Az RFC-k olyan protokollokat is meghatároznak, amelyeket emberek milliárdjai által naponta használt szolgáltatások biztosítására használnak, mint például a valós idejű együttműködés, az e-mail és a domain-név rendszer.

Az RFC-k általában internetes piszkozatokként (I-D) kezdődnek, amelyeket egy egyén vagy egy kis csoport ír. Az IETF-ben ezeket általában egy munkacsoport fogadja el, javítja és felülvizsgálja. Bár nem minden I-D válik RFC-vé, jól meghatározott folyamatok (amelyek az RFC-kben is dokumentálva vannak) irányítják a dokumentum mérlegelését és előrehaladását. Közzétételükkor az RFC-k szabadon elérhetők az interneten.

A szoftverfejlesztők, hardvergyártók és hálózatüzemeltetők szerte a világon önkéntesen alkalmazzák az RFC-k által leírt műszaki előírásokat, mint szabványokat.

• Fontosabb RFC-k:

RFC 765: File Transfer Protocol (Ftp)

RFC 768: User Datagram Protocol (UDP)

RFC 791: Internet Protocol (IP)

RFC 792: Internet Control Message Protocol (ICMP)

RFC 793: Transmission Control Protocol (TCP)

RFC 822: Fejléc-, dátum- és időformátumok

RFC 826: Address Resolution Protocol (ARP)

RFC 903: Reverse Address Resolution Protocol (RARP)

RFC 1034 és RFC 1035: Domain Name System (DNS)

RFC 1766, RFC 3066: Tags for the Identification of Languages,

RFC 4646, RFC 5646: Tags for Identifying Languages

RFC 4647: Matching of Language Tags

RFC 1939: Post Office Protocol (POP3)

RFC 2068: Hypertext Transfer Protocol (HTTP 1.1)

RFC 2821: Simple Mail Transfer Protocol (SMTP)

Forrás:

https://hu.wikipedia.org/wiki/RFC

https://www.ietf.org/standards/rfcs/

• SZEÜSZ/KEÜSZ

A szabályozott elektronikus ügyintézési szolgáltatások (SZEÜSZ-ök) koncepcionális megalapozását a 2015. évi E-ügyintézési törvényben találhatjuk meg. A törvény 2016-ban megjelent végrehajtási rendelete (VHR) szabályozza részleteiben az egyes SZEÜSZ-ök tartalmát, szolgáltatási funkcióit. A szabályozott szolgáltatás azt jelenti, hogy a szolgáltatások jellemzőit, feltételeit az állam jogszabályokban meghatározza, adott jellegű szolgáltatást csak ilyen paraméterek teljesítésével lehet nyújtani. A SZEÜSZ-ök egy része kormány által kötelezően biztosított szolgáltatás (pl. elektronikus azonosítás). A SZEÜSZ-öket a jogszabályok által definiált feltételek mentén piaci alapon bárki nyújthatja (kivéve az előzőekben említett kormány által kötelezően nyújtandó szolgáltatásokat), azonban a jogszabályban definiált SZEÜSZ-öket a kormány külön jogszabályban kijelölt központi szolgáltatón keresztül biztosítja. Az ilyen szolgáltatások az ún. központi elektronikus ügyintézési szolgáltatások (KEÜSZ-ök).

A projektek végrehajtása során kiemelkedő fontosságot kap a meglévő és fejlesztés alatt álló közigazgatási sztenderdek és szabványok használata. Ennek célja, hogy technológiai szempontból is biztosítsuk az egységes szolgáltatásokat és az azonos minőséget az ügyfelek számára. Továbbá megteremti annak előfeltételét, hogy ezeket a szolgáltatásokat a rendelkezésre álló erőforrások hatékony kihasználásával lehessen bevezetni.

Mire figyeljünk az újrafelhasználás során

Értsük meg a kód működését!

Az újrafelhasználás során gyakran előfordul, hogy a kód vagy a komponens eredeti funkcióját vagy működését nem értik meg teljesen. Ez vezethet hibákhoz és váratlan viselkedéshez.

Mielőtt felhasználunk egy kódot vagy komponenst, javasolt dokumentáció, kommentek és a forráskód alapos tanulmányozása.

Ügyeljünk a laza kapcsolatokra!

Előfordulhat az is, hogy túl szorosan kapcsolódunk a meglévő kódhoz vagy komponensekhez. Ez megnehezítheti a további fejlesztést, korlátozhatja a rugalmasságot és skálázhatóságot.

Ebben az esetben is ajánlott a kód alapos vizsgálata és kiválasztása, valamint az újrafelhasználás során az általánosságra és a moduláris tervezésre összpontosítani.

Figyeljünk a biztonságra!

Ha a kód hibákat tartalmaz, akkor nem lehet megbízható, biztonságos. Csak olyan kódot javasolt újrahasználni, amely nem tartalmaz hibákat.

A meglévő kód vagy komponensek frissítése és biztonsági ellenőrzése fontos lépés az újrafelhasználás során. Ajánlott alkalmazni a bevált biztonsági gyakorlatokat és vizsgálni a sérülékenységet.

Ne hagyjuk ki a tesztelést!

Az újrafelhasznált kód vagy komponensek megfelelő tesztelése elengedhetetlen. Hiányzó vagy nem megfelelő tesztelés hibás működéshez, inkompatibilitáshoz vagy megbízhatósági problémákhoz vezethet. Javasolt a teljeskörű egységtesztelés, integrációs tesztek és rendszeres ellenőrzések végrehajtása az újrafelhasznált kódra.

Minden projekt és helyzet egyedi lehet, ezért a fenti javaslatokat az adott körülményekhez és követelményekhez szükséges igazítani.

Újrafelhasználhatóság tervezése

Az újrafelhasználás során lehetőség van teljes alkalmazások, vagy csak bizonyos modulok újrafelhasználására is, attól függően, hogy milyen szintű újrafelhasználást szeretnénk elérni, és hogy milyen mértékben illeszkedik az adott alkalmazás vagy modul más projektekbe vagy rendszerekbe.

A teljes alkalmazás újrafelhasználása akkor nyerhet értelmet, ha az alkalmazás egésze komplex funkcionalitást vagy üzleti logikát tartalmaz, amely más projektekben vagy rendszerekben is hasznos lehet. Az alkalmazás újrafelhasználása lehetőséget ad az erőforrások és a fejlesztési idő megtakarítására, mivel az elkészült alkalmazást újra felhasználhatjuk más projektekben anélkül, hogy újra kellene fejlesztenünk az egészet.

Az egyes modulok vagy komponensek újrafelhasználása viszont arra összpontosít, hogy a fejlesztők különálló részeket, funkciókat vagy komponenseket hozzanak létre, amelyeket más alkalmazásokba vagy rendszerekbe beépíthetnek. Ez lehetővé teszi az egyszerűsített, újrafelhasználható építőkövek készítését, amelyeket külön-külön lehet kombinálni vagy testreszabni más projektekhez vagy rendszerekhez.

Mindkét megközelítésnek vannak előnyei és alkalmazási területei. A teljes alkalmazás újrafelhasználása nagyobb mértékű újrafelhasználást és gyorsabb fejlesztési ciklusokat eredményezhet, míg a moduláris újrafelhasználás lehetővé teszi a funkcionalitás kiválasztását és testreszabását, valamint a könnyebb karbantarthatóságot és bővíthetőséget.

• A LIBRA Alkalmazás-katalógus szerepe az újrafelhasználás során

Az állami érdekű alkalmazások komplett újrafelhasználására már most is lehetőséget biztosít az egységes Állami Alkalmazás-fejlesztési Környezetről és az Állami Alkalmazás-katalógusról, valamint az egyes kapcsolódó kormányrendeletek módosításáról szóló 314/2018. (XII. 27.) Korm. rendelet (a továbbiakban ÁAFK Kr.) szóló alapján létrehozott LIBRA Alkalmazás-katalógus.

A LIBRA Állami Alkalmazás-katalógus 2019 óta üzemel élesben. A LIBRA Alkalmazás-katalógus az állam működése, annak támogatása érdekében fejlesztett informatikai alkalmazások zárt, az alkalmazások funkcionális, szakmai, tartalmi és műszaki adatait tartalmazó, szabályozott adattartalmú nyilvántartására szolgáló elektronikus adatgyűjtő és adatszolgáltató rendszer.

A LIBRA Alkalmazás-katalógus a mindenkori állami szoftvervagyon aktuális állapotáról ad technológia, alkalmazás, szolgáltatás és életesemény szintű részletes képet, segítve a párhuzamos, indokolatlan állami fejlesztések megelőzését.

A LIBRA célja nem csupán egy pillanatfelvétel bemutatása a közigazgatási szoftverekről, alkalmazásokról, hanem folyamatosan naprakész információk biztosítása azok állapotáról, ezáltal támogatva az állami szervek fejlesztésekkel összefüggő stratégiai tervezési feladatait.

A működést támogató nyilvántartás létrehozása lehetővé teszi, hogy az állami érdekből – állami megrendelésre – fejlesztett alkalmazások köréről az állam és annak szervezetei mindenkor naprakész információkkal rendelkezzenek. Az igények kielégítésével a LIBRA Alkalmazás-katalógus a párhuzamos, indokolatlan állami fejlesztések megelőzését is szolgálja.

Segítségével naprakészek és könnyen kereshetők lesznek az állami tulajdonban lévő szoftvertermékek, funkciójuk és egyéb további szempontok alapján. Lehetővé válik az elkészült szoftverek kormányzati körben, korlátlan számban történő felhasználása, a későbbi szükség szerinti továbbfejlesztéseknek vagy módosításoknak a meglévő állami fejlesztői kapacitások felhasználásával történő megvalósítása.

Ennek eredményeképp az állam tulajdonosi szerepe tovább erősödik, és a közfeladatra szánt források takarékos felhasználása megvalósul. Az állam tulajdonában lévő informatikai infrastruktúrák optimális kihasználása és összehangolása azok hatékonyságát tovább növeli, illetve az állami fejlesztői kapacitások célirányos és saját érdekű felhasználása optimalizálódik.

Az állami célból fejlesztett alkalmazások rendszerezésével lehetőség nyílik az alkalmazás portfólió elemzésére, a fejlesztési erőforrások hatékonyabb felhasználására, a megoldások használatával kapcsolatban összegyűlt tapasztalat megismerésére. Ezzel támogatva az állami szervek, fejlesztésekkel összefüggő stratégiai tervezési feladataik megvalósulását. Új fejlesztés állami beszerzése ugyanis kizárólag abban az esetben válik lehetővé, ha a LIBRA Alkalmazás-katalógusban nem áll rendelkezésre azonos funkciójú vagy az újonnan felmerülő igényekhez könnyen adaptálható alkalmazás.

Használatával lehetővé válik az elkészült szoftverek kormányzati körben, korlátlan számban történő felhasználása, a későbbi szükség szerinti tökéletesítéseknek vagy átalakításoknak a meglévő állami fejlesztői kapacitások felhasználásával történő megvalósítása, mindehhez előnyben részesítve a nyílt forráskódú szoftvereket és technológiákat a teljes megvalósítási és a fenntartási, továbbfejlesztési időszak során.

Fenti célok megvalósításához nélkülözhetetlen a LIBRA Alkalmazás-katalógus működése és folyamatos karbantartása, optimalizálása. A katalógusnak és a benne naprakészen nyilvántartott adatoknak jelentős szerepe van az állami célú alkalmazás-fejlesztési erőforrásokkal való hatékony gazdálkodásban.

Forrás: https://aafk.gov.hu/libra/

• Komponens alapú tervezés alapelvei

A komponens alapú tervezés olyan tervezési megközelítés, amelyben a szoftver nagyobb egységekre, ún. komponensekre van felosztva, amelyek egymástól függetlenül működhetnek és újrafelhasználhatók más alkalmazásokban vagy rendszerekben.

A komponens alapú tervezés alapelvei a következők:

Függetlenség elve: A komponenseknek önállóan működő egységeknek kell lenniük, amelyek minimális vagy semmilyen függőséget nem mutatnak más komponensektől vagy külső rendszerektől. Ez lehetővé teszi, hogy a komponenseket könnyen el lehessen választani és újra lehessen használni más alkalmazásokban.

Interfész elve: A komponenseknek jól definiált interfészekkel kell rendelkezniük, amelyek meghatározzák a kommunikációt más komponensekkel. Az interfészeknek egyszerűeknek, stabilaknak és jól dokumentáltaknak kell lenniük, hogy a komponenseket könnyen össze lehessen illeszteni és cserélhetővé lehessen tenni őket.

Moduláris tervezés elve: A komponenseknek kohézióval és alacsony függőséggel rendelkező modulokra kell oszthatóknak lenniük. Ez azt jelenti, hogy a komponenseknek egyértelmű felelősségi körrel kell rendelkezniük, és minimálisnak kell lenniük a külső komponensektől való függőségek szempontjából.

Újrafelhasználhatóság elve: A komponenseknek újrafelhasználhatónak kell lenniük más alkalmazásokban vagy rendszerekben. Ez azt jelenti, hogy a komponenseket úgy kell tervezni, hogy könnyen beilleszthetők legyenek más kontextusokba és újra felhasználhatók legyenek más feladatok megoldására.

Ezek az alapelvek segítenek a komponens alapú tervezés hatékonyabbá és rugalmasabbá tételében, lehetővé téve a szoftverkomponensek újrafelhasználását és a fejlesztési folyamat gyorsabb és hatékonyabb megvalósítását.

Forrás:

Szyperski, C. (2002). Component Software: Beyond Object-Oriented Programming. Addison-Wesley Professional.

Bass, L., Clements, P., & Kazman, R. (2012). Software Architecture in Practice (3rd Edition). Addison-Wesley Professional.

Clements, P., Kazman, R., & Klein, M. (2010). Evaluating Software Architectures: Methods and Case Studies. Addison-Wesley Professional.

• API-k használata, építése

Egy nyilvános API segítségével lehetséges egy programrendszer szolgáltatásait használni anélkül, hogy annak belső működését ismerni kellene.

Az API-adatok és műszaki szabványok elősegítik a fejlesztési következetességet, időt spórolnak, növelik a hatékonyságot, csökkentik a költségeket és segítenek jobb digitális közszolgáltatásokat nyújtani.

https://www.gov.uk/service-manual/technology/application-programming-interfaces-apis

https://hu.wikipedia.org/wiki/Alkalmaz%C3%A1sprogramoz%C3%A1si_fel%C3%BClet

A fejlesztő csapat lehetőség szerint építhet is API-kat, ha nincs olyan, ami a projektjéhez alkalmas lehet. API-k építéséhez az alábbi általános lépéseket javasoljuk figyelembe venni:

Határozzuk meg a célokat és a felhasználókat!

Az API-stratégia megtervezése elengedhetetlen a hosszú távú sikerhez. Az API-nak értéket kell teremtenie mind a tervezett felhasználók, mind a szervezetek számára. A felhasználók igényeinek megértése segít meghatározni az API-követelményeket.

Határozzuk meg a követelményeket!

Határozzuk meg az API célját és funkcionalitását. Gondoljunk arra, hogy milyen adatokat szeretnénk elérhetővé tenni, milyen műveleteket kívánunk végrehajtani és milyen visszajelzéseket szeretnénk kapni az API-t használóktól. Kétféle követelményt érdemes figyelembe venni. A funkcionális követelmények határozzák meg, hogy az API mire lesz képes. Ezek azok az üzleti lehetőségek, amelyeket az API elérhetővé tesz a felhasználók számára. Ezzel szemben a nem funkcionális követelmények olyan dolgokkal foglalkoznak, mint a teljesítmény, a megbízhatóság és a biztonság.

Fontos a tervezés

Határozzuk meg az API tervezését, beleértve az adatstruktúrát, az elérési útvonalakat és az adatátviteli formátumokat. Döntsük el, hogy milyen architektúra szerint épül fel. Mielőtt megírnánk az első kódsort, olyan architektúrát kell kidolgozni, amely megfelel a követelményeinknek, és tükrözi az API-t használó fejlesztők igényeit. Minden API-nak meg kell felelnie 5 nem funkcionális követelménynek is:

• Használhatóság: a fejlesztőknek minimális erőfeszítéssel meg kell tudniuk tanulni és használni az API-t.
• Megbízhatóság: az API az elvárásoknak megfelelően, megbízhatóan, a teljesítményre gyakorolt káros hatás nélkül kell teljesítenie a funkcióit.
• Skálázhatóság: a rendszernek alkalmazkodnia kell a megnövekedett terheléshez.
• Tesztelhetőség: a cél a hibák könnyű azonosítása.
• Biztonság: az API-t védeni kell a rosszindulatú felhasználóktól.

Adatmodell

Definiáljuk az adatok struktúráját és kapcsolatait, amelyeket az API kezelni fog. Határozzuk meg az entitásokat (objektumokat) és a velük végrehajtható műveleteket (létrehozás, olvasás, frissítés, törlés stb.).

Programozási nyelv és keretrendszer kiválasztása

Válasszunk olyan programozási nyelvet és keretrendszert, amely megfelel az igényeinknek és lehetővé teszik az API hatékony és biztonságos építését. Pl.: Node.js, Python, Ruby, Java vagy .NET.

Gondoljunk a biztonságra!

A rosszul megtervezett API-k a sebezhetőség fő forrásai lehetnek. Ezért a tervezési szakaszban fokozottan ügyeljünk a biztonságra az alábbi 4 biztonsági réteg beépítésével:

• Azonosítás: ki fér hozzá az API-hoz.
• Hitelesítés: aki hozzá szeretne férni az API-hoz az erősítse meg a személyazonosságát.
• Engedélyezés: korlátozzuk le, hogy mit tehet az API-val.
• Titkosítás: biztosítsuk, hogy az adatok illetéktelen felhasználók számára elérhetetlenek legyenek.

Az API fejlesztése

Miután befejeztük az API tervezését, ideje megépíteni saját API-nkat. Ez egy iteratív folyamat. Javasolt az API-jainkat egy-egy végponton építeni, fokozatosan hozzáadva további funkciókat, közben folyamatosan tesztelni és elkezdeni a részletes dokumentációt megírni.

Az API implementálása

Hozzuk létre az API végpontokat (endpoints), amelyek az adatokhoz és műveletekhez való hozzáférést biztosítják. Az endpointok kiszolgálhatják a GET, POST, PUT, DELETE stb. HTTP kéréseket a megfelelő válaszokkal.

Adatvédelem és hitelesítés

Biztosítsuk az API hitelesítését és az adatvédelmi mechanizmusokat, például token alapú hitelesítést vagy OAuth protokollt, hogy csak az engedélyezett felhasználók férhessenek hozzá az API-hoz és az adatokhoz.

Készítsük el a dokumentációt!

Készítsünk részletes dokumentációt az API-ról, amely leírja az elérhető végpontokat, a paramétereket, a visszatérési értékeket és az esetleges hibakódokat. A dokumentáció segít az API felhasználóinak megérteni és hatékonyan használni az API-t.

Tesztelés és hibakeresés

Végezzünk alapos tesztelést az API-n, hogy megbizonyosodjunk a helyes működésről és az esetleges hibák felderítéséről. Használjunk egységteszteket és integrációs teszteket az API funkcionalitásának ellenőrzésére.

Verziókezelés

Kövessük nyomon és kezeljük az API változatait. Az új funkciók hozzáadásakor vagy a meglévők módosításakor gondoskodjunk arról, hogy a régebbi verziókhoz való kompatibilitás megmaradjon.

Közzététel és dokumentálás

Hozzuk létre az API-katalógusban vagy a fejlesztői portálon a megfelelő dokumentációt és útmutatókat az API regisztrálásához és közzétételéhez.

Ezek az általános lépések segíthetnek elkezdeni az API építését. Az eljárás azonban függ az alkalmazás specifikus követelményeitől és az adott technológiai környezettől. A konkrét esetekben érdemes lehet további kutatást végezni és az adott nyelvhez vagy keretrendszerhez tartozó dokumentációkat követni.

Források:

https://www.gov.uk/guidance/defining-an-api-management-strategy

https://www.mindk.com/blog/how-to-build-an-api/

• Szoftvertervezési minták

A szoftvertervezési minták olyan útmutatók és bevált gyakorlatok, amelyek segítenek strukturálni és szervezni a szoftveralkalmazások tervezését. Ezek a minták hasznosak lehetnek a kód felépítésében, a kommunikációban a komponensek között, valamint a problémák kezelésében és a rugalmas architektúrák létrehozásában. Itt van néhány népszerű szoftvertervezési minta, amelyeket érdemes megismerni:

Singleton minta

A Singleton minta garantálja, hogy egy osztályból csak egyetlen példány létezzen, és biztosítja a globális hozzáférést ehhez az egy példányhoz. Ez hasznos lehet például akkor, amikor egyetlen objektumot szeretnénk megosztani az alkalmazás minden része között. A Singleton minta implementálása függhet a választott programozási nyelvtől és keretrendszertől.

Observer minta

Az Observer minta lehetővé teszi, hogy több objektum (az ún. "megfigyelők") kövessék egy másik objektum (az ún. "tárgy") állapotváltozásait, és automatikusan értesüljenek a változásokról. Ez a minta hasznos lehet például események vagy értesítések kezelésében.

Factory minta

A Factory minta segít a példányosítási folyamat elválasztásában az objektum létrehozásától. Egy központi gyártó osztály (a Factory) felelős az objektumok létrehozásáért, ezáltal könnyen bővíthetővé és karbantarthatóvá téve a kódot.

MVC (Model-View-Controller) minta

Az MVC minta segít a különböző részek (modell, nézet, vezérlő) szétválasztásában egy alkalmazásban. A modell tárolja az adatokat és a logikát, a nézet felelős a felhasználói felület megjelenítéséért, míg a vezérlő közvetíti a kommunikációt a modell és a nézet között.

Dependency Injection minta

A Dependency Injection (DI) minta segít a komponensek közötti függőségek kezelésében. Ahelyett, hogy a komponens maga hozza létre a függőségeit, azokat injektálják (beszúrják) a komponensbe külső forrásból. Ez növeli a rugalmasságot, tesztelhetőséget és könnyebbé teszi a komponensek újrafelhasználhatóságát.

A "Design Patterns: Elements of Reusable Object-Oriented Software" című könyv gyakran ajánlott olvasmány a szoftvertervezési mintákkal kapcsolatban. Az adott programozási nyelv dokumentációja és a közösségi fórumok is jó források lehetnek a szoftvertervezési minták megértéséhez és alkalmazásához.

Források:

"Design Patterns: Elements of Reusable Object-Oriented Software" - Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

https://refactoring.guru/design-patterns

Újrafelhasználás menedzselése

• GitHub jelentősége

A GitHub egy web és felhő alapú szolgáltatás, amely segít a fejlesztőknek kódjuk tárolásában és kezelésében, valamint a kódjuk változásainak nyomon követésében és szabályozásában. Az oldalt 2008 áprilisában indította el Tom Preston-Werner, Chris Wanstrath, P.J. Hyett és Scott Chacon. A GitHub, mint cég 2007 óta létezik, és San Franciscóban található. 2018-ban a Microsoft felvásárolta.

Az oldal közösségi kommunikáció-szerű funkciókat is tartalmaz, mint feedek, követők, wikik és egy közösségi hálózat grafikont, ami megmutatja, hogy hogyan dolgoznak a fejlesztők a saját verzióikon („forks”) egy tárolóban és melyik fork (és azon belül ág) a legújabb.

Ahhoz, hogy feltöltsünk az oldalra, regisztráció szükséges, de a nyilvános tárolókat bárki szabadon böngészheti és letöltheti. Egy regisztrált felhasználóval lehetőség nyílik megbeszélésekre, tárolók kezelésére, mások tárolóihoz való hozzáférésre és a kódban történt változások megtekintésére.

Ahhoz, hogy megértsük, mi az a GitHub, ismernünk kell két összefüggő fogalmat:

• Verziókezelés
• Git

Verziókezelés

A verzióvezérlés segít a fejlesztőknek nyomon követni és kezelni a szoftverfejlesztési projekt kódjában bekövetkezett változásokat. A projekt életében a verziókezelés elengedhetetlenné válik. Ha egy fejlesztő újra fel szeretne használni egy kódot, vagy a kódnak egy részét, nem biztos, hogy a legfrissebb verzióra lesz szüksége. Ehelyett a verziókezelés lehetővé teszi a fejlesztők számára, hogy biztonságosan dolgozzanak az elágazásokon és egyesítéseken.

Elágazással (branch) a fejlesztő megkettőzi a forráskód egy részét (ezt repositorynak/tárolónak nevezik). A fejlesztő ezután biztonságosan módosíthatja a kód ezen részét anélkül, hogy ez befolyásolná a projekt többi részét.

Ezután, amint a kód megfelelően működik, visszaolvaszthatja (merge) a kódot a fő forráskódba, hogy hivatalossá tegye.

Ezeket a változásokat a rendszer nyomon követi, és szükség esetén visszaállíthatja.

Git

A Git egy speciális nyílt forráskódú verziókezelő rendszer, amelyet Linus Torvalds, a Linux készítője hozott létre 2005-ben.

A Git a forráskód változásainak nyomon követésére szolgál. A teljes kódbázis és előzményei minden fejlesztő számítógépén elérhetők, ami lehetővé teszi az egyszerű elágazást és egyesítést.

A Git jellemzői:

• Nyomon követi az előzményeket
• Ingyenes és nyílt forráskódú
• Támogatja a nemlineáris programozást
• Biztonsági mentéseket készít
• Skálázható
• Támogatja az együttműködést
• Támogatja a megosztott, közösségben megvalósuló fejlesztést

Forráskód nyilvánossá tétele

Amennyiben lehetséges, a forráskódot mindig nyilvánosan elérhetővé kell tenni.

A kód közzétételekor meg kell győződni a következőkről:

Licenc kiválasztása

Határozd meg, hogy milyen licenc alatt kívánod közzétenni a szoftvert. Különböző nyílt forráskódú licencmodellek léteznek, mint például az MIT licenc, az Apache licenc, a GNU General Public License (GPL) stb. Válassz olyan licencet, amely megfelel az elképzeléseidnek és szabadon használhatóvá teszi a szoftvert.

Dokumentáció és útmutatók

Biztosítsd, hogy a szoftverhez megfelelő dokumentáció és útmutatók álljanak rendelkezésre, amelyek segítséget nyújtanak a felhasználóknak a telepítéshez, a konfiguráláshoz és az alkalmazás használatához.

Nyilvánosság és közösség

Hozzáférhetővé téve a szoftvert, biztosítsd a nyilvánosságot és a közösségi kommunikációt. Olyan fórumokat és kommunikációs csatornákat hozz létre, ahol a felhasználók kérdéseket tehetnek fel, hibákat jelenthetnek és ötleteket oszthatnak meg.

Kódbázis kezelése

Használj verziókezelő rendszert, például Git-et, amely lehetővé teszi a kódbázis követését, változások nyomon követését és a közös munkát a fejlesztőkkel. Biztosítsd, hogy a kódbázis tiszta legyen, jól dokumentált változtatásokkal.

Biztonság és adatvédelem

Mielőtt közzéteszed a szoftvert, végezz biztonsági ellenőrzéseket és győződj meg arról, hogy nincsenek olyan sérülékenységek vagy hibák a kódban, amelyek veszélyeztethetik a felhasználók biztonságát vagy az adatvédelmet.

Következetes verziókezelés

A változások és fejlesztések során gondoskodj arról, hogy a verziószámokat és változtatásokat következetesen dokumentáld. Ez lehetővé teszi számodra, hogy követni és ellenőrizni tudd a szoftver változásait az idő múlásával. Segítséget nyújt az átláthatóságban, a hibakeresésben, és szükség esetén a változtatások visszavonásában.

Az állami informatikai fejlesztések során is ezeket a gyakorlatokat részesítsük előnyben.

Források:

https://kinsta.com/knowledgebase/what-is-github/

https://www.simplilearn.com/tutorials/git-tutorial/what-is-git#what_is_git

https://hu.wikipedia.org/wiki/GitHub#T%C3%B6rt%C3%A9nelme

https://www.gov.uk/service-manual/technology/making-source-code-open-and-reusable

Fogel, K. (2005). Producing Open Source Software: How to Run a Successful Free Software Project. O'Reilly Media.

Fitzek, F. H., & Reichert, F. (2016). Open Source for the Internet of Things. Elsevier.

• A LIBRA Alkalmazás-katalógus használata a gyakorlatban

A "LIBRA Alkalmazás-katalógus szerepe az újrafelhasználás során" pontban már kifejtettük a LIBRA Alkalmazás-katalógus szerepét az állami informatika körében, most arra térünk ki, hogy hogyan lehet használni, ha egy komplett alkalmazást szeretnénk újrafelhasználni vagy a saját igényeinkre szabni.

Az alkalmazásfejlesztés előkészítő szakaszában a szolgáltatónak ellenőrzést szükséges végeznie az Állami Alkalmazás-katalógusban annak érdekében, hogy a párhuzamos alkalmazásfejlesztések elkerülhetők legyenek és ezzel a takarékos állami üzemeltetés követelményei teljesülhessenek.

Az Állami Alkalmazás-katalógus böngészőből érhető el az alábbi linken:

https://libra.aafk.gov.hu/

A bejelentkezés felhasználónév (a regisztrációnál megadott email cím) és jelszó megadásával történik.

A bal menüsávban kiválasztható szervezetek, illetve alkalmazások lehetőségekre kattintva juthatunk el a LIBRA Alkalmazás-katalógusban szereplő szervezeteket/alkalmazásokat felsoroló oldalakhoz.

A kiválasztott alkalmazásra kattintva tekinthetjük meg annak egyes űrlapjait.

Újrafelhasználhatósági témában a Felhasználási jogok adatlapon kaphatunk megfelelő információt arról, hogy az adott alkalmazás forráskódja és dokumentációja rendelkezésre áll-e az állami szervezetnél, illetve azok felhasználási jogának továbbadása engedélyezett-e.

Amennyiben minden adott az alkalmazás újrafelhasználáshoz, célszerű felvenni a kapcsolatot a Digitális Szolgáltató Központtal.