Kódfelülvizsgálat

A Wikipédiából, a szabad enciklopédiából

A kódfelülvizsgálat (amit néha szoktak egyenrangú felülvizsgálatnak is nevezni) olyan szoftverbiztonsági tevékenység, amiben egy vagy több ember ellenőriz egy programot, főként a néző és olvasó forráskódjának részeit az implementáció után, vagy pedig az implementáció félbeszakításaként. A személyek közül, akik a kódáttekintést végzik, legalább egyikőjüknek nem szabad a kód szerzőjének lennie. Azok a személyek, akik végrehajtják az ellenőrzést, kivéve a szerzőt, bírálóknak, felülvizsgálóknak nevezzük.[1]

Bár a minőségi problémák felfedezése gyakran a fő cél, a kód áttekintést általában többféle cél elérése érdekében végzik:[2]

  • Jobb kódminőség - a kód belső minőségének és karbantarthatóságának javítása (olvashatóság, egységesség, érthetőség stb.)
  • Hiányok megtalálása - a minőség javítása külső szempontok tekintetében, különösen a helyesség tekintetében, de teljesítményproblémák, biztonsági sebezhetőségek, bejuttatott rosszindulatú programok is megtalálhatók.
  • Tudás átvitele - segít a kódbázisra, a megoldási megközelítésekre, a minőséggel kapcsolatos elvárásokra stb. vonatkozó ismeretek átadásában; mind a bírálók, mind a szerző számára.
  • A kölcsönös felelősségérzet növelése - a közös kódtulajdonlás és a szolidaritás érzésének erősítése.
  • Jobb megoldást találni - új ötletek felszínre hozása új és jobb megoldások érdekében, amelyek felülmúlják a vizsgált kód megoldásait.
  • A Q/A irányelveknek teljesítése, ISO/IEC standardok - A kódok felülvizsgálata bizonyos kontextusokban kötelező, pl. légiforgalmi szoftverek, biztonságkritikus szoftverek esetében.

A fent említett kódvizsgálat definíciója elhatárolja a szomszédos, de különálló szoftverminőségi biztosítási technikáktól: A statikus kódelemzésnél a fő ellenőrzést egy automatizált program végzi, az önellenőrzés esetében csak a szerző ellenőrzi a kódot, a tesztelés a kód végrehajtás szerves része, a páros programozás pedig a megvalósítás során folyamatosan, és nem külön lépésként történik

Felülvizsgálati típusok[szerkesztés]

A kódáttekintő eljárásoknak sokféle variációja van, ami közül néhányat a későbbiekben részletezünk. A további áttekintő típusok az IEEE1028 részét képezik.

Az IEEE1028-2008 lista a következő típusokat foglalja magába:[3]

  • Vezetőségi felülvizsgálatok
  • Műszaki felülvizsgálatok
  • Ellenőrzések
  • Átjárók
  • Ellenőrzések

Vizsgálat (formális)[szerkesztés]

Történelmileg ez az első kód áttekintő eljárás, amit részletesen tanulmányoztak és leírtak, amit úgy hívtak „Vizsgálat” (Inspection), melynek feltalálója Michael Fagan.[4] Ez a Fagan-féle vizsgálat egy formális folyamat, amely gondos és részletes, több résztvevővel és több fázisban történő végrehajtást foglal magában. A formális kódellenőrzés a felülvizsgálat hagyományos módszere, amelynek során a szoftverfejlesztők egy sor megbeszélésen vesznek részt, és soronként vizsgálják át a kódot, általában az anyag nyomtatott példányait használva. A formális felülvizsgálatok rendkívül alaposak, és bizonyítottan hatékonyak a hibák felderítésében a vizsgált kódban.[4]

Rendszeres változásalapú kódellenőrzés (áttekintés)[szerkesztés]

Az utóbbi években számos ipari csapat bevezette a kódellenőrzés egy könnyebb típusát.[5][6]Fő jellemzője, hogy az egyes felülvizsgálatok terjedelme a kódbázisban egy jegyben, felhasználói történetben, commit-ban vagy más munkaegységben végrehajtott változásokon alapul. Továbbá vannak olyan szabályok vagy konvenciók, amelyek a felülvizsgálati feladatot a fejlesztési folyamatba ágyazzák (pl. "minden jegyet felül kell vizsgálni"), ahelyett, hogy minden egyes felülvizsgálatot kifejezetten megterveznének. Az ilyen felülvizsgálati folyamatot rendszeres, változás alapú kód felülvizsgálatnak nevezik.[7] Ennek az alapfolyamatnak számos változata létezik. Egy 2017-es 240 fejlesztőcsapat körében végzett felmérés szerint a csapatok 90%-a használ változtatásokon alapuló felülvizsgálati folyamatot (ha egyáltalán használnak felülvizsgálatot), 60% pedig rendszeres, változásalapú kód ellenőrzést. Emellett a legtöbb nagy szoftvercég, például a Microsoft,[8] a Google,[9] és a Facebook is változásalapú kód felülvizsgálati folyamatot alkalmaz.

