Softvertechnológia (VIMIAB04) - Szoftverfejlesztés

Szoftvertechnológia (VIMIAB04) Szoftvertechnológia bevezető (Software engineering) Dr. Micskei Zoltán https://mit.bme.hu/~micskeiz 1  Tanulási eredmények A tananyag elsajátítása után a hallgató képes lesz (K1)...

Szoftvertechnológia (VIMIAB04) Szoftvertechnológia bevezető (Software engineering) Dr. Micskei Zoltán https://mit.bme.hu/~micskeiz 1  Tanulási eredmények A tananyag elsajátítása után a hallgató képes lesz (K1) bemutatni a szoftvertechnológia céljait és sajátosságait, (K1) felsorolni a különböző alkalmazási területek jellegzetességeit, (K2) összefoglalni, hogy milyen nézőpontokból, feladatokból és szereplőkből áll egy tipikus szoftverfejlesztési folyamat, (K1) felidézni, hogy milyen szakmai fejlődési utak léteznek az informatika területén. Szoftvertechnológia (VIMIAB04) 2 2  Hova fejlődött a szoftverek fejlesztése 50 év alatt? Miért nehéz továbbra is jó szoftvert készíteni? A tantárgy célkitűzése, hogy áttekintést adjon a komplex szoftverek fejlesztésével kapcsolatos feladatokról, kihívásokról és jó gyakorlatokról. Bár a szoftveres rendszerek és maga a szoftvertechnológia rengeteget fejlődtek az elmúlt évtizedekben, a megoldandó problémák és egyre bonyolultabbak és nagyobb méretűek. Így a szoftverfejlesztés továbbra sem egy megoldott feladat. 3  NASA Perseverance (videó) https://mars.nasa.gov/mars2020/multimedia/videos/ Szoftvertechnológia (VIMIAB04) 4 Videók: https://mars.nasa.gov/mars2020/multimedia/videos/ Ma már képesek vagyunk olyan szoftvereket készíteni, amik emberi beavatkozás nélkül földre (pontosabban Marsra) tesznek egy több tonnás nagyon érzékeny felderítő robotot, mindezt egy rendkívül bizonytalan környezetben. De ehhez egy sok éves projektben rengeteg ember munkáját kell összehangolni, és hiba nélkül kell működnie ennek a rendkívül komplex szoftvernek. 4  Software engineering A software engineering meghatározásához először a software, majd engineering fogalmakat érdemes körbejárni. Figyelem: a software engineering kifejezésnek nincs igazán jó magyar fordítása. A szoftverfejlesztés vagy szoftvertervezés inkább részfeladatokat ír le, a szoftvermérnökség talán kevésbé terjedt el. Jobb elnevezés hiányában a tárgyban sokszor szoftverfejlesztést fogunk használni, de ez, mint látni fogjuk, nem csak a kód megírását foglalja magában! 5  Mi a szoftver? Eredeti angol definíció a jegyzetek részben Szoftver [software]: számítógépes programok, folyamatok és esetlegesen a számítógépes rendszer üzemelésére vonatkozó dokumentációk és adatok. Forrás: IEEE, "Systems and software engineering — Vocabulary," ISO/IEC/IEEE Standard 24765, 2010 Nem csak a programkód! Szoftvertechnológia (VIMIAB04) 6 software: computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system 6  Szoftverrendszer [software system] szoftverrendszer: olyan rendszer, ami szoftverből, hardverből és adatból áll, és az elsődleges értékét a szoftver végrehajtása adja. Forrás: OMG, "Essence – Kernel and Language for Software Engineering Methods" formal/18-10-02, 2018 rendszer [system]: együttműködő elemek kombinációja, ami egy vagy több megadott cél elérése érdekében szerveződik. Forrás: ISO/IEC 15288:2008 (IEEE Std 15288-2008) Szoftvertechnológia (VIMIAB04) 7 software system: a system made up of software, hardware, and data that provides its primary value by the execution of the software system: combination of interacting elements organized to achieve one or more stated purposes. Sok esetben nem csak magával a szoftverrel kell foglalkoznunk, hanem az azt magába foglaló rendszerrel is. Ez minimálisan hardvert és adatot érint még, de egyre több informatikai rendszer úgynevezett társadalmi-technikai [socio-technical] rendszer, ahol a rendszert használó embereket és szervezeteket legalább annyira fontos figyelembe venni, mint a szoftver kódját. 7  Példa: szoftver és rendszer DOC SW Online pénztárgép HW API SW HW DOC SW HW Online pénztárgép System of Systems (SoS) Szoftvertechnológia (VIMIAB04) 8 Az online pénztárgépek folyamatos kapcsolatban vannak a NAV központi szervereivel, és folyamatosan adatokat kell küldeniük. Sok gyártó készít kompatibilis online pénztárgépet, ezekre egyedi, saját szoftverek fejlesztenek. Maga a szoftver azonban egyedül nem használható, kell hozzá a pénztárgép hardver, az üzembehelyezéshez szükséges leírás vagy szolgáltatás. A NAV-nak is van egy saját rendszere (ami belül valószínűleg rengeteg különálló szoftver és hardver együttműködéséből jön létre). Ez egy megadott felületen (Application Programming Interface – API) érhető el a pénztárgépek számára. Az egyes online pénztárgépek és a NAV rendszerének együttesére is tekinthetünk egy nagy rendszerként. Azonban a NAV-nak nem csak pénztárgépek adatokat, hanem most már a szolgáltatások adatait is online kell küldeni (online számla). Erre egyre több számlázó szoftver képes, amik vagy szolgáltatásként internetről („felhőből”) érhetők el, vagy az ügyfélhez telepíthetők. Ezek mind külön-külön szoftverek, szoftveralapú rendszerek. Érdeklődőknek elérhető a NAV specifikációja a GitHub- on: https://github.com/nav-gov-hu/Online-Invoice A NAV az online pénztárgép adatok egy részét az online számla rendszernek átadja, a két rendszerből származó adatokat együttesen is vizsgálja. Így ez tekinthető akár rendszerek rendszerének (system of systems). 8  Mérnökség (?) [Engineering] engineering: szisztematikus, fegyelmezett, mérhető módszerek alkalmazása struktúrák, gépek, termékek, rendszerek vagy folyamatok terén. Forrás: IEEE, "Systems and software engineering — Vocabulary," ISO/IEC/IEEE Standard 24765, 2010 Szoftvertechnológia (VIMIAB04) 9 Engineering: the application of a systematic, disciplined, quantifiable approach to structures, machines, products, systems, or processes. Érdemes megfigyelni, hogy a „tradicionális” mérnöki foglalkozásokban hogyan vegyítik a matematikai alapokra építő számolásokat/becsléseket, a szabványok adta előadásokat/tanácsokat és a saját tapasztalatot. 9  Hogyan dolgozik egy „igazi” mérnök? Iteráció és kompromisszumok (trade-off) Vevői követelmény Tervezés, modellezés Szabványok Gyártás Meglévő alkatrészek Szimuláció, analízis Prototípus, tesztelés Szoftvertechnológia (VIMIAB04) 10 (Opcionális): érdeklődőknek egy hosszabb írás, hogy vajon mérnök-e a szoftvermérnök. Hillel Wayne. Are we really engineers? https://www.hillelwayne.com/post/are-we-really-engineers/ 10  Szoftvermérnökség [Software engineering] software engineering: egy mérnöki ág, ami olyan alapos módszerek kidolgozására és használatára fokuszál, amiknek a segítségével tervezett és fejlesztett szoftver termékek megbízhatóan ellátnak meghatározott feladatokat. Forrás: ACM, "Computing Curricula 2020" Többverziós programok többszereplős fejlesztése. Forrás: Brian Randell vagy David Parnas (nem egyértelmű) Szoftvertechnológia (VIMIAB04) 11 - Software engineering: an engineering discipline that focuses on the development and use of rigorous methods for designing and constructing software artifacts that will reliably perform specified tasks - “The multiperson development of multiversion programs.” (forrás: Brian Randell vagy David Parnas; nem egyértelmű) Kapcsolódó, hasonló definíciók: software engineering: systematic application of scientific and technological knowledge, methods, and experience to the design, implementation, testing, and documentation of software (ISO/IEC) 11  Programozás és szoftverfejlesztés Vevő, igények, üzlet Szoftver- Csapatban dolgozás fejlesztés Nagy méretű szoftver Hosszú életciklus Programozási nyelvek Programozás Algoritmusok Adatszerkezetek „Software engineering is programming integrated over time.” (Software Engineering at Google könyv) Szoftvertechnológia (VIMIAB04) 12 - Az eddigi Programozás tantárgyak az alapokat segítettek elsajátítani, amikor egy kisebb, jól definiált specifikációhoz kellett önállóan egy programot elkészíteni. - A Szoftvertechnológia tantárgy keretében erre építve azzal foglalkozunk, hogy milyen módszerek és eszközök segítenek, ha nem pontos és egyértelmű elvárások alapján, csapatban együtt dolgozva, egy esetleg régebb óta létező szoftvert kell karbantartható módon fejleszteni, aminek akár egymásnak ellentmondó szempontokat is ki kell szolgálnia. - Software Engineering at Google könyv: Programming: programkód elkészítése adott feladathoz. Software engineering: minden, ami ahhoz kell, hogy az elkészült programkód karbantartható / fenntartható / hatékony / skálázható / változásokhoz adaptálható legyen a teljes életciklusa során (ami akár évek vagy évtizedek) – fejlesztést segítő eszközök és jó gyakorlatok, csapat, szervezeti kultúra, kompromisszumok hozása (trade-off) 12  Mik a szoftver sajátosságai? Gyártás Egyszerű másolás Meghibásodás Konzisztencia Fizikai kényszerek Logikai fogalmak Módosítás nehéz Könnyebb átírni Képek: Unsplash Szoftvertechnológia (VIMIAB04) 13 Bár sok közös jellemzője van más mérnöki feladatokkal, szoftverek készítése némiképp eltér például egy elektronikai alkatrész vagy kerékpár tervezésétől. Fizikai termékek (csavar, chip…) esetén a konzisztens, olcsó, nagy tételű gyártás nehéz probléma. Szoftver esetén még egy példány elkészítése triviális. A fizikai alkatrészek meghibásodnak, elöregednek. Két ugyanolyan típusú dióda jellemzőiben biztos lesz valami (megadott tartományon belüli) eltérés. Szoftver esetén az ilyen jellegű meghibásodásokkal nem kell számolni, ott a tervezési hibákra kell felkészülni. (Természetesen lesznek futásidejű problémák is, pl. megtelik a merevlemez, korrupt lesz a memóriatartomány, de az nem azért, mert elöregedett egy for ciklus.) Egy autó vagy épület tervezése során a fizikai világ kényszerei korlátoznak. Sok szoftver esetén viszont elvont, elképzelt problémakörben dolgozunk, ahol sokkal kevesebb kötöttség van. Egy NYÁK vagy betonelem esetén ha a bemérés során probléma van, akkor esetleg újra le kell gyártatni a prototípust. Szoftver esetén ha egy teszt sikertelen, akkor a hiba okának megtalálása után könnyebben átírható a kód, és gyorsan előállt egy új verzió, amit újra lehet tesztelni. 13  Hova jutott a szoftverfejlesztés? 1969: szoftver 2020: rossz minőségű SW „ára” $2000 milliárd / év krízis? Szoftvertechnológia (VIMIAB04) 14 NATO report: „There was a considerable amount of debate on what some members chose to call the ‘software crisis’ or the ‘software gap’. As will be seen from the quotations below, the conference members had widely differing views on the seriousness, or otherwise, of the situation, and on the extent of the problem areas” … „There is a widening gap between ambitions and achievements in software engineering” CISQ report: The Cost of Poor Software Quality in the US: A 2020 Report. https://www.it-cisq.org/cisq-files/pdf/CPSQ-2020-report.pdf 14  Szoftverrendszerek: sikerek és kudarcok Linux (1991-) Mars Orbiter (1998) „just a hobby, won't be big Elégett a marsi belépéskor and professional like gnu” $125 milliós kár ~4e közreműködő, Angol -> SI konverzió hiba ~80e commit évente CERN LHC (1998-) Knight Capital (2012) 25 petabyte adat évente Tesztelő kód elkezdett Biztonságkritikus vezérlés kereskedni (rossz frissítés) Több 10 ezer kutató $440 milliós kár, káosz Google Maps (2005-) Crowdstrike (2024) Széles hozzáférhetőség Hibás frissítés driver-ben Egyszerű kezelhetőség Windows BSOD (8m gép) Street View Reptér, kórház leállt Szoftvertechnológia (VIMIAB04) 15 Linux kernel: https://project.linuxfoundation.org/hubfs/Reports/2020_kernel_history_report_0 82720.pdf?hsLang=en Mars Climate Orbiter: https://solarsystem.nasa.gov/missions/mars-climate- orbiter/in-depth/ Knight Capital: https://www.henricodolfing.com/2019/06/project-failure-case- study-knight-capital.html Poly Network: https://research.kudelskisecurity.com/2021/08/12/the-poly- network-hack-explained/ CrowdStrike: https://en.wikipedia.org/wiki/2024_CrowdStrike_incident 15  Hova fejlesztünk szoftvert? Alkalmazási területek jellegzetességei Szoftvertechnológia (VIMIAB04) 16 16  Szoftver az élet minden területén A szoftver meghatározó része egyre több terméknek és szolgáltatásnak Szoftvertechnológia (VIMIAB04) 17 17  Webes és mobil alkalmazások Nagyméretű szoftver és adat Több 10 ezer szerveren futó SW-ek ! Hyper skálázódás (SW, cég, csapat…) Felhasználói élmény (UX) Kísérletezés, gyorsan változó igények ! Gyors visszajelzés és alkalmazkodás Lásd „Mobil és webes szoftverek” tantárgy Szoftvertechnológia (VIMIAB04) 18 18  Üzleti és nagyvállalati alkalmazások Állami és nagyvállalati SW Egyedi SW, külső beszállító bevonásával ! Részletes specifikáció és szerződés Üzleti (dobozos) termékek Változatos célcsoport: KKV-tól multi ! Testreszabhatóság és tanácsadás Lásd „Információs rendszerek üzemeltetése” tantárgy Szoftvertechnológia (VIMIAB04) 19 19  Kritikus és beágyazott rendszerek Beágyazott rendszerek Fizikai rész, hosszú életciklus, költség ! Együttműködés más mérnökökkel Biztonságkritikus rendszerek Emberélet és károkozás lehetősége ! Elvárható helyes működés biztosítása Lásd „Rendszermodellezés” és „Beágyazott inf. rendszerek” tantárgyak Szoftvertechnológia (VIMIAB04) 20 20  Nyílt forráskódú könyvtárak és eszközök Nyílt forráskódú fejlesztés Radikálisan új módszereket hozott ! Aszinkron, elosztott projektműködés SW eszközök és könyvtárak OS, fordítóprogram, hálózati SW… ! Karbantartás költsége, közösség Lásd „Nyílt forráskódú és szabad szoftverek” választható tantárgy Szoftvertechnológia (VIMIAB04) 21 21  Hogyan? Módszerek, jó gyakorlatok Szoftvertechnológia (VIMIAB04) 22 22  Szoftvertechnológia nézőpontjai Technikai Emberi … Üzleti Szervezeti Szoftvertechnológia (VIMIAB04) 23 Technikai: eddig ezzel foglalkoztak a leginkább a tárgyak (program megvalósítása, tesztelése…) Üzleti: a szoftverek egy jelentős része valami üzleti probléma megoldásában segít, cég/felhasználók/szervezet számára termel valamilyen pénzbeli vagy egyéb értéket (value). A célközönség, a probléma és a lehetséges érték és hatás azonosítása legalább annyira fontos, mint a technikai vetület. Emberi: Bár a szoftverre sokszor mint valami determinisztikus logikai konstrukcióra gondolunk, a legtöbbször emberek fogják használni. Az Ő elvárásaik, igényeik, felhasználási módjaik azonosítása és a szoftver használatának megtanítása és figyelése nélkül a legjobb szoftver sem ér semmit. Szervezeti: a nagyobb szoftverek fejlesztése során egy csapat dolgozik együtt valamilyen módszert követve valamilyen szervezeti keretben. Ezeknek a megfelelő kialakítása (vagy esetlegesen hiányosságai) sokszor nagyobb hatással vannak a készülő szoftverre, mint a technikai problémák leküzdése. …: Ezen kívül jogi, etikai, biztonsági és tucatnyi egyéb szempontot kell figyelemmel kísérnünk egy komplex szoftver készítése során. 23  Szoftvertechnológia módszertanok Hogyan készítsünk (jó) szoftvert? V-modell Scrum (agilis) DevOps Szoftvertechnológia (VIMIAB04) 24 Képek forrása: V-modell és Scrum (Wikipedia), DevOps (https://blog.devops.dev/) A szoftverfejlesztési módszertanok (másképp életciklus modellek) azt határozzák meg, hogy kinek - mikor - mit kell csinálnia a fejlesztés során. Általában valamilyen alapelvek mentén szerveződnek. A tantárgy utolsó blokkjában részletesen foglalkozunk velük. Addig is röviden: V-modell: tipikusan beágyazott, kritikus rendszereknél használják (autó-, repülő- és űripar). Fontos elv az egyes fázisok egymásra épülése és az elkészült termékek folyamatos finomítása (pl. követelményleírás alapján készül a részletes specifikáció, majd az alapján az architektúra terve). Minden fázishoz szorosan kapcsolódnak ellenőrzési és tesztelési feladatok a magas biztonságossági elvárások miatt. Scrum: Egy népszerű agilis fejlesztési módszertan, ami rövid (1-2 hetes) iterációkba, úgynevezett sprintekbe, szervezi a fejlesztést. Fontos szempont a felhasználóval/megrendelővel való kapcsolattartás és a csapatok autonóm működése. Sok kötött „szertartást” is tartalmaz (napi stand-up megbeszélés, retrospektív…), emiatt kritika is éri mostanában. DevOps: inkább megközelítés, mint konkrét módszertan. A szoftver fejlesztésének és üzemeltetésének kapcsolatát hangsúlyozza. Tipikus gyakorlata, hogy a funkciót fejlesztő csapat felel az adott funkció üzemeltetéséért is, hangsúlyozza a gyors, adat-alapú visszajelzés fontosságát. 24  Mi a közös a módszertanokban? Object Management Group (OMG) Essence szabvány Közös „magot” azonosították Erre építhetők jó gyakorlatok és módszertanok Szoftvertechnológia (VIMIAB04) 25 Az alap lépések, gyakorlatok és feladatok bemutatására most az Essence szabvány ábráit és fogalmait fogjuk használni. (Lehetne ezeket máshogy csoportosítani, pl. minden szoftvertechnológiával foglalkozó könyv saját felsorolásokat használ. De így próbálunk valami közös nyelvet használni majd az első előadásokban.) 25  Essence: mivel kell foglalkozni? Megrendelő (lehetőség, igény…) Megoldás (készítendő SW…) „Törekvés” (csapat, hogyan fejlesztünk…) Szoftvertechnológia (VIMIAB04) 26 Hogy kell olvasni az ábrát? A fura  jelek az úgynevezett alpha-k (ezek az alapvető szoftvertechnológiai elemek, amiknek a haladását figyelemmel kísérhetjük). Közöttük lehetnek kapcsolatok, amiknek az irányát a ráírt szövegben lévő < jel jelzi. OMG Essence specification, Figure 8.2 – The Kernel Alphas „Stakeholders: The people, groups, or organizations who affect or are affected by a software system” „Opportunity: The set of circumstances that makes it appropriate to develop or change a software system.” „Requirements: What the software system must do to address the opportunity and satisfy the stakeholders.” „Software System: A system made up of software, hardware, and data that provide its primary value by the execution of the software. A software system can be part of a larger software, hardware, business, or social solution” „Team: A group of people actively engaged in the development, maintenance, delivery, or support of a specific software system.” „Work: Activity involving mental or physical effort done in order to achieve a result.” „Way-of-Working: The tailored set of practices and tools used by a team to guide and support their work.” 26  Essence: mit lehet csinálni? Szoftvertechnológia (VIMIAB04) 27 OMG Essence specification, Figure 8.3 – The Kernel Activity Spaces „Explore Possibilities: Explore the possibilities presented by the creation of a new or improved software system. This includes the analysis of the opportunity to be addressed and the identification of the stakeholders.” „Understand Stakeholder Needs: Engage with the stakeholders to understand their needs and ensure that the right results are produced. This includes identifying and working with the stakeholder representatives to progress the opportunity.” „Ensure Stakeholder Satisfaction: Share the results of the development work with the stakeholders to gain their acceptance of the system produced and verify that the opportunity has been successfully addressed.” „Use the System: Observe the use the system in an operational environment and how it benefits the stakeholders.” „Understand the Requirements: Establish a shared understanding of what the system to be produced must do.” „Shape the System: Shape the system so that it is easy to develop, change and maintain, and can cope with current and expected future demands. This includes the overall design and architecting of the system to be produced.” „Implement the System: Build a system by implementing, testing, and integrating 27  one or more system elements. This includes bug fixing and unit testing.” „Test the System: Verify that the system produced meets the stakeholders’ requirements.” „Deploy the System: Take the tested system and make it available for use outside the development team.” „Operate the System: Support the use of the software system in the live environment.” „Prepare to do the Work: Set up the team and its working environment. Understand and commit to completing the work.” „Coordinate Activity: Co-ordinate and direct the team’s work. This includes all ongoing planning and re-planning of the work, and adding any additional resources needed to complete the formation of the team.” „Support the Team: Help the team members to help themselves, collaborate, and improve their way of working.” „Track Progress: Measure and assess the progress made by the team.” „Stop the Work: Shutdown the software engineering endeavor and hand over the team’s responsibilities.” 27  Módszertanok és gyakorlatok (példák) Módszertanok Pair programming Domain-driven Design (DDD) Gyakorlatok Cross-functional teams Continous integration (CI) User stories Hardware-in-the- Test-driven development (TDD) loop testing (HiL) Szoftvertechnológia (VIMIAB04) 29 Rengeteg módszertan és gyakorlat érhető el. Nagyon sok listát és véleményt lehet olvasni, hogy melyik a legjobb (ez nyilván időben változik, ahogy haladunk az adott hype görbén). [Hype görbe: https://en.wikipedia.org/wiki/Gartner_hype_cycle] Módszertanok: Kanban: egy könnyűsúlyú módszer, ami a párhuzamosan végezhető feladatokat igyekszik korlátozni, és az elvárásokat és a kapacitások korlátait egyensúlyozni. Egyfajta „lean” módszertan, autóipari gyártásból származnak az alapjai. SAFe: Scaled agile framework, nagyvállalati környezethez próbálja adaptálni az agilis módszertanokat. Gyakorlatok: Páros programozás (pair programming) Tesztvezérelt fejlesztés (TDD) Folytonos integráció (CI) 29  Nincs legjobb gyakorlat Nincs legjobb módszertan Minden függ a környezettől… 30  Különböző környezet – különböző célok Startup új Autó fék- Beszállító egy szolgáltatása rendszere banknál „Move fast and Biztonsági Minősítések break things” szabványoknak (ISO, CMMI…) Kevés doksi, megfelelés Jól definiált egyszerű Többszintű folyamatok folyamatok ellenőrzés követése Kanban? Modellalapú fejlesztés? Scrum / SAFe? Éles környezetben tesztelés? MiL / SiL / HiL tesztelés? Elfogadási tesztek? Szoftvertechnológia (VIMIAB04) 31 31  Szakmai fejlődés Karrierút, szervezetek, etika Szoftvertechnológia (VIMIAB04) 32 32  Karrierutak szoftverfejlesztőként Nem egységes elnevezés, de itt már nem elég „jól programozni” Individal Contributor és Manager út párhuzamosan forrás Szoftvertechnológia (VIMIAB04) 33 Forrás: Levels, Ladders and Titles: Everything You Need to Know, https://www.levels.fyi/blog/what-are-career-levels-ladders.html 33  Mi kell ahhoz, hogy fejlődjek? (példa) CircleCI career matrix (link) Sokféle aspektus, nem csak technikai! Magasabb szinteken egyre nagyobb és több embert érint a saját munkánk hatása Szoftvertechnológia (VIMIAB04) Nagyon sok részletes példa: 34 https://progression.fyi/ PÉLDA: CircleCI matrix, Senioer Engineer Writing code: „Consistently writes production-ready code that is easily testable, easily understood by other developers, and accounts for edge cases and errors. Understands when it is appropriate to leave comments, but biases towards self- documenting code.” Testing: „Understands the testing pyramid, and writes unit tests as well as higher level tests in accordance with it. Always writes tests to handle expected edge cases and errors gracefully, as well as happy paths.” Effective communication: „Communicates effectively, clearly, concisely in written and verbal form both technical and non technical subjects, and in an audience- oriented way. Actively listens to others and ensures they are understood. Pays attention to nonverbal communication. ” 34  Pozíciók az informatika világában Test engineer Network / system administrator Data scientist Software engineer …. Product manager Software architect Technical writer / Evangelist Szoftvertechnológia (VIMIAB04) 35 A szoftverfejlesztő pozíción túl rengeteg érdekes karrierút van az informatika világában. Szoftverfejlesztő karrierrel és lehetőségekkel kapcsolatban érdemes Orosz Gergely blogjába beleolvasni (https://blog.pragmaticengineer.com/). 35  Szakmai szervezetek Szoftvertechnológia (VIMIAB04) 36 ACM: Mottó - Advancing Computing as a Science & Profession. Szakmai szervezet, inkább USA fókusszal. Az ACM osztja ki a Turing-díjat, amit a számítástechnikai Nobel-díjának szoktak hívni. Sok releváns folyóirat és konferencia hozzájuk tartozik. Egyénként is lehet a tagsághoz csatlakozni. IEEE (Institute of Electrical and Electronics Engineers): kezdetben villamosmérnök fókusz, de most már az informatikát is támogatják. Sok szabványt dolgoznak ki az informatika széles területén. Kiejtése: “I-triple-E”. Egyénként is lehet a tagsághoz csatlakozni. OMG (Object Management Group): cégek és akadémiai intézetek a tagjai, szabványokat és specifikációkat dolgoznak ki. A legismertebb szabványuk az UML modellezési nyelv. ISTQB: tesztelési tananyagokat dolgoznak ki és az alapján vizsgázni lehet náluk. Magyar tagszervezete a Hungarian Testing Board (https://www.hstqb.org/). NJSZT (Neumann János Számítógéptudományi Társaság): az egyik legrégebbi és legnagyobb hazai informatikai szakmai szervezet. 36  Etikus és szakmai munkavégzés ACM Code of Ethics and Professional Conduct Járuljon hozzá a társadalom és az emberiség jólétéhez Kerülje el a károkozást Legyen őszinte és megbízható Legyen fair és ne diszkrimináljon Tartsa tiszteletben a személyes adatokat Tartsa tiszteletben a bizalmasságot … https://www.acm.org/code-of-ethics Szoftvertechnológia (VIMIAB04) 37 Ezek az alapelvek közelítő fordításai, érdemesebb inkább az angol eredetit megnézni, hogy pontosabb képet kapjunk. 37  Mit tennél szoftverfejlesztőként? Olyan szoftvert kell írnod, ami visszafogja a károsanyag- kibocsátást, ha tesztpadon fut az autó. Olyan szoftvermodult kell fejlesztened, ami a felhasználók személyes adatait analizálja a tudtuk nélkül. Tudod, hogy nem tervezték és tesztelték eléggé az új, vezérlést irányító funkciót a repülőben. Szoftvertechnológia (VIMIAB04) 38 38  Etikus és szakmai munkavégzés? forrás forrás forrás Dieselgate Cambridge Analytica 737 MAX MCAS Szoftvertechnológia (VIMIAB04) 39 - Dieselgate: „Days later Volkswagen admits installing software designed to reduce emissions during lab test.” - Cambridge Analytica: „In the 2010s, personal data belonging to millions of Facebook users was collected without their consent by British consulting firm Cambridge Analytica, predominantly to be used for political advertising” - MCAS: „But several FAA technical experts said in interviews that as certification proceeded, managers prodded them to speed the process. ” 39  Hogyan tovább? Összefoglalás Szoftvertechnológia (VIMIAB04) 40 40  Tantárgy további témái Fejlesztői Követelmények Verziókezelés I. Szoftver- munka lépései kezelése fejlesztési gyakorlatok Tervezés és Jó minőségű Tesztelés és architektúra forráskód teszttervezés Miért és mit Modellezési II. Modellezés UML nyelv modellezünk? nyelvek III. Folyamatok Projekt- Mérés és Módszertanok és projektek menedzsment elemzés Szoftvertechnológia (VIMIAB04) 41 41  Hasznos segédletek (érdemes letölteni!) IEEE szabványok (jelenleg nem elérhető a PDF ) – 24765-2010 Systems and SW engineering – Vocabulary – SE VOCAB – online kereshető formátum elérhető (!) Software Engineering Book of Knowledge (SWEBOK) – V3 verzió elérhető és letölthető International Software Testing Qualifications Board (ISTQB) – Foundation Level Syllabus (v4.0) – Glossary of Testing Terms (EN / HU) – Glossary / Kifejezésgyűjtemény (magyar fordítás) Szoftvertechnológia (VIMIAB04) 42 42  Jegyzetek és könyvek OMIKK-ban elérhető Online könyvek és anyagok Friss könyvek (angolul) Lásd a Moodle oldalon minden előadásnál a kapcsolódó tanyagokat! Szoftvertechnológia (VIMIAB04) 43 43  Összefoglalás Szoftvertechnológia (VIMIAB04) 44 44  Szoftvertechnológia (VIMIAB04) Fejlesztői munkafolyamat Dr. Micskei Zoltán https://mit.bme.hu/~micskeiz Az előadáson egy szoftverfejlesztő nézőpontjából vesszük végig az alacsony szintű, napi munkafolyamatot. Ez segít majd elhelyezni a tantárgy elején szereplő gyakorlatokat, azonosítani azok céljait és szerepét. A technikák és gyakorlatok felsorolása nem kimerítő. Most kevésbé fogunk a mikorra és miértre koncentrálni, erre majd a tárgy utolsó harmadában a szoftverfejlesztési folyamatoknál visszatérünk (pl. miért user story-t használnak az agilis módszertanok a funkciók összegyűjtésére, és azt mikor és ki készíti el). 1  Tanulási eredmények A tananyag elsajátítása után a hallgató képes lesz (K2) összefoglalni a fejlesztési munkafolyamat tipikus lépéseit, (K1) felsorolni az egyes lépéseket segítő jó gyakorlatokat, (K3) használni build eszközöket szoftvertermékek előállítására. Szoftvertechnológia (VIMIAB04) 2 2  Szoftvertechnológia tantárgy témái Fejlesztői Követelmények Verziókezelés I. Szoftver- munka lépései kezelése fejlesztési gyakorlatok Tervezés és Jó minőségű Tesztelés és architektúra forráskód teszttervezés Miért és mit Modellezési II. Modellezés UML nyelv modellezünk? nyelvek III. Folyamatok Projekt- Mérés és Módszertanok és projektek menedzsment elemzés Szoftvertechnológia (VIMIAB04) 3 3  DevOps = Development + Operations Szoftvertechnológia (VIMIAB04) 4 A DevOps megközelítésről (fejlesztés és üzemeltetés összekapcsolása) még a tárgy végén lesz szó, most csak az ábra segít összegyűjteni, hogy tipikusan milyen lépések vannak. Ezek a lépések majd mindegyik módszertanban megtalálhatók, a különbség főleg a fókuszban, az egyes lépések részletességében, valamint abban van, hogy mekkora méretű feladatra végezzük el ezt a ciklust. (Egyébként: “DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes.”) 4  Szoftverfejlesztés feladatai Szoftvertechnológia (VIMIAB04) 5 5  Mi lehet egy junior fejlesztő feladata? Új funkció Hibajavítás Átírás … [refactor] Szoftvertechnológia (VIMIAB04) 6 6  Új funkció fejlesztése (1): bemenet Funkció [feature] céljai és részletesebb leírása (Folyamat nem itt kezdődik, lásd Követelmények előadást!) Open source / agilis környezetben: issue / story / ticket Szoftvertechnológia (VIMIAB04) 7 A fejlesztő kap egy feladatot (hogyan? kitől? erről majd a tárgy utolsó harmadában lesz szó), amit már valakik körvonalaztak, megfelelő méretűre felbontották, és el lehet vele kezdeni dolgozni. Agilis vagy nyílt forrású projekt esetén tipikusan ezek egy úgynevezett issue kezelő rendszerben vannak nyilvántartva, ahol rövidebb, strukturált szöveges leírást lehet hozzájuk adni és a tulajdonságaikat megadni (állapot, felelős, milyen részhez tartozik, kapcsolódó kód…). Ilyen funkciót nyújt például a GitHub vagy a Jira, de rengeteg egyéb nyílt vagy kereskedelmi megoldás létezik még. 7  Új funkció fejlesztése (1): bemenet Funkció [feature] céljai és részletesebb leírása (Folyamat nem itt kezdődik, lásd Követelmények előadást!) (Biztonság)kritikus környezetben: modul specifikáció Szoftvertechnológia (VIMIAB04) 8 A fejlesztő kap egy feladatot (hogyan? kitől? erről majd a tárgy utolsó harmadában lesz szó), amit már valakik körvonalaztak, megfelelő méretűre felbontották, és el lehet vele kezdeni dolgozni. Beágyazott / kritikus környezetben tipikusan ez egy formálisabb, részletesebb dokumentáció, ami egy hosszabb folyamat eredménye. Lehet egy szöveges dokumentum, de sok esetben modellekkel, részletes táblázatokkal ki van egészítve. 8  Új funkció fejlesztése (2): átvizsgálás Megvalósítás elkezdése előtt: átvizsgálás [review] Megvalósítható? Ellentmondásos? Hiányos? Tesztelhető? Lásd a Követelmények kezelése előadást Szoftvertechnológia (VIMIAB04) 9 A munka megkezdése előtt kiemelten fontos, hogy maga a fejlesztő is átvizsgálja a kapott feladat leírását, specifikációját. Ezzel sokkal hamarabb lehet problémákat azonosítani és kijavítani, rengeteg felesleges munkát megtakarítva. Az átvizsgálás folyamata az issue megjegyzésekben feltett kérdésektől kezdve a kötött folyamatú, nagyon részletes átvizsgálásig terjedhet; a feladat bonyolultságától és kockázatosságától függően. 9  Új funkció fejlesztése (3): részletes tervek Eddigi információk alapján részletes tervek (akár iteratívan) Változatos részletesség: allépések / pszeudókód / (UML) modell Lásd a Tervezés és architektúra előadást, UML modellezés részt Szoftvertechnológia (VIMIAB04) 10 Az adott alkalmazási területtől és a módszertantól függően eltérő részletességű tervezés előzi meg a kódolás megkezdését: - Lehet, hogy csak a fejlesztő megpróbálja allépésekre bontani a feladatot, esetleges kapcsolódó feladatokat azonosítani (szükségem van-e valamire, kell-e mással egyeztetni…). - Bonyolultabb funkció esetén folyamatábrát lehet skiccelni vagy pszeudókódot felírni. - Még bonyolultabb funkció esetén szükség lehet még részletesebb modellek elkészítésére (például egy összetett állapotgép), ami segít a speciális esetek végig gondolásában, előzetes ellenőrzésben. 10  Hibajavítás Hasonló a menete, de itt a cél meglévő szoftver javítása Hibajelzés forrása: felhasználó / fejlesztők / automatikus teszt… Hibajelentés [bug report] Reprodukálás Jó esetben sok információ Pontos hibajelenség Hibakeresés Környezet (OS, nyelv, program verzió…) Reprodukálás lépései Képernyőképek, Javítás mintaadatok Szoftvertechnológia (VIMIAB04) 11 Tipikus lépések hibajavítás során: Hibát megpróbáljuk a saját környezetünkben is előhozni (reprodukálás): ez sokszor nem is annyira könnyű, hiszen lehet, hogy a hiba csak a felhasználó speciális környezetében jelentkezik (régebbi HW vagy OS, más nyelvi beállítás…). A következő lépés a hiba okának és pontos helyének megtalálása [fault localization]: ez gyakran nem egyértelmű. Szükség lehet a forráskód vagy a naplófájlok tanulmányozására, kód futás közbeni vizsgálására (debugging), hibás eset leszűkítésére minimálisan szükséges lépésekre. Szerencsére erre is van eszköztámogatás már. Végül a hiba javítása következik. Bonyolultabb esetben ez is hasonló lehet a fenti, új funkció fejlesztése folyamat lépéseihez, hisz egy elhamarkodott hibajavítás könnyen sokkal súlyosabb hibákat is okozhat. Fontos, hogy a végén ellenőrizzük, hogy a javítás tényleg megoldotta-e az eredeti hibát, és nem rontott-e el korábban működő funkciókat. 11  Refactor refaktorálás: a meglévő kód átstrukturálására szolgáló technika, ami a belső struktúrát a kívülről látható viselkedés megváltoztatása nélkül alakítja át. Martin Fowler, https://refactoring.com/ Példa: Extract Method Tipikus felhasználás Javítani: karbantarthatóság, olvashatóság, teljesítmény Későbbi kiterjeszthetőség Kódolás során folyamatosan Lásd a refactoring lépéseket: https://refactoring.com/catalog/ Szoftvertechnológia (VIMIAB04) 12 refactoring: a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Maga a refactoring egy elemi technika, amit a fejlesztés közben folyamatosan lehet alkalmazni (pl. elkészült az új funkció első, működő verziója, de utána még sokat kell alakítani rajta, hogy „szép” legyen a kód). Ha nincs megfelelően menet közben karbantartva a kód (vagy elavult rendszer [legacy system] kódja), akkor úgynevezett technikai adósság [technical dept] halmozódik fel (ami tulajdonképpen a most nem megfelelően elvégzett munka későbbi ára, amit meg kell fizetnünk). Például ha nem foglalkozunk a fordító warning üzeneteivel, egy új funkciónál nem törekszünk arra, hogy később kiegészíthető legyen, ha a kódot nem jól strukturáljuk, és ezért minden apróbb új funkció esetén is nagyon sok különböző részét kell a kódnak megváltoztatni. Ebben az esetben szükség lehet külön feladatként is a kód átalakításával foglalkozni. 12  Szoftverfejlesztés feladatai Szoftvertechnológia (VIMIAB04) 13 13  Kód elkészítése (saját környezetben) Kódolás Dokumen- Fordítás & tálás build Debug Tesztelés Szoftvertechnológia (VIMIAB04) 14 Ezt (vagy ehhez hasonló) ciklust ismétlünk addig, amíg a kiválasztott feladattal el nem készülünk. Ezen ciklus lépéseinek a sorrendje változhat (pl., lásd később tesztvezérelt fejlesztés esetén). 14  Hol készítsem el a kódot? Helyi fejlesztőkörnyezet Távoli (felhő) fejlesztőkörnyezet Laptop / PC … (Részben) távoli gépen fut IDE mellett eszközök Több erőforrás, közös környezet telepítése (fordító, web- szerver, csomagkezelő…) Közös fejlesztői beállítások (verziókezelőbe rakható!) Kézi / automatikus Developer productivity (!) forrás Szoftvertechnológia (VIMIAB04) 15 Kép forrása és egy rövid bevezető a témában: https://newsletter.pragmaticengineer.com/p/cloud-development-environments 15  Hogyan: Pair programming Páros programozás: ketten ülnek a gép előtt – Egyik gépel és megvalósít, másik megfigyel és segít (szerepeket váltani!) Tudásmegosztás, mentorálás, taktikai/stratégiai gondolkozás Jobb minőséget eredményezhet, de tanulni kell ezt is! Forrás: „The effectiveness of pair programming: A meta- forrás analysis”, DOI: 10.1016/j.infsof.2009.02.001 Szoftvertechnológia (VIMIAB04) 16 A páros programozásnak nagyon sok, elsőre nem is látható előnye van: a tudás megosztása a csapaton belül (milyen kód mintákat érdemes használni, mi nem vált be korábban); a tapasztaltabb tagok menet közben tudják mentorálni a kezdőket. Bár a kód látszólag lassabban készül el, de sokszor jobb minőségű lesz. Fontos, hogy gyakorolni kell a hatékony alkalmazását, és figyelni arra, hogy mindenki a szerepének megfelelő feladatokat végezze, és rendszeresen váltsuk a szerepeket menet közben. Kép forrása és részletes, jól érhető leírás: https://martinfowler.com/articles/on-pair- programming.html 16  Hogyan: kódolási irányelvek & szabályok Ajánlások a kód írásához [coding guidelines, rules] Iparági, nyelv vagy cégspecifikus Do & don’t (esetleg consider) Tipikus területek: – Formázás (zárójel, szóköz…) – Konvenciók (struktúra, elnevezés…) – Minták (javasolt és tiltott elemek…) Eszköztámogatás (!) – IDE, linter… Forrás: https://google.github.io/styleguide/javaguide.html Lásd a Jó minőségű forráskód előadást Szoftvertechnológia (VIMIAB04) 17 Akkor jó egy fejlesztési projekt környezete, hogy ha ezeket nem is kell nagyrészt fejben tartani a fejlesztőknek, mert eszközök automatikusan ellenőrzik és javítják (például az IDE mentés esetén automatikusan átformázza a kódot a megadott szabályoknak megfelelően). 17  Hogyan: statikus analízis eszközök Statikus analízis: kód vizsgálata futtatás nélkül Generikus hibák, problémák azonosítása (pl. nullával osztás) Visszajelzés a kód írása közben Forrás: https://rules.sonarsource.com/ Lásd a Jó minőségű forráskód előadást Szoftvertechnológia (VIMIAB04) 18 A legtöbb eszköz elérhetővé teszi a szabálygyűjteményét, amiben a probléma leírásán túl jó és rossz példákat is találunk. Ezekből rengeteget lehet tanulni, érdemes már a legkisebb projektek esetén is használni valami fejlesztői környezetbe beépülő statikus analízis eszközt. 18  Szoftverfejlesztés feladatai Szoftvertechnológia (VIMIAB04) 19 19  Nem elég a fordító? > gcc hello.c -o hello Fordítási és build kihívások Sok forrás- és egyéb fájl (több száz…) Többféle változat (architektúra, debug/release) Szoftvertechnológia (VIMIAB04) Külső könyvtárak 20 [library] Kép forrása: LLVM dependencies (https://wiki.gentoo.org/wiki/Project:LLVM/Cross- package_dependencies) Kis programoktól eltekintve nagyon körülményes lenne mindig kézzel összeállított parancsokkal hívni a fordítót, linkert. Nagyobb projekteknél bonyolult függőségi gráf lehet a modulok között, így már magának a fordítási lépések sorrendjének a meghatározása sem triviális feladat. 20  Build Build: Szoftver termékek létrehozása a forrás(kód)ból – Fordítás [compile] ennek csak egy részlépése! Build keretrendszerek: konfigurálható lépések és célok – Maven, Gradle, CMake, MSBuild, Bazel… Előkészítés Fordítás Tesztelés Csomagolás Telepítés Preprocessor Különböző Tesztfuttatás Telepíthető Helyi gépre Generálás verziók Fedettség változat Távoli Függőségek Inkrementális Jelentések Verziózás tárhelyre Szoftvertechnológia (VIMIAB04) 21 Automatizált build: https://www.agilealliance.org/glossary/automated-build Az ábra egy általános build folyamatot mutat be, az eszközök általában mind valami saját elnevezést és folyamatot definiálnak. A felsoroltokon kívül még rengeteg egyéb, kisebb feladatot lehet egy-egy build keretrendszernek megadni. 21  Példa: Build eszközök (Make) CFLAGS ?= -g Paraméterek és változók all: helloworld Célok és függőségek köztük helloworld: helloworld.o # Commands start with TAB not spaces $(CC) $(LDFLAGS) -o $@ $^ helloworld.o: helloworld.c $(CC) $(CFLAGS) -c -o $@ $< Sok visszatérő lépést kell mindig definiálni clean: FRC $(RM) helloworld helloworld.o Szoftvertechnológia (VIMIAB04) 22 22  Példa: Build eszköz (Maven) 1. 2. com.mycompany.app 3. my-app 4. 1.0-SNAPSHOT Szoftver neve és verziója 5. 6. 7. 1.7 8. 1.7 Paraméterek és 9. tulajdonságok 10. 11. 12. 13. junit Függőségek kezelése 14. junit 15. 4.12 16. test 17. Elv: „convention over 18. configuration” 19. Szoftvertechnológia (VIMIAB04) 23 Convention over configuration: ha követem a Maven konvencióját, akkor nem kell külön konfigurálnom azt a részt. Például, ha src-nek nevezem el azt a mappát, amiben a forrásfájlok vannak, akkor azt egyből megtalálja. Külön csak akkor kéne megadni paraméterben ezt, ha ettől a szokástól eltérek. Részletesebben majd lásd a LAB2-nél, vagy ebben a leírásban: https://maven.apache.org/guides/getting-started/index.html 23  Példa: Szabványos könyvtárstruktúra src – main: alkalmazás kódja – java: nyelvenként elkülönítve – resources: minden, ami nem forráskód (képek, hang, adat…) – test: tesztkód hasonló struktúrában target: – build eredménye kerül ide, nem kerül a verziókezelőbe pom.xml: – build konfigurációja (Maven), verziózni! Szoftvertechnológia (VIMIAB04) 24 Lásd kicsit részletesebben: https://maven.apache.org/guides/introduction/introduction-to-the-standard- directory-layout.html 24  Függőségek [dependency] kezelése Tipikus függőségek – Aktuális projekt másik része (közös definíciók, segédkönyvtár…) – Bármi, ami nem része a standard könyvtárnak (grafika, hálózat…) Megoldandó problémák – Definiálni pontosan, hogy mi kell – Beszerezni a megfelelő verziót – Elérhetővé tenni a lokális fordító számára Hova rakjam a függőségeket? – Verziókezelő rendszer (forráskódként vagy binárisként) – Központi vagy internetes tárhelyen Szoftvertechnológia (VIMIAB04) 25 Ezek most a fordításhoz szükséges függőségek (tipikusan megosztott könyvtárak), amik a fordításhoz és a linkeléshez szükségesek. (Később majd lesz szó egy-egy osztály függőségeiről, vagy egy UML modellben függőségekről; ne keverjük azokat ezekkel, csak mert ugyanazt a szót szokás rá használni.) 25  Központi függőségkezelés Függőség egyedi azonosítása (csoport + termék + verzió) Publikus (pl. maven central) vagy saját szerver Tranzitív függőségkezelés Szoftvertechnológia (VIMIAB04) 26 A legtöbb programozási környezet használ manapság már valami központi tárhelyet, ahonnan a becsomagolt függőségeket le lehet tölteni, frissíteni (pl. Java: maven central, Node.js: npm Registry,.NET: NuGet Gallery…). Ezekben az adott szoftver fejlesztői tölthetnek fel új verziót a saját szoftverükből, amit így könnyen el lehet érni bármelyik másik szoftverprojektben. 26  Szoftverfejlesztés feladatai Szoftvertechnológia (VIMIAB04) 27 27  Tesztelés Tesztelés: szoftver futtatása, megfigyelése és kiértékelése (pontosabb definíció később!) Sok szinten és célból – Szint: modul/egység, integrációs, rendszerteszt… – Cél: funkció, teljesítmény, biztonság… – Automatikus és manuális (test vs. check) Teszttervezési technikák (specifikáció, struktúra…) Szoftvertechnológia (VIMIAB04) 28 Lásd a Tesztelés előadásokat 28  Egységtesztelés [unit testing] Különálló egységek tesztelése (modul, osztály…) Funkció fejlesztése közben: normál és kivételes lefutások Forráskód lefedettség mérése [code coverage] Szoftvertechnológia (VIMIAB04) 29 Egységtesztelésből a Szoftvertechnológia és a Programozás 3. tantárgyakból is lesz majd szó később. 29  Tesztvezérelt fejlesztés (TDD) Test-driven development (TDD) Kód elkészítése kis lépésenként Teszt Refactor – Teszt írása (még nem létező kódhoz) írása – Annyi kód írása, amíg a teszt sikeres – Refactor: új és régi kód, tesztkód Kód írása Végig kell gondolni, hogy mit csinál a kód kívülről látható módon Szoftvertechnológia (VIMIAB04) 30 Kent Beck (a TDD megalkotója) leírása a folyamatról és tipikus hibákról: Canon TDD, https://tidyfirst.substack.com/p/canon-tdd 30  Definition of Done Kész van a funkció? Persze, 95%-ban már kész! Működik, már csak … kell. Definition of Done Ellenőrző lista, hogy mikor van valami kész Kód, tesztek, teszt futtatás, próba telepítés… Csapattól függ a tartalma Lásd: https://www.agilealliance.org/glossary/definition-of-done Szoftvertechnológia (VIMIAB04) 31 31  Szoftverfejlesztés feladatai Szoftvertechnológia (VIMIAB04) 32 32  Kód integráció problémája Eddig egy fejlesztőről beszéltünk… A gyakorlatban többen párhuzamosan dolgoznak… Szoftvertechnológia (VIMIAB04) 33 33  Mi segít az integrációban? „Használd ezt a fájlt” main-15-almost-final.c Verziókezelő rendszer [version control system] (Bármilyen) fájl azonosított verziói és verziók sorrendje Tárhely [repository]: fájlok verziói és meta-adata DE: verziókezelő önmagában nem oldja meg az integrációt KELL: egyeztetett folyamat forrás Szoftvertechnológia (VIMIAB04) 34 Lásd a Verziókezelés előadást 34  Tipikus kód integrációs minták Külön forráskód ág [branch] az egyes fejlesztőknek – Saját módosítások oda gyűjtve Merge: két ág módosításaink összefésülése – Ha „kész” vagyok, visszafésülöm a saját módosításaimat, hogy lássák – De: időközben más módosíthatott → konfliktus [merge conflict] Kód kezelési és integrációs minták: Minél ritkább az integráció, Mikor, hol, ki milyen ágon annál nehezebb! dolgozik és fésül „if it hurts… do it more often"” Szoftvertechnológia (VIMIAB04) 35 35  Folytonos integráció [Continuous Integration (CI)] Folytonos integráció: egy olyan szoftverfejlesztési gyakorlat, ahol a csapattagok a munkájukat gyakran integrálják, tipikusan mindenki legalább naponta. Martin Fowler „ Minden integrációt automatikus build ellenőriz (amiben vannak tesztek is), hogy az integrációs hibákat minél előbb észrevegyük” Forrás Szoftvertechnológia (VIMIAB04) 36 Continuous Integration a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. 36  Folytonos integráció támogatása Minden változtatás után: Verziókezelő Kód újrafordítása, (unit) rendszer tesztek futtatása (Közel) azonnali visszajelzés Ne legyen kimaradt fájl vagy beégetett beállítás/útvonal (Akár több platformon) Folytonos integráció kiszolgáló Szoftvertechnológia (VIMIAB04) 37 37  Szoftverfejlesztés feladatai Szoftvertechnológia (VIMIAB04) 38 38  Kiadás [release] készítése kiadás egy konfigurációs elem meghatározott verziója, amit egy adott cél érdekében teszünk elérhetővé IEEE 828-2012 Ügyfélnek átadható vagy éles környezetbe telepíthető Minden szükséges állomány (bináris, konfig fájl, adatbázis…) Egyedi verzióval (azonosítóval) ellátva Szoftvertechnológia (VIMIAB04) 39 release: particular version of a configuration item that is made available for a specific purpose 39  Kiadások verziózása Sokféle konvenció és lehetőség, például: Semantic Versioning 2.0.0 forrás: https://semver.org/ Szoftvertechnológia (VIMIAB04) 40 Ezeket az elveket nagyon fontos betartani, hogy a mi könyvtárunkat/programunkat/szolgáltatásunkat használók számára egyértelmű legyen, hogy mi a teendőjük egy friss változat esetén. Például, ha egy új MAJOR verziót publikálunk, akkor a felhasználóinknak biztos alaposan le kell tesztelni a saját megoldásukat, és jó eséllyel módosítani is kell rajta. Nagyon komoly hiba, ha egy visszafelé nem kompatibilis változtatás esetén csak MINOR vagy PATCH verziószámot változtatunk. 40  Szoftverfejlesztés feladatai Szoftvertechnológia (VIMIAB04) 41 41  Telepítés (deploy) 954 oldal!!! Kézi telepítés (telepítési útmutató alapján) Automatizált telepítő csomag / szkriptek Infrastructure as Code (+cloud erőforrások) Szoftvertechnológia (VIMIAB04) 42 Manapság már nagyon sok program vagy alkalmazás automatizált telepítőcsomaggal érhető el (mobilalkalmazás esetén például el sem képzelhető lenne egy hosszadalmas kézi telepítési procedúra). 42  Folytonos kiszállítás [Continuous Delivery (CD)] „építsd úgy a szoftvert, hogy bármikor olyan állapotban legyen, hogy éles üzembe lehessen állítani” Forrás: https://martinfowler.com/bliki/ContinuousDelivery.html delivery pipeline Forrás Szoftvertechnológia (VIMIAB04) 43 Continous delivery: build software so that it is always in a state where it could be put into production Lásd még: Continuous Delivery vs Continuous Deployment, https://continuousdelivery.com/2010/08/continuous-delivery-vs-continuous- deployment/ 43  Szoftverfejlesztés feladatai Szoftvertechnológia (VIMIAB04) 44 44  Üzemeltetés és monitorozás Éles szoftverrendszer megfigyelése (HW, SW és üzleti metrikák) Probléma esetén riasztás (SMS, telefon – akár éjszaka…) forrás Szoftvertechnológia (VIMIAB04) 45 Sok cégnél most már az a csapat felel az adott komponense/szolgáltatás magas szintű üzemeltetéséért, aki fejleszti. Így a fejlesztőcsapat tagjai kapnak értesítést az éjszaka közepén is, ha az adott komponens nem működik (hisz ők azok, akik a legnagyobb eséllyel meg tudják javítani vagy vissza tudnak állni egy olyan állapotra, ami még működött). 45  Fejlesztői munkafolyamat Összefoglalás Szoftvertechnológia (VIMIAB04) 46 46  Tipikus fejlesztési munkafolyamat Funkció Terv Felülvizsgáló Verziókezelő rendszer Fejlesztő Éles környezet Folytonos integráció kiszolgáló Felügyelet Kódolási Statikus Egységteszt szabályok analízis Rendszerteszt E2E teszt Ikonok: icons8.com Szoftvertechnológia (VIMIAB04) 47 47  Összefoglalás Szoftvertechnológia (VIMIAB04) 48 48  Szoftvertechnológia (VIMIAB04) Verziókezelés és együttműködés Dr. Micskei Zoltán https://mit.bme.hu/~micskeiz 1  Tanulási eredmények A tananyag elsajátítása után a hallgató képes lesz (K2) összefoglalni a verziókezelő rendszerek alapfogalmait, (K3) alkalmazni a Git verziókezelő rendszert, (K2) megkülönböztetni tipikus forráskód integrációs mintákat. Szoftvertechnológia (VIMIAB04) 2 2  Szoftvertechnológia tantárgy témái Fejlesztői Követelmények Verziókezelés I. Szoftver- munka lépései kezelése fejlesztési gyakorlatok Tervezés és Jó minőségű Tesztelés és architektúra forráskód teszttervezés Miért és mit Modellezési II. Modellezés UML nyelv modellezünk? nyelvek III. Folyamatok Projekt- Mérés és Módszertanok és projektek menedzsment elemzés Szoftvertechnológia (VIMIAB04) 3 3  Tipikus fejlesztési munkafolyamat Funkció Terv Felülvizsgáló Verziókezelő rendszer Fejlesztő Éles környezet Folytonos integráció kiszolgáló Felügyelet Kódolási Statikus Egységteszt szabályok analízis Rendszerteszt E2E teszt Ikonok: icons8.com Szoftvertechnológia (VIMIAB04) 4 4  Kód integráció problémája Eddig egy fejlesztőről beszéltünk… A gyakorlatban többen párhuzamosan dolgoznak… Szoftvertechnológia (VIMIAB04) 5 5  Verziókezelés alapfogalmai commit, branch, merge… Szoftvertechnológia (VIMIAB04) 6 Nem mindegyik kifejezésnek van jól használható magyar megfelelője (pl. commit – véglegesítés?), és a Git parancsok használatakor úgyis az angol megfelelőt kell tudni, ezért ezeknek az alapfogalmaknak az angol megfelelőjét használja az előadás. 6  Vigyázat! Nincsenek univerzális fogalmak! Mindegyik verziókezelő mást ért ezeken! Szoftvertechnológia (VIMIAB04) 7 7  Verziókezelő rendszer (általánosan!) Tárhely [repository] Version Control Verziók System – VCS Fájlok vagy fájlhalmazok változtatásai Change / diff tárolva vagy állapotkép [snapshot] Checkout vagy clone (nem ugyanaz!) Commit művelet Working copy Szoftvertechnológia (VIMIAB04) 8 A kezdeti verziókezelők külön-külön kezelték az egyes fájlokat, de ez gondot okozhatott, ha egy módosítás több fájlt is érintett (például átmozgattunk egy függvényt az egyik fájlból a másikba, vagy átneveztünk egy osztályt, és ezt át kell vezetni az összes felhasználási helyén is). Ha ez a módosítás nem atomi, akkor komoly problémát okozhat (lásd az Adatbázisok és Operációs rendszerek tantárgyakat). Manapság a VCS-ekben a módosítás egysége fájlok csoportja (change list), amik közül vagy mindegyik módosítás érvényre jut vagy egyik sem. 8  Központosított és elosztott verziókezelők központosított [centralized] elosztott [distributed] Teljes történet és metaadat mindenkinél. Teljes történet csak a központi szerveren! Lokálisan gyorsan bármit módosíthatunk. Ütközések kezelése: pl. zárolás [locking] Ütközések kezelése csak ha kialakul. Szoftvertechnológia (VIMIAB04) 9 Központosított esetben: - A fejlesztők helyi gépén tipikusan csak egy adott verzióhoz tartozó fájlok vannak letöltve. - A konfliktusok elkerülése érdekében zárolást lehet használni: valamelyik fejlesztő zárt rak egy elemre (és esetleg annak az összes gyerekére), és olyankor más nem írhatja azt, csak olvashatja. Így biztos elkerüljük az ütközéseket [conflict], de akár indokolatlanul sokáig nem tudja más azt a fájlt módosítani, és blokkolja a munkáját. Ez egy pesszimista stratégia (lásd az Adatbázisok és a Szoftvertechnikák tárgyakat!). A modern központosított verziókezelők már általában nem használnak zárakat, de még előfordulnak ilyen rendszerek. Elosztott esetben: - Mindenkinek a teljes tárhely megvan az összes fájl összes verziójával és az összes metaadattal, így bármikor bárki bármelyik változatra vissza tud állni. Bármilyen lokális módosítás gyors, mert nem kell a központi szerverrel kommunikálni. - Nincs kitüntetett központi változat, így nincs olyan, hogy a hiteles vagy a legfrissebb változat. Bárki elküldhet változtatásokat bárkinek, és akkor kell csak kezelni az ütközésekkel, ha ténylegesen ki is alakulnak (optimista stratégia). - A gyakorlatban azonban sok elosztott verziókezelőt használó projektben is kineveznek egy speciális tárhelyet, amihez a többiek igazodnak (például Git esetén sokan igénybe veszik a GitHub-ot vagy GitLab-ot, hogy az ő szervereiken tárolt tárhely legyen az, amihez mindenki igazodhat). 9  Alapfogalmak: codeline, commit és branch head / tip (legutolsó commit) commit: összetartozó változtatások metaadattal; különbséget megadja C1 C2 C3 codeline: commit-ok rendezett sorozata branch: egy codeline, tipikusan akkor B1 hozunk létre új branch-et, ha valamin elkezdünk párhuzamosan dolgozni trunk/mainline: kezdőállapotból induló C1 C2 C3 branch, ezt tekintjük a közös állapotnak integration: több branch változtatásainak B1 „összefésülése” [merge] conflict: ha két branch ugyanazt a fájlt C1 C2 C3 változtatta vagy szemantikai ütközést okoz Szoftvertechnológia (VIMIAB04) 10 A branch [ág] kifejezéssel érdemes vigyázni, mert az egyes verziókezelő rendszerek teljesen mást értenek alatta! Commit és branch angolban ige és főnév is! Commit metaadat: ki csinálta, mikor, milyen üzenetet adott hozzá… Integrate helyett általában a merge szót használjuk, viszont például a Git-ben az csak egy fajta módja az integrálásnak (lehet rebase-elni is). Szemantikai ütközés [semantic conflict]: ha az egyik fejlesztő megváltoztatja az A osztály m1() metódusának nevét m2()-re és a másik fejlesztő ír egy új B osztályt, ami A-nak még m1() néven hívja a metódusát, akkor nem lesz fájl szintű ütközés, de integráció után a kód nem fog fordulni. A verziókezelő szoftver ezt általában nem tudja automatikusan észre venni, csak később derül ki. 10  Elosztott verziókezelő és elágazás Elosztott verziókezelőnél mindig több párhuzamos ág van! (alapértelmezetten, akkor is, ha nem készítek külön ágat!) Saját, lokális tárhely main ága (klónozás és módosítások után) Kijelölt tárhely main ága (pl. GitHub szerverén lévő tárhely) forrás Szoftvertechnológia (VIMIAB04) 11 Ha többen dolgozunk, akkor mindenkinek a helyi tárhelyében lesz egy változat a main ágból. Ha a saját példányán valaki változtat, akkor mindenképp integrálni kell, hogy a többiek is lássák azt. 11  Git verziókezelő rendszer Forrás: S. Chacon, B. Straub. Pro Git, 2nd edition, 2014 Szoftvertechnológia (VIMIAB04) 13 Ez a szakasz a Pro Git könyv ábráit fogja használni az alapfogalmak bemutatásához. 13  Git in 100 seconds Jeff Delaney (@Fireship): Git Explained in 100 Seconds Szoftvertechnológia (VIMIAB04) 14 14  Git verziókezelő rendszer Új VCS kifejezetten a Linux kernel támogatására (2005-) Tervezési célok – Elosztott működés – Olcsó, kényelmes branch kezelés – Gyors működés nagy tárhelyen is – Adat- és integritásvédelem Szoftvertechnológia (VIMIAB04) 15 15  Git: állapotképek [snapshot] tárolása Minden verzió teljes állapotot eltárol Nem változott fájlokat nem duplikálja Szoftvertechnológia (VIMIAB04) 16 16  Helyi tárhely részei munkakönyvtár érkeztető terület.git könyvtár [working directory] [staging area] (tárhely) Teljes történet, Aktuális állapot, amin checkout vagy switch összes változás dolgozunk. (speciális Ebben változtathatók adatstruktúrák) a fájlok, könyvtárak! add commit Szoftvertechnológia (VIMIAB04) 17 17  Fájlok lehetséges állapotai Forrás Szoftvertechnológia (VIMIAB04) 18 18  Commit: snapshot és metaadat együtt Commit azonosítója: Kezdeti Szülő: sorrend megadása SHA-1 hash checksum commit Belső adatszerkezet: objektum, fa… Szoftvertechnológia (VIMIAB04) 19 19  Git: Commit és branch HEAD: speciális mutató (helyi munkaterület hol áll épp) Új commit mozgatja master: init által létrehozott első branch (átállítható, pl. main) Branch: mozgatható mutató egy commitra Szoftvertechnológia (VIMIAB04) 20 Másik branch-re váltás esetén a working directory tartalmát átállítja a Git az adott branch-hez tartozó commit snapshot-jára. A working directory mindig egy állapotot tud megmutatni, a branch-et váltó vagy a commit parancsok tudják ezt az állapotot változtatni. 20  DEMO: Git alapok Szoftvertechnológia (VIMIAB04) 21 DEMO főbb lépései: - Helyi repository inicializálása - Fájlok hozzáadása és commit-álás - Státusz és commit történet megtekintése -.git könyvtár tartalma, belső adatszerkezetek és hivatkozások - Ágak kezelése, új ág létrehozása - Ágak integrálása, konfliktus feloldása 21  Legfontosabb Git parancsok (1) Üres tárhely inicializálása Távoli tárhely klónozása (teljes) Lokális munkaterület állapota Fájl követése és commit-olása Szoftvertechnológia (VIMIAB04) 22 22  Legfontosabb Git parancsok (2) Nem követett és módosított fájlok esetén az állapot Szoftvertechnológia (VIMIAB04) 23 23  Legfontosabb Git parancsok (3) Commit történet megtekintése [commit history] Commit hash Commit üzenet Szoftvertechnológia (VIMIAB04) 24 24  Legfontosabb Git parancsok (4) Távoli [remote] tárhely lekérdezése Távoli tárhely változásainak lekérése Távoli tárhely hozzáadása Helyi tárhely változásainak elküldése Szoftvertechnológia (VIMIAB04) 25 25  Commit tanácsok Rossz példa: mit csináltunk itt? commit == összetartozó változáshalmaz → inkább sok, kisebb commit Git commit üzenet ajánlás Jó példa: követhető történet Szoftvertechnológia (VIMIAB04) 26 Gyakori, kis commit-ok segítenek abban, hogy mindig végig gondoljuk, hogy mit csináltam épp most és mit szeretnék ezután most csinálni. Segít a többieknek megérteni a munkánkat és indokainkat, és később egy esetleges hibakeresés is sokkal könnyebb, ha be tudjuk határolni, hogy egy néhány dolgot változtató commit elején jelent meg a hiba. 26  További git funkciók Tag – Commit megjelölése címkével – Annotated tag: megjelölés név, email, üzenet, új hash – Pl.: kiadás megjelölése (1.0.0) Git hook – Szkriptek lefuttatása adott események esetén – Pl.: Pre-commit checks – tesztek, kód stílus ellenőrzése (ha nem sikeres a check, akkor nem commit-olható a változtatás!) Szoftvertechnológia (VIMIAB04) 27 27  Verziókezelési és együttműködési minták Forrás: M. Fowler. „Patterns for Managing Source Code Branches” Szoftvertechnológia (VIMIAB04) 28 Különböző integrációs mintákat és ezekből építkező együttműködési folyamatokat fogunk megnézni. 28  Alap minta: Mainline Mainline: Egy megosztott ág, ami a termék aktuális állapotaként szolgál „Single Source of Truth” Ebből indulhat ki mindenki, ide tölti fel a jóváhagyott változást Elosztott VCS: sokszor egy tárhely ki van jelölve mainline-nak! (pl. cég k