Kódrefaktorálás

A Wikipédiából, a szabad enciklopédiából
Ugrás a navigációhoz Ugrás a kereséshez

A kódrefaktorálás a meglévő számítógépes kód átalakításának folyamata - a felépítés megváltoztatása - a külső viselkedésének megváltoztatása nélkül. A refaktorálás célja a szoftver (nem funkcionális tulajdonságai) tervezésének, felépítésének és/vagy implementációjának javítása, miközben megőrzi a szoftver funkcionalitását. A kódrefaktorálás potenciális előnyei közé tartozik, hogy fejlessze a kód olvashatóságát és csökkentse a bonyolultságát; ezek segítségével könnyebben karbantarthatjuk a forráskódot, és egyszerűbb, letisztultabb vagy kifejezőbb belső architektúrát vagy objektummodellt hozhatunk létre a bővíthetőség javítása érdekében.

Jellemzően refaktorálás közben szabványosított kisebb változtatások sorozatát (micro-refactoring) alkalmazzák, amelyek mindegyike (általában) egy apró változást jelent a számítógépes program forráskódjára, amely megőrzi a szoftver viselkedését, vagy legalábbis nem változtatja meg a funkcionális követelményeknek való megfelelését. Számos fejlesztési környezet automatizált támogatást nyújt ezen alapvető refaktorok mechanikai szempontjainak végrehajtásához. Ha jól hajtják végre, akkor a kódrefaktorálás segíthet a szoftverfejlesztőknek a rendszerben nyugvó hibák vagy biztonsági rések felfedezésében és kijavításában, az alapjául szolgáló logika egyszerűsítésével, és a szükségtelen bonyolultsági szintek kiküszöbölésével. Ha rosszul van végrehajtva, akkor megváltoztathatja a szoftver funkcionalitását, újabb hibákat idézhet elő, vagy mindkettő.

„A kód kinézetének folyamatos fejlesztésével, egyre egyszerűbbé és egyszerűbbé tesszük a munkát vele. Ez éles ellentétben áll azzal ami általában történik: kevés refaktorálással, és nagy figyelemmel történő újítások célszerű implementálása. Ha ráérzel a folyamatos refaktorálás higiénikus szokásába, rájössz, hogy sokkal könyebb bővíteni és karbantartani a kódot.”
   – Joshua Kerievsky, Refactoring to Patterns[1]

Motiváció[szerkesztés]

A refaktorálást általábán a kód bűzének[2] észrevétele motiválja. Például, a rendelkezésre álló módszer túl hosszú lehet, de az is lehet, hogy egy másik módszer közeli duplikációja. Amint felismerték, ezeket a problémákat a forráskód refaktorálásával, vagy új formává alakításával lehet megoldani, amely ugyanúgy viselkedik, mint korábban, de már nem "bűzlik".

Egy hosszabb rutint egy vagy több kisebb alrutinra bonthatunk; vagy duplikált rutinok esetén a másolat eltávolítható és helyettesíthető egy megosztott funkcióval. A refaktorálás elmulasztása technikai adósság halmozódását eredményezheti; másrészről a refaktorálás a technikai adósság visszafizetésének egyik elsődleges eszköze.[3]

Előnyök[szerkesztés]

A refaktorálás előnyeinek két általános kategóriája van.

  1. Karbantarthatóság. A hibák javítása könnyebb, mivel a forráskód könnyen olvasható, és a szerző szándéka könnyen megragadható.[4] Ezt úgy lehet elérni, hogy a nagyméretű monolitikus eljárásokat egyedileg tömör, jól megnevezett, egycélú módszerek sorozatává redukálják. Ezt pedig úgy lehet elérni, ha egy módszert egy megfelelőbb osztályba helyezünk, vagy eltávolítjuk a félrevezető megjegyzéseket.
  2. Bővíthetőség. Az alkalmazás adottságait könnyebb kibővíteni, ha felismerhető tervezési mintákat használ, és bizonyos rugalmasságot biztosít, ott, ahol korábban még nem létezett.[5]