A felülvizsgálatok hatékonysága és eredményessége[szerkesztés]

A Capers Jones több mint 12 000 szoftverfejlesztési projektjének folyamatos elemzése azt mutatta, hogy a formális ellenőrzés során a rejtett hibák felfedezési aránya 60-65% között van. Az informális ellenőrzés esetében ez az arány kevesebb, mint 50%. A tesztelés legtöbb formája esetében a látens hibák felfedezési aránya 30% körül van.[10] [11] A Best Kept Secrets of Peer Code Review című könyvben közzétett kódvizsgálati esettanulmány szerint a könnyített felülvizsgálatok ugyanannyi hibát fedeznek fel, mint a formális felülvizsgálatok, de gyorsabbak és költséghatékonyabbak,[12] ami ellentmond a Capers Jones által végzett tanulmánynak.

A többi fajta hiányosságokat, amiket a kód áttekintésben felfedeztek még ma is tanítják.A kódáttekintések során feltárt hibák típusait is vizsgálták. Empirikus tanulmányok bizonyították, hogy a kódvizsgálati hibák akár 75%-a inkább a szoftver fejleszthetőségét/fenntarthatóságát, mint a funkcionalitást érinti,[13] [14] [15] [16] ami a kódvizsgálatokat kiváló eszközzé teszi a hosszú termék- vagy rendszer-életciklusú szoftvercégek számára.[17] Ez azt is jelenti, hogy a kódvizsgálatok során megvitatott problémák kevesebb, mint 15%-a kapcsolódik hibákhoz.[18]

Irányelvek[szerkesztés]

Megállapították, hogy a kódellenőrzés hatékonysága a felülvizsgálat sebességétől függ. A kód felülvizsgálati sebességnek óránként 200 és 400 kódsor között kell lennie.[19] [20] [21] [22] Kritikus szoftverek (például biztonságkritikus beágyazott szoftverek) esetében az óránkénti néhány száz kódsornál több kódsor vizsgálata és felülvizsgálata túl gyors lehet a hibák megtalálásához.[23]

Támogató eszközök[szerkesztés]

A statikus kódelemző szoftverek a forráskód szisztematikus, ismert sebezhetőségek és hibatípusok szisztematikus ellenőrzésével csökkentik a nagy mennyiségű kód felülvizsgálatának a fejlesztőre háruló feladatát.[24] A VDC Research 2012-es tanulmánya szerint a megkérdezett szoftvermérnökök 17,6 %-a használ jelenleg automatizált eszközöket a szakértői kódellenőrzés támogatására, és 23,7 %-uk számít arra, hogy 2 éven belül használni fogja őket.[25]

