Kódrefaktorálás
A kódrefaktorálás a meglévő számítógépes forráskód átalakításának folyamata – az elemek, összetevők (faktorok) megváltoztatása – a külső viselkedés módosulása nélkül. A refaktorálás célja a kód nem funkcionális tulajdonságainak (felépítésének, összetételé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 javítja a kód olvashatóságát és csökkenti a bonyolultságát; így könnyebben karbantartható a forráskód, és egyszerűbb, letisztultabb vagy kifejezőbb belső architektúra vagy objektummodell hozható létre a bővíthetőség javítása érdekében.
Refaktorálás közben jellemzően szabványosított kisebb változtatások sorozatát (micro-refactoring) alkalmazzák, amelyek mindegyike (általában) a forráskód apró változtatását jelenti, 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 telepítési környezet automatizált támogatást nyújt ezen kis változtatások mechanikai aspektusainak 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ése által, é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 és/vagy újabb hibákat idézhet elő.
„A kód dizájnjának folyamatos javításával egyre egyszerűbbé és egyszerűbbé tesszük a vele való munkát. Ez éles ellentétben áll azzal, ami általában történik: kevés refaktorálás, és nagy hangsúly az új funkciók gyors implementációján. Ha ráérzel a folyamatos refaktorálás higiénikus szokására, rájössz, hogy sokkal könnyebb lesz bővíteni és karbantartani a kódot.” | |
– Joshua Kerievsky, Refactoring to Patterns[1] |
Motiváció
A refaktorálásra általában akkor kerül sor, ha „gyanús kódot” (code smell) észlelnek.[2] Például egy adott metódus túl hosszú, vagy nagyban hasonlít egy másikra.. Amint felismerték, ezeket a problémákat a forráskód refaktorálásával vagy újraírásával oldják meg, mely ugyanúgy viselkedik, de már nem gyanús.
Egy hosszabb metódusból egy vagy több kisebb szubrutint lehet kiemelni; duplikált rutinok esetén a másolat eltávolítható és helyettesíthető egy megosztott függvénnyel. 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
A refaktorálás előnyeinek két általános kategóriája van.
- Karbantarthatóság. A hibák javítása könnyebb, ha 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 rövid, jól megnevezett, egycélú metódusok sorozatává redukálják. Az is segít, ha egy metódust egy megfelelőbb osztályba helyezünk, vagy eltávolítjuk a félrevezető megjegyzéseket.
- Bővíthetőség. Az alkalmazás funkcióit könnyebb kibővíteni, ha felismerhető tervezési mintákat használ, és bizonyos rugalmasságot biztosít olyan helyeken, ahol korábban nem létezett ilyen.[5]
A teljesítménytervezés (performance engineering) képes megszüntetni a programok hatékonysági hiányosságait, az úgynevezett szoftverfelfúvódást (software bloat), amely a hagyományos szoftverfejlesztési stratégiákból ered (az alkalmazás fejlesztési idejének minimalizálása a futási idő helyett). A teljesítménytervezés a szoftvert a futtatásához szükséges hardverhez is igazíthatja, például a párhuzamos architektúrák kihasználása érdekében.[6]
Kihívások
A refaktoráláshoz ki kell emelni a szoftverrendszer struktúráját, az adatmodelleket és az alkalmazáson belüli függőségeket, hogy tudomást szerezzünk a meglévő szoftverrendszer működéséről.[7] A távozó csapattagok miatt a fejlesztőknek hiányos vagy pontatlan ismereteik vannak a rendszer jelenlegi állapotáról és a tervezési döntésekről. A kódmegújítási tevékenységek további erőfeszítéseket igényelhetnek ezen ismeretek visszanyerése érdekében.[8] A refaktorálási tevékenységek architekturális módosításokat eredményeznek, amelyek rontják a szoftverrendszer szerkezeti felépítését, ez pedig befolyásolja például a karbantarthatóságot és az áttekinthetőséget, amelyek a szoftverrendszerek teljes újrafejlesztéséhez vezethetnek.[9]
A kódrefaktoráló tevékenységeket szoftveres intelligencia biztosíthatja, amely eszközöket és technikákat használ, hogy adatokat szolgáltasson a kód algoritmusairól és szekvenciáiról.[10] 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átumban való megjelenítése kritikus rész a magas szintű megértés kialakulásában, mivel ez alapján tudható meg, hogy mit kell módosítani, és hogyan.[11]
Tesztelés
Az automatikus egységteszteket be kell állítani a refaktorálás előtt, hogy megbizonyosodjanak arról, hogy a rutinok továbbra is a várt eredményeket adják.[12] Az egységtesztelés még nagymértékű refaktorálás esetén is stabilitást eredményezhet, ha a változtatásokat kis lépésekben végzik. Gyakori stratégia a több projektet átfogó refaktorálások esetén hogy az összes projektet egyetlen adattárban (repository) tárolják.[13]
Az egységtesztek végrehajtása során a refaktorálás egy iteratív ciklus formáját ölti, amely során apró kódváltoztatásokat végeznek, teszteléssel megbizonyosodnak róla, hogy ez nem változtatta meg a viselkedést, majd folytatják a változtatásokat. Ha egy teszt bármely pontján kudarcot vall, akkor az utolsó apró változtatást visszavonják és más módon ismétlik meg. Ahhoz, hogy ez az 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 folyamat szerves részeként írják le.
Technikák
Íme néhány példa a mikro-refaktorokra; ezek közül néhány csak bizonyos nyelvekre vagy nyelvtípusokra vonatkozik. Hosszabb lista megtalálható Martin Fowler könyvében és a weboldalon.[14] 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 észszerű 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[15]
- Rendszerfüggési grafikon – a programfüggőségi gráfok közötti eljáráshívások ábrázolása[16]
- Szoftverintelligencia – Segít megérteni az alkalmazáson belüli függőségeket
- További absztrakciót lehetővé tevő technikák
- Adatmező egységbe zárása – rákényszeríti a kódot, hogy a mezőt csak getter és setter metódusokkal lehessen elérni
- Típus általánosítása – általánosabb típusok létrehozása a további kódmegosztás érdekében
- Típusellenőrző kód cserélése állapotra/stratégiára[17]
- Feltételek cserélése polimorfizmusra[18]
- A kód logikusabb részekre bontása
- A kód felbontása újrafelhasználható szemantikai egységekre, amelyek tiszta, jól meghatározott, egyszerűen használható felületeket tartalmaznak
- Egy nagyobb osztály egy részének kiemelése és velük egy új osztály létrehozása
- Egy nagyobb metódus (vagy függvény) egy részének kiemelése és velük egy új metódus létrehozása
- Nevek és helyek javítására
- Metódusok vagy adatmezők áthelyezése egy megfelelőbb osztályba vagy forrásfájlba
- Metódusok vagy adatmezők neveinek megváltoztatása olyanra, amelyek jobban leírják a céljukat
- Pull up – áthelyezés szülőosztályba (objektumorientált programozásban)
- Push down – áthelyezés gyerekosztályba (objektumorientált programozásban)[12]
- Kódduplikáció automatikus felismerése[19]
Hardver-refaktorálás
Míg a refaktorálás kifejezés eredetileg kizárólag a szoftverkód átírá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 hardverleíró nyelveken történő refaktorálására. Mivel a hardvermérnökök 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.
Az analóg hardverleírások (VHDL-AMS-ben) automatikus refaktorálását Zeng és Huss javasolta.[20] 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ézises eszközökkel feldolgozható, az eredeti kód viszont nem. A digitális HDL-ek refaktorálását 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
Bár a refaktorálás informálisan évtizedek óta jelen volt, a szó (refactoring) legelőször 1990 szeptemberében jelent meg William Opdyke és Ralph Johnson cikkében.[23] Megjegyzendő, hogy a factoring és a factoring out kifejezéseket a Forth közösségben már az 1980-as évek eleje óta ilyen értelemben használták. Leo Brodie Thinking Forth (1984) könyvének hatodik fejezetét a témának szentelték.[24]
William Griswold 1991-es Ph.D. disszertációja az egyik első nagyobb tudományos munka a funkcionális és a procedurális programok refaktorálásáról. Opdyke 1992-es disszertációja az objektumorientált programok refaktorálásáról szólt, bár az elmélet és a technika már régóta elérhető volt program transzformációs rendszerekként.[25] Mindezek az irományok áttekintést adnak a refaktorálás általános módszereiről.
Martin Fowler könyve, a Refactoring: Improving the Design of Existing Code referenciamunkának tekinthető.[26]
Automatizált kódrefaktorálás
Számos 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.[27] Alább néhány ilyen szerkesztő vagy úgynevezett refaktoráló böngésző:
- DMS szoftverfejlesztési eszközkészlet (nagyméretű refaktorálást valósít meg C, C ++, C #, COBOL, Java, PHP és más nyelvek számára)
- Eclipse alapú:
- Eclipse (Java, és kisebb mértékben C ++, PHP, Ruby és JavaScript)
- PyDev (Python)
- Photran (Fortran bővítmény az Eclipse IDE-hez)
- Embarcadero Delphi
- IntelliJ alapú:
- AppCode (Objektív-C, C és C ++)
- IntelliJ IDEA (Java)
- PyCharm (Python)
- WebStorm (JavaScript)
- Android Studio (Java)
- JDeveloper (Java)
- NetBeans (Java)
- Smalltalk: A legtöbb dialektus erős refaktoreszközöket tartalmaz. Sokan használják a 90-es évek elején Ralph Johnson által gyártott eredeti refaktorböngészőt.
- Visual Studio alapú:
- Visual Studio (NET és C ++)
- CodeRush (kiegészítő)
- Visual Assist (a Visual Studio kiegészítője a C # és C ++ refaktor támogatásával)
- Wing IDE (Python)
- X kód (C, Objective-C és Swift)[28]
- Qt készítő (C ++, Objective-C és QML esetén)[29]
Jegyzetek
- ↑ Kerievsky, Joshua. Refactoring to Patterns. Addison Wesley (2004)
- ↑ Fowler, Martin. Refactoring. Improving the Design of Existing Code. Addison-Wesley, 63. o. (1999). ISBN 978-0-201-48567-7
- ↑ Suryanarayana, Girish. Refactoring for Software Design Smells. Morgan Kaufmann, 258. o. (2014. november 1.). ISBN 978-0128013977
- ↑ Martin, Robert. Clean Code. Prentice Hall (2009)
- ↑ Haendler (2019. augusztus 18.). „A Framework for the Assessment and Training of Software Refactoring Competences”. Proc. Of 11th International Conference on Knowledge Management and Information Systems (KMIS)..
- ↑ Leiserson et al (2020). „There's plenty of room at the Top: What will drive computer performance after Moore's law?”. Science 368 (6495), eaam9744. o. DOI:10.1126/science.aam9744. PMID 32499413.
- ↑ Nassif, Matthieu (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.
- ↑ van Gurp, Jilles (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.
- ↑ 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.
- ↑ Novais, Renato (2017. augusztus 18.). „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.
- ↑ 1963-, Fowler, Martin. Refactoring : improving the design of existing code. Reading, MA: Addison-Wesley (1999. augusztus 18.). ISBN 978-0201485677. OCLC 41017370
- ↑ a b (these are only about OOP however).Refactoring techniques in Fowler's refactoring Website
- ↑ Java Power Tools (angol nyelven). "O'Reilly Media, Inc.", 301. o. (2008. augusztus 18.). ISBN 9781491954546. Hozzáférés ideje: 2018. július 26.
- ↑ Refactoring techniques in Fowler's refactoring Website
- ↑ 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.
- ↑ 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.
- ↑ Replace type-checking code with State/Strategy
- ↑ Replace conditional with polymorphism
- ↑ Bruntink, Magiel, et al. "An evaluation of clone detection techniques for crosscutting concerns." Software Maintenance, 2004. Proceedings. 20th IEEE International Conference on. IEEE, 2004.
- ↑ Kaiping Zeng, Sorin A. Huss, "Architecture refinements by code refactoring of behavioral VHDL-AMS models". ISCAS 2006
- ↑ 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"
- ↑ M. Keating, P. Bricaud: Reuse Methodology Manual for System-on-a-Chip Designs, Kluwer Academic Publishers, 1999.
- ↑ Opdyke és Johnson (1990. szeptember 1.). „Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems”., ACM.
- ↑ Brodie, Leo. Thinking Forth, 171–196. o.. ISBN 0-9764587-0-5. Hozzáférés ideje: 2020. május 3.
- ↑ 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
- ↑ Fowler, Martin. Refactoring. Improving the Design of Existing Code. Addison-Wesley, 63ff. o. (1999). ISBN 978-0-201-48567-7
- ↑ 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.
- ↑ What's new in Xcode 9
- ↑ Refactoring in Qt Creator
További információk
- Wake, William C.. Refactoring Workbook. Addison-Wesley (2003). ISBN 978-0-321-10929-3
- Mens (2024. augusztus 18.). „A survey of software refactoring”. IEEE Transactions on Software Engineering 30 (2), 126–139. o. DOI:10.1109/tse.2004.1265817. ISSN 0098-5589.
- Feathers, Michael C. Working Effectively with Legacy Code. Prentice Hall (2004). ISBN 978-0-13-117705-5
- Kerievsky, Joshua. Refactoring To Patterns. Addison-Wesley (2004). ISBN 978-0-321-21335-8
- Arsenovski, Danijel. Professional Refactoring in Visual Basic. Wrox (2008). ISBN 978-0-470-17979-6
- Arsenovski, Danijel. Professional Refactoring in C# and ASP.NET. Wrox (2009). ISBN 978-0-470-43452-9
- Ritchie, Peter. Refactoring with Visual Studio 2010. Packt (2010). ISBN 978-1-84968-010-3
- Mi a refaktorálás? (c2.com cikk)
- Martin Fowler honlapja a refaktorról
- Refactoring az Open Directory Project-ben
Fordítá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. 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.