Kihívások[szerkesztés]

A refaktoráláshoz szét kell szedni a szoftverrendszer felépítését, az adatmodelleket és az alkalmazáson belüli függőségeket, hogy megszerezzük a meglévő szoftverrendszer ismereteit[6]. A csapatok forgalma azt jelenti, hogy hiányoznak, vagy pontatlan ismeretek vannak a rendszer jelenlegi állapotáról és a fejlesztők tervezési döntéseiről. A további kódmegújítási tevékenységek további erőfeszítéseket igényelhetnek ezen ismeretek visszanyerése érdekében.[7] A refaktoráló tevékenységek arhitektúrális módosításokat generálnak, amelyek rontják a szoftverrendszer szerkezeti felépítését. Ez a romlás befolyásolja az arhitektúrális tulajdonságokat, például a karbantarthatóságot és az áttekinthetőséget, amelyek a szoftver rendszerek teljes újrafejlesztéséhez vezethetnek.[8]

A kódrefaktoráló tevékenységeket szoftver intelligencia biztosítja, amik eszközöket és technikákat használnak, amelyek adatokat szolgáltatnak a kódfuttatás algoritmusairól és szekvenciáiról[9]. A szoftverrendszer felépítésének, az adatmodellek és az összetevőkön belüli függőségek belső állapotának áttekinthető formátumának biztosítása kritikus része a magas szintű megértés kialakulásának, mivel ez alapján megtudjuk, hogy mit kell módosítani, és hogyan.[10]

Tesztelés[szerkesztés]

Az automatikus egységteszteket be kell állítani a refaktorálás előtt, hogy a rutinok továbbra is a várt módon viselkedjenek.[11] Az egységteszt stabilitást eredményezhet még nagy refaktorálás esetén is, ha egyetlen atomi elkötelezettséggel hajtják végre. Gyakori stratégia a több projektet átfogó biztonságos elemi refaktorálások lehetővé tételére, hogy az összes projektet egyetlen monorepo[12] nevű repositoryban tároljuk.

Az egységtesztek végrehajtása során a refaktorálás egy iteratív ciklus formájában jelenik meg, amely során elvégzünk egy apró kódváltoztatást, teszteléssel megbizonyosodunk róla, hogy ez nem okozott hibát a rendszerben, majd újabb apró változtatásokat végzünk el. Ha egy teszt bármely pontján kudarcot vall, akkor az utolsó apró változtatást visszavonják és más módon kell megismételni. Sok apró lépéssel a program a kiindulási pontból eljut arra a pontra, ahol szeretnénk hogy legyen. Ahhoz, hogy ez a nagyon iteratív folyamat praktikus legyen, a teszteket nagyon gyorsan kell lefuttatni, különben a programozók az idejük nagy részét a tesztek végrehajtására fordítanák. Az extrém programozás és más agilis szoftverfejlesztések támogatói ezt a tevékenységet a szoftverfejlesztési ciklus szerves részeként írják le.

Technikák[szerkesztés]