Jegyzetek[szerkesztés]

 

  1. Kolawa, Adam. Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press, 260. o. (2007). ISBN 978-0-470-04212-0 
  2. Baum, Tobias. Factors Influencing Code Review Processes in Industry, Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering - FSE 2016, 85–96. o.. DOI: 10.1145/2950290.2950323 (2016. április 26.). ISBN 9781450342186 
  3. IEEE Standard for Software Reviews and Audits”. DOI:10.1109/ieeestd.2008.4601584.  
  4. a b (1976. április 26.) „Design and code inspections to reduce errors in program development”. IBM Systems Journal 15 (3), 182–211. o. DOI:10.1147/sj.153.0182.  
  5. Rigby, Peter. Convergent contemporary software peer review practices, 202. o.. DOI: 10.1145/2491411.2491444 (2013. április 26.). ISBN 9781450322379 
  6. Baum, Tobias. The Choice of Code Review Process: A Survey on the State of the Practice, Lecture Notes in Computer Science, 111–127. o.. DOI: 10.1007/978-3-319-69926-4_9 (2017. április 26.). ISBN 978-3-319-69925-7 
  7. Baum, Tobias. A Faceted Classification Scheme for Change-Based Industrial Code Review Processes, 2016 IEEE International Conference on Software Quality, Reliability and Security (QRS), 74–85. o.. DOI: 10.1109/QRS.2016.19 (2016. április 26.). ISBN 978-1-5090-4127-5 
  8. MacLeod (2017. április 26.). „Code Reviewing in the Trenches: Challenges and Best Practices”. IEEE Software 35 (4), 34. o. DOI:10.1109/MS.2017.265100500. (Hozzáférés: 2020. november 28.)  
  9. Sadowski (2018. április 26.). „Modern Code Review: A Case Study at Google”. International Conference on Software Engineering, Software Engineering in Practice Track, 181. o. DOI:10.1145/3183519.3183525.  
  10. Jones: Measuring Defect Potentials and Defect Removal Efficiency. Crosstalk, The Journal of Defense Software Engineering, 2008. június 1. [2012. augusztus 6-i dátummal az eredetiből archiválva]. (Hozzáférés: 2010. október 5.)
  11. Jones (2009. április 1.). „Embedded Software: Facts, Figures, and Future”. Computer 42 (4), 42–52. o. DOI:10.1109/MC.2009.118.  
  12. Jason Cohen. Best Kept Secrets of Peer Code Review (Modern Approach. Practical Advice.). Smart Bear Inc. (2006). ISBN 978-1-59916-067-2 
  13. Czerwonka (2015). „Code Reviews Do Not Find Bugs. How the Current Code Review Best Practice Slows Us Down”. ICSE '15: Proceedings of the 37th International Conference on Software Engineering 2, 27–28. o. DOI:10.1109/ICSE.2015.131. (Hozzáférés: 2020. november 28.)  
  14. Mantyla (2009). „What Types of Defects Are Really Discovered in Code Reviews?”. IEEE Transactions on Software Engineering 35 (3), 430–448. o. DOI:10.1109/TSE.2008.71. (Hozzáférés: 2012. március 21.)  
  15. Bacchelli: Expectations, outcomes, and challenges of modern code review. Proceedings of the 35th IEEE/ACM International Conference On Software Engineering (ICSE 2013), 2013. május 1. (Hozzáférés: 2015. szeptember 2.)
  16. Beller: Modern code reviews in open-source projects: which problems do they fix?. Proceedings of the 11th Working Conference on Mining Software Repositories (MSR 2014), 2014. május 1. (Hozzáférés: 2015. szeptember 2.)
  17. Siy: Does the Modern Code Inspection Have Value?. unomaha.edu, 2004. december 1. [2015. április 28-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. február 17.)
  18. Bosu: Characteristics of Useful Code Reviews: An Empirical Study at Microsoft. 2015 IEEE/ACM 12th Working Conference on Mining Software Repositories, 2015. május 1. (Hozzáférés: 2020. november 28.)
  19. Kemerer (2009. április 17.). „The Impact of Design and Code Reviews on Software Quality: An Empirical Study Based on PSP Data”. IEEE Transactions on Software Engineering 35 (4), 534–550. o. DOI:10.1109/TSE.2009.27.  
  20. Code Review Metrics. Open Web Application Security Project. Open Web Application Security Project. [2015. október 9-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. október 9.)
  21. Best Practices for Peer Code Review. Smart Bear. Smart Bear Software. [2015. október 9-i dátummal az eredetiből archiválva]. (Hozzáférés: 2015. október 9.)
  22. Bisant (1989. október 1.). „A Two-Person Inspection Method to Improve Programming Productivity”. IEEE Transactions on Software Engineering 15 (10), 1294–1304. o. DOI:10.1109/TSE.1989.559782. (Hozzáférés: 2015. október 9.)  
  23. Ganssle: A Guide to Code Inspections. The Ganssle Group, 2010. február 1. (Hozzáférés: 2010. október 5.)
  24. Balachandran, Vipin. Reducing human effort and improving quality in peer code reviews using automatic static analysis and reviewer recommendation, 2013 35th International Conference on Software Engineering (ICSE), 931–940. o.. DOI: 10.1109/ICSE.2013.6606642 (2013). ISBN 978-1-4673-3076-3 
  25. VDC Research: Automated Defect Prevention for Embedded Software Quality. VDC Research, 2012. február 1. (Hozzáférés: 2012. április 10.)

Fordítás[szerkesztés]

Ez a szócikk részben vagy egészben a Code review című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

Kapcsolódó szócikkek[szerkesztés]

További információk[szerkesztés]