Íme néhány példa a mikrorefaktorokra; ezek közül néhány csak bizonyos nyelvekre vagy nyelvtípusokra vonatkozik. Hosszabb lista megtalálható Martin Fowler refaktorkönyvében és a weboldalon.[13] Számos fejlesztési környezet automatizált támogatást nyújt ezeknek a mikro-refaktoroknak. Például egy programozó rákattinthat egy változó nevére, majd a helyi menüből kiválaszthatja az „Encapsulate field” refaktoráló funkciót. A fejlesztői környezet ezután további részleteket kér, általában ésszerű alapértelmezésekkel és a kódváltozások előnézetével. Miután a programozó megerősítette, elvégzi a szükséges változtatásokat a kód egészében.

  • Technikák, amelyek lehetővé teszik a megértést
    • Programfüggőségi gráf - az adatok és a vezérlőfüggőségek explicit ábrázolása[14]
    • Rendszerfüggési grafikon - a programfüggőségi gráfok közötti eljáráshívások ábrázolása[15]
    • Szoftver intelligencia - Segít megérteni az alkalmazáson belüli függőségeket
  • További absztrakciót lehetővé tevő technikák
    • Mező egységbe zárása - rákényszeríti a kódot, hogy a mezőt getter és setter metódusokkal lehessen elérni.
    • Általánosítsa a típust - hozzon létre általánosabb típusokat a további kódmegosztás érdekében
    • Cserélje ki a típusellenőrző kódot állapotra/stratégiára[16]
    • Cserélje le a feltételt polimorfizmussal[17]
  • A kód logikusabb részekre bontásának technikája
    • A komponensek a kódot újrafelhasználható szemantikai egységekre bontják, amelyek tiszta, jól definiált, egyszerűen használható felületeket tartalmaznak.
    • Az extrakciós osztály a kód egy részét egy meglévő osztályból egy új osztályba mozgatja.
    • Kivonási módszer: egy nagyobb metódus egy részének új metódussá alakítása. A kód kisebb részekre bontásával könnyebben érthető. Ez a funkciókra is alkalmazható.
  • Technikák a nevek és a kód helyének javítására
    • Módszer vagy mező áthelyezése - áthelyezés egy megfelelőbb osztály- vagy forrásfájlba
    • Metódus vagy mező átnevezése - a név megváltoztatása olyanra, amely jobban feltárja a célját
    • Pull up - objektum-orientált programozásban (OOP), áthelyezés szülő osztályba
    • Push down - az OOP-ban, áthelyezés gyerekosztályba[11]
  • Automatikus klóndetektálás[18]

Hardver-refaktorálás[szerkesztés]

Míg a refaktorálás kifejezés eredetileg kizárólag a szoftverkód refaktorálására utalt, az utóbbi években a hardverleíró nyelveken (HDL) írt kódot is refaktorálták. A hardver-refaktorálás kifejezést rövidített kifejezésként használják a kód hardverleíró nyelveken történő refaktorálására. Mivel a hardver mérnökök[19] többsége szerint a HDL nem tekinthető programozási nyelvnek, a hardver-refaktorálásra egy külön területként tekintünk, mint a hagyományos kódrefaktorálásra.

Az analóg hardverleírások (VHDL-AMS-ben) automatikus refaktorálását Zeng és Huss[20] javasolta. Megközelítésük szerint a refaktorálás megőrzi a hardveres tervezés szimulált viselkedését. A nem funkcionális mérés az, hogy a refaktorált kód standard szintézis eszközökkel feldolgozható, az eredeti kód viszont nem. A digitális HDL-ek refaktorálását, habár kézi refaktorálást, szintén a Synopsys munkatársa, Mike Keating vizsgálta.[21] [22] Célja, hogy a komplex rendszerek megértését könnyebbé tegye, ami növeli a tervezők produktivitását.

Története[szerkesztés]

Bár a kódrefaktorálás informálisan évtizedek óta jelen volt, William Griswold 1991-es Ph.D. disszertációja[23] az egyik elsõ nagyobb tudományos munka a funkcionális és a procedurális programok refaktorálásáról. William Opdyke1992-es disszertációja[24] az objektumorientált programok refaktorálásáról[25] szólt, bár az elmélet és a technika már régóta elérhető volt program transzformációs rendszerekként. Mindezek az erőforrások katalógust adnak a refaktorálás általános módszereiről; egy refactoring módszer leírja, hogyan kell alkalmazni a módszert, és megmondja, mikor kell (vagy nem kell) alkalmazni a módszert.

Martin Fowler könyve, Refactoring: Improving the Design of Existing Code[26] a kánoni referencia.

A "refaktorálás" kifejezés első ismert használata a publikált irodalomban 1990. szeptemberi cikkben készült, melyet William Opdyke és Ralph Johnson írt.[27] Griswold Ph.D. tézise,[28] valamint Opdyke 1992-ben publikált PhD-tézise[29] szintén ezt a kifejezést használja.[25]

A "faktoring" és a "faktoring out" kifejezéseket ilyen módon használják a Forth közösségben legalább az 1980-as évek eleje óta. Leo Brodie Thinking Forth (1984) könyvének[30] hatodik fejezetét a témának szentelték.

Extrém programozás esetén az Extract Method refactoring technika lényegében ugyanazt jelenti, mint a faktoring Forth-ben; hogy egy "szót" (vagy függvényt) kisebb, könnyebben karbantartható funkciókra bonthassanak.

A refaktorálásokat rekonstruálhatjuk[31] posthoc alatt is, hogy tömör leírást adhassunk a szoftver verziókövető rendszerekben, például a CVS-ben vagy az SVN-ben rögzített komplex szoftverváltozásokról.

Automatizált kódrefaktorálás[szerkesztés]

Számos szoftver- szerkesztőnek és fejlesztői környezetnek van automatikus refaktorálás támogatása. Lehetséges az alkalmazáskód és a tesztkód refaktorálása is.[32] Itt található néhány ilyen szerkesztő vagy úgynevezett refaktoráló böngésző.

Lásd még[szerkesztés]

  • Javítási minta
  • Kód felülvizsgálata
  • Adatbázis-refaktiválás
  • Bomlás (informatika)
  • Moduláris programozás
  • Eltűnt kód
  • Prefactoring
  • Az aggodalmak szétválasztása
  • Szoftver szakértői értékelés
  • Tesztvezérelt fejlesztés

Jegyzetek[szerkesztés]

  1. Kerievsky, Joshua. Refactoring to Patterns. Addison Wesley (2004) 
  2. Fowler, Martin. Refactoring. Improving the Design of Existing Code. Addison-Wesley, 63ff. o. (1999). ISBN 978-0-201-48567-7 
  3. Suryanarayana, Girish. Refactoring for Software Design Smells. Morgan Kaufmann, 258. o. (2014. november 1.). ISBN 978-0128013977 
  4. Martin, Robert. Clean Code. Prentice Hall (2009) 
  5. Haendler (2019. szeptember 4.). „A Framework for the Assessment and Training of Software Refactoring Competences”. Proc. Of 11th International Conference on Knowledge Management and Information Systems (KMIS)..  
  6. Nassif (2017. november 1.). „Revisiting turnover-induced knowledge loss in software projects”. 2017 IEEE International Conference on Software Maintenance and Evolution (ICSME), 261–272. o. DOI:10.1109/ICSME.2017.64.  
  7. van Gurp (2002. március 1.). „Design erosion: problems and causes”. Journal of Systems and Software 61 (2), 105–119. o. DOI:10.1016/S0164-1212(01)00152-2.  
  8. Hassan (2010. november 1.). „Software intelligence: the future of mining software engineering data”. In Proceedings of the FSE/SDP Workshop on Future of Software Engineering Research (FoSER '10), 161–166. o. DOI:10.1145/1882362.1882397.  
  9. Novais (2017. szeptember 4.). „Experimentally assessing the combination of multiple visualization strategies for software evolution analysis”. Journal of Systems and Software 128, 56–71. o. DOI:10.1016/j.jss.2017.03.006.  
  10. 1963-, Fowler, Martin. Refactoring : improving the design of existing code. Reading, MA: Addison-Wesley (1999. szeptember 4.). ISBN 978-0201485677. OCLC 41017370 
  11. a b (these are only about OOP however).Refactoring techniques in Fowler's refactoring Website
  12. Java Power Tools (en nyelven). "O'Reilly Media, Inc.", 301. o. (2008. szeptember 4.). ISBN 9781491954546. Hozzáférés ideje: 2018. július 26. 
  13. (these are only about OOP however).Refactoring techniques in Fowler's refactoring Website
  14. Ferrante (1987. július 1.). „The program dependence graph and its use in optimization”. ACM Transactions on Programming Languages and Systems 9 (3), 319–349. o, Kiadó: ACM. DOI:10.1145/24039.24041.  
  15. Donglin (2008. november 1.). „Slicing objects using system dependence graphs”. Proceedings. International Conference on Software Maintenance, 319–349. o, Kiadó: IEEE. DOI:10.1109/ICSM.1998.738527.  
  16. Replace type-checking code with State/Strategy
  17. Replace conditional with polymorphism
  18. Bruntink, Magiel, et al. "An evaluation of clone detection techniques for crosscutting concerns." Software Maintenance, 2004. Proceedings. 20th IEEE International Conference on. IEEE, 2004.
  19. Hardware description languages#HDL and programming languages
  20. Kaiping Zeng, Sorin A. Huss, "Architecture refinements by code refactoring of behavioral VHDL-AMS models". ISCAS 2006
  21. M. Keating :"Complexity, Abstraction, and the Challenges of Designing Complex Systems", in DAC'08 tutorial "Bridging a Verification Gap: C++ to RTL for Practical Design"
  22. M. Keating, P. Bricaud: Reuse Methodology Manual for System-on-a-Chip Designs, Kluwer Academic Publishers, 1999.
  23. Opdyke, William F (June 1992), Refactoring Object-Oriented Frameworks, University of Illinois at Urbana-Champaign, <https://web.archive.org/web/20191216212919/https://dl.acm.org/citation.cfm?id=169783>. Hozzáférés ideje: 2008-02-12
  24. Opdyke, William F (June 1992), Refactoring Object-Oriented Frameworks, University of Illinois at Urbana-Champaign, <https://web.archive.org/web/20191216212919/https://dl.acm.org/citation.cfm?id=169783>. Hozzáférés ideje: 2008-02-12
  25. a b Martin Fowler, "MF Bliki: EtymologyOfRefactoring"
  26. Fowler, Martin. Refactoring. Improving the Design of Existing Code. Addison-Wesley, 63ff. o. (1999). ISBN 978-0-201-48567-7 
  27. Opdyke, William F. (1990. szeptember 1.). „Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems”. Proceedings of the Symposium on Object Oriented Programming Emphasizing Practical Applications (SOOPPA), ACM. 
  28. Griswold, William G (July 1991), Program Restructuring as an Aid to Software Maintenance, University of Washington, <http://cseweb.ucsd.edu/~wgg/Abstracts/gristhesis.pdf>. Hozzáférés ideje: 2011-12-24
  29. Opdyke, William F (June 1992), Refactoring Object-Oriented Frameworks, University of Illinois at Urbana-Champaign, <https://web.archive.org/web/20191216212919/https://dl.acm.org/citation.cfm?id=169783>. Hozzáférés ideje: 2008-02-12
  30. Brodie, Leo. Thinking Forth, 171–196. o.. ISBN 0-9764587-0-5. Hozzáférés ideje: 2020. május 3.  Archiválva 2005. december 16-i dátummal a Wayback Machine-ben
  31. Weißgerber, Peter (2006). „Identifying Refactorings from Source-Code Changes”. Proceedings of 21st IEEE/ACM International Conference on Automated Software Engineering (ASE 2006), ACM. 
  32. Xuan (2016). „B-Refactoring: Automatic test code refactoring to improve dynamic analysis”. Information and Software Technology 76, 65–80. o. DOI:10.1016/j.infsof.2016.04.016.  
  33. What's new in Xcode 9
  34. Refactoring in Qt Creator

Fordítás[szerkesztés]

Ez a szócikk részben vagy egészben a Code refactoring 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.

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