코드 리팩터링

Code refactoring

컴퓨터 프로그래밍소프트웨어 설계에서 코드 리팩터링은 외부 동작을 변경하지 않고 기존 컴퓨터 코드를 재구성하는 프로세스입니다.리팩터링은 소프트웨어(비기능 속성)의 설계, 구조 및/또는 구현을 개선하면서 기능을 유지하는 것을 목적으로 합니다.리팩터링의 잠재적인 이점으로는 코드 가독성 향상과 복잡성 감소가 있습니다.이러한 이점은 소스 코드의 유지보수성을 향상시키고 보다 단순하고 깔끔하며 표현력이 뛰어난 내부 아키텍처 또는 객체 모델을 생성하여 확장성을 향상시킬 수 있습니다.리팩터링의 또 다른 잠재적인 목표는 성능 향상입니다.소프트웨어 엔지니어는 보다 고속으로 실행하거나 메모리를 적게 사용하는 프로그램을 작성해야 하는 지속적인 과제에 직면해 있습니다.

일반적으로 리팩터링은 일련의 표준화된 기본 마이크로 리팩터링을 적용하는데, 각각은 소프트웨어의 동작을 보존하거나 최소한 기능 요건에 대한 적합성을 수정하지 않는 컴퓨터 프로그램의 소스 코드의 미세한 변경이다.많은 개발 환경은 이러한 기본적인 리팩터링의 기계적 측면을 수행하기 위한 자동 지원을 제공합니다.코드 리팩터링이 잘 되면 소프트웨어 개발자는 기본 논리를 단순화하고 불필요한 복잡성을 배제함으로써 시스템 내의 숨겨진 오류 또는 휴면 버그 또는 취약성을 발견하고 수정하는 데 도움이 될 수 있습니다.잘못하면 외부 기능을 변경하지 않는 요건을 충족하지 못해 새로운 버그가 발생할 수 있습니다.

코드 디자인을 지속적으로 개선하여 작업하기 쉽고 쉽게 만듭니다.리팩터링이 거의 없고 새로운 기능을 쉽게 추가하는 데 많은 주의를 기울이는 등 일반적인 현상과는 확연히 대조적입니다.리팩터링을 계속하는 위생 습관을 들이면 코드를 연장하고 유지하기 쉬워집니다.

--

동기

리팩터링은 보통 코드 [2]냄새를 감지함으로써 동기를 부여합니다.예를 들어, 수중에 있는 방법이 매우 길거나 가까운 다른 방법의 거의 중복일 수 있습니다.인식되면 소스 코드를 리팩터링하거나 이전과 동일하게 동작하지만 더 이상 "냄새"가 나지 않는 새로운 형태로 변환하여 이러한 문제를 해결할 수 있습니다.

긴 루틴의 경우 하나 이상의 작은 서브루틴을 추출할 수 있으며, 중복 루틴의 경우 중복을 제거하고 하나의 공유 함수로 대체할 수 있습니다.리팩터링을 수행하지 않으면 기술적 부채가 누적될 수 있습니다. 반면 리팩터링은 기술적 [3]부채를 상환하는 주요 수단 중 하나입니다.

혜택들

리팩터링 활동에는 두 가지 일반적인 유익성 범주가 있습니다.

  1. 유지 보수성소스코드가 읽기 쉽고 작성자의 의도를 [4]파악하기 쉽기 때문에 버그 수정이 용이합니다.이는 대규모 모노리식 루틴을 개별적으로 간결하고 이름이 잘 지정된 단일 목적 메서드 세트로 줄임으로써 달성할 수 있습니다.이는 메서드를 보다 적절한 클래스로 이동하거나 잘못된 주석을 제거함으로써 달성할 수 있습니다.
  2. 확장성인식 가능한 설계 패턴을 사용하면 애플리케이션의 기능을 확장하는 것이 쉬워지고, 이전에는 없었던 유연성을 [1]얻을 수 있습니다.

퍼포먼스 엔지니어링은, 애플리케이션의 실행에 걸리는 시간이 아닌 개발 시간을 최소한으로 억제하는 것을 목표로 하는 종래의 소프트웨어 개발 전략으로부터 발생하는, 소프트웨어의 번짐이라고 불리는 프로그램의 비효율성을 해소할 수 있습니다.퍼포먼스 엔지니어링에서는 예를 들어 병렬 프로세서나 벡터 [5]유닛을 활용하기 위해 소프트웨어를 실행하는 하드웨어맞출 수도 있습니다.

과제들

리팩터링에서는 기존 소프트웨어 [6]시스템에 대한 지식을 얻기 위해 소프트웨어 시스템 구조, 데이터 모델 및 애플리케이션 내 의존 관계를 추출해야 합니다.팀의 이직은 시스템의 현재 상태 및 퇴사하는 개발자가 내린 설계 결정에 대한 지식이 없거나 부정확함을 의미합니다.코드 리팩터링 작업을 더 진행하려면 [7]이 지식을 다시 얻기 위해 추가적인 노력이 필요할 수 있습니다.리팩터링 액티비티는 소프트웨어 시스템의 구조 아키텍처를 악화시키는 아키텍처 변경을 일으킵니다.이러한 열화는 유지관리성 및 포괄성 등의 건축 특성에 영향을 미쳐 소프트웨어 시스템의 완전한 재개발로 이어질 수 있습니다.[8]

코드 리팩터링 활동은 알고리즘 및 코드 [9]실행 시퀀스에 대한 데이터를 제공하는 도구 및 기술을 사용할 때 소프트웨어 인텔리전스로 보호됩니다.소프트웨어 시스템 구조, 데이터 모델 및 컴포넌트 내 의존성의 내부 상태에 대해 이해하기 쉬운 형식을 제공하는 것은 수정해야 할 항목과 [10]방법에 대한 높은 수준의 이해를 형성하기 위한 중요한 요소입니다.

테스트

리팩터링 전에 자동 장치 테스트를 설정하여 루틴이 [11]예상대로 작동하는지 확인해야 합니다.유닛 테스트에서는 단일 원자 커밋으로 실행할 경우 대형 리팩터에도 안정성을 가져올 수 있습니다.여러 프로젝트에 걸쳐 안전 및 원자 리팩터를 허용하는 일반적인 전략은 모든 프로젝트를 단일 저장소(모노레포)[12]에 저장하는 것입니다.

유닛 테스트를 실시하면 리팩터링은 소규모 프로그램 변환, 정확성 확인 테스트, 또 다른 소규모 변환의 반복 사이클이 됩니다.어느 시점에서든 테스트가 실패하면 마지막 작은 변경은 실행 취소되고 다른 방법으로 반복됩니다.많은 작은 단계를 거치면서 프로그램은 원래 있던 위치에서 원하는 위치로 이동합니다.이 반복적인 프로세스가 실용화되기 위해서는 테스트가 매우 빠르게 실행되어야 합니다.그렇지 않으면 프로그래머는 대부분의 시간을 테스트가 끝나기를 기다리는 데 소비해야 합니다.극단적인 프로그래밍기타 민첩한 소프트웨어 개발지지하는 사람들은 이 활동을 소프트웨어 개발 주기의 필수적인 부분으로 설명합니다.

기술

다음은 마이크로 리팩터링의 몇 가지 예입니다.이들 중 일부는 특정 언어 또는 언어 유형에만 적용될 수 있습니다.더 긴 목록은 마틴 파울러의 리팩터링[2][page needed] 책과 웹사이트에서 찾을 수 있다.[13]많은 개발 환경에서 이러한 마이크로 리팩터링을 자동으로 지원합니다.예를 들어, 프로그래머는 변수의 이름을 누른 다음 컨텍스트 메뉴에서 "필드 캡슐화" 리팩터링을 선택할 수 있습니다.그런 다음 IDE는 일반적으로 합리적인 기본값과 코드 변경 미리 보기를 사용하여 추가 세부 정보를 요구합니다.프로그래머의 확인을 거쳐 코드 전체에 걸쳐 필요한 변경을 수행합니다.

  • 보다 많은 이해를 가능하게 하는 기술
    • 프로그램 종속성 그래프 - 데이터 및 제어 종속성의 명시적 표현
    • System Dependence Graph - PDG 간의 프로시저 호출 표현
    • 소프트웨어 인텔리전스 - 초기 상태를 리버스 엔지니어링하여 기존 애플리케이션 내 의존관계를 파악합니다.
  • 보다 추상화를 가능하게 하는 기술
    • 필드 캡슐화– getter 및 setter 메서드를 사용하여 필드에 액세스하도록 코드를 강제합니다.
    • 타입의 일반화– 보다 일반적인 타입을 생성하여 더 많은 코드 공유를 가능하게 합니다.
    • 유형 검사 코드를 상태/전략으로[16] 대체합니다.
    • 조건부로 다형성[17] 대체
  • 코드를 보다 논리적인 조각으로 분할하는 기술
    • 컴포넌트화는 코드를 재사용 가능한 시맨틱 단위로 분해하여 명확하고 알기 쉬운 인터페이스를 제공합니다.
    • 추출 클래스는 코드의 일부를 기존 클래스에서 새 클래스로 이동합니다.
    • 추출 방법: 큰 메서드의 일부를 새로운 메서드로 변환합니다.코드를 작은 조각으로 나누면 더 쉽게 이해할 수 있습니다.이는 기능에도 적용됩니다.
  • 코드 이름 및 위치 개선 기술
    • 메서드 또는 필드 이동– 보다 적절한 클래스 또는 소스 파일로 이동
    • 메서드 이름 변경 또는 필드 이름 변경 – 용도를 더 잘 알 수 있는 새 이름으로 이름을 변경합니다.
    • 풀업 – 객체 지향 프로그래밍(OOP)에서 슈퍼클래스로 이동
    • 푸시 다운 – OOP에서 하위[13] 클래스로 이동합니다.
  • 자동 클론[18] 검출

하드웨어 리팩터링

원래 리팩터링이라는 용어는 소프트웨어 코드의 리팩터링만을 의미하지만 최근에는 하드웨어 기술 언어로 작성된 코드도 리팩터링되고 있습니다.하드웨어 리팩터링이라는 용어는 하드웨어 기술 언어로 코드를 리팩터링하기 위한 약어로 사용됩니다.하드웨어 기술 언어는 대부분의 하드웨어 [19]엔지니어에게 프로그래밍 언어로 간주되지 않기 때문에 하드웨어 리팩터링은 기존 코드 리팩터링과는 다른 분야로 간주됩니다.

아날로그 하드웨어 기술 자동 리팩터링(VHDL-AMS)은 Zeng과 [20]Huss에 의해 제안되었습니다.이러한 접근 방식에서 리팩터링은 하드웨어 설계의 시뮬레이션된 동작을 유지합니다.개선되는 비기능적 측정은 리팩터링된 코드를 표준 합성 도구로 처리할 수 있지만 원래 코드는 처리할 수 없다는 것입니다.디지털 하드웨어 기술 언어의 리팩터링(수동 리팩터링)도 Synopsys의 동료인 Mike [21][22]Keating에 의해 조사되었습니다.그의 목표는 복잡한 시스템을 이해하기 쉽게 만들어 설계자의 생산성을 높이는 것입니다.

역사

출판된 문헌에서 "리팩터링"이라는 용어를 처음 사용한 것은 1990년 9월 윌리엄 옵다이크와 랄프 [23]존슨의 기사에서였다.1992년에 발표된 그리스월드의 박사 논문 [24]옵다이크의 박사 논문도 [25][26]용어를 사용했다.비록refactoring 코드 비공식적으로 수십년 동안 행해졌다, 윌리엄 Griswold의 1991년 박사 학위 dissertation[24]1과 절차적 기능 프로그램 refactoring에 대한 첫번째 주요 학술의 작품, 비록 모든 과정은 이론과 기계 l.다 윌리엄 옵다이크. 미국의 1992년 dissertation[25]에 의해 객체 지향 programs,[26]의 refactoring되었다ong av프로그램 변환 시스템으로 사용할 수 있습니다.이러한 리소스는 모두 일반적인 리팩터링 방법 카탈로그를 제공합니다.리팩터링 방법에는 메서드를 적용해야 하는 경우와 적용해서는 안 되는 경우에 대한 방법 및 인디케이터가 설명되어 있습니다.

마틴 파울러의 책 리팩터링: 기존 코드 설계의 개선은 표준 참고 [according to whom?]자료입니다.

Factoring과 Factoring out이라는 용어는 적어도 1980년대 초부터 Forth 커뮤니티에서 이러한 방식으로 사용되어 왔습니다.레오 브로디의 책 '생각하기'[27]6장은 이 주제에 전념하고 있다.

익스트림 프로그래밍에서 추출 방법 리팩터링 기법은 기본적으로 Fourth의 인수분해와 같은 의미를 가집니다. 즉, 단어(또는 함수)를 보다 작고 유지보수가 용이한 함수로 분해하는 것입니다.

리팩터링은 CVS나 SVN과 같은 소프트웨어 저장소에 기록된 복잡한 소프트웨어 변경에 대한 간결한 설명을 생성하기 위해 사후 재구성할[28] 수도 있습니다.

자동 코드 리팩터링

많은 소프트웨어 에디터 및 IDE는 자동 리팩터링을 지원합니다.테스트 [29]코드뿐만 아니라 애플리케이션 코드도 리팩터가 가능합니다.다음은 이러한 에디터, 이른바 리팩터링 브라우저 목록입니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b Kerievsky, Joshua (2004). Refactoring to Patterns. Addison Wesley.
  2. ^ a b Fowler, Martin (1999). Refactoring. Improving the Design of Existing Code. Addison-Wesley. pp. 63ff. ISBN 978-0-201-48567-7.
  3. ^ Suryanarayana, Girish (November 2014). Refactoring for Software Design Smells. Morgan Kaufmann. p. 258. ISBN 978-0128013977.
  4. ^ Martin, Robert (2009). Clean Code. Prentice Hall.
  5. ^ Leiserson, Charles E.; Thompson, Neil C.; Emer, Joel S.; Kuszmaul, Bradley C.; Lampson, Butler W.; Sanchez, Daniel; Schardl, Tao B. (2020). "There's plenty of room at the Top: What will drive computer performance after Moore's law?". Science. 368 (6495): eaam9744. doi:10.1126/science.aam9744. PMID 32499413.
  6. ^ Haendler, Thorsten; Neumann, Gustaf (2019). "A Framework for the Assessment and Training of Software Refactoring Competences". Proc. Of 11th International Conference on Knowledge Management and Information Systems (KMIS).: 307–316. doi:10.5220/0008350803070316. ISBN 978-989-758-382-7. S2CID 204754665.
  7. ^ Nassif, Matthieu; Robillard, Martin P. (November 2017). "Revisiting turnover-induced knowledge loss in software projects". 2017 IEEE International Conference on Software Maintenance and Evolution (ICSME): 261–272. doi:10.1109/ICSME.2017.64. ISBN 978-1-5386-0992-7. S2CID 13147063.
  8. ^ van Gurp, Jilles; Bosch, Jan (March 2002). "Design erosion: problems and causes". Journal of Systems and Software. 61 (2): 105–119. doi:10.1016/S0164-1212(01)00152-2.
  9. ^ Hassan, Ahmed E.; Xie, Tao (November 2010). "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. doi:10.1145/1882362.1882397. S2CID 3485526.
  10. ^ Novais, Renato; Santos, José Amancio; Mendonça, Manoel (2017). "Experimentally assessing the combination of multiple visualization strategies for software evolution analysis". Journal of Systems and Software. 128: 56–71. doi:10.1016/j.jss.2017.03.006.
  11. ^ Fowler, Martin (1999). Refactoring : improving the design of existing code. Reading, MA: Addison-Wesley. ISBN 978-0201485677. OCLC 41017370.
  12. ^ Smart, John Ferguson (2008). Java Power Tools. "O'Reilly Media, Inc.". p. 301. ISBN 9781491954546. Retrieved 26 July 2018.
  13. ^ a b (단, 이것은 OOP에 관한 것입니다).Fowler 리팩터링 웹사이트 리팩터링 기술
  14. ^ Ferrante, Jeanne; Ottenstein, Karl J.; Warren, Joe D. (July 1987). "The program dependence graph and its use in optimization". ACM Transactions on Programming Languages and Systems. ACM. 9 (3): 319–349. doi:10.1145/24039.24041. S2CID 505075.
  15. ^ Donglin, Linag; Harrold, M. J. (November 2008). "Slicing objects using system dependence graphs". Proceedings. International Conference on Software Maintenance. IEEE: 319–349. doi:10.1109/ICSM.1998.738527. ISBN 978-0-8186-8779-2. S2CID 18160599.
  16. ^ "Replace type-checking code with State/Strategy".
  17. ^ "Replace conditional with polymorphism".
  18. ^ 브런팅크, 마지엘 등"클론 검출 기술에 대한 교차 우려 평가"Software Maintenance, 2004.의사진행동.제20회 IEEE 국제회의 온.IEEE, 2004.
  19. ^ 하드웨어 설명 언어 #HDL 및 프로그래밍 언어
  20. ^ 카이핑쩡, 소린AHuss, "동작 VHDL-AMS 모델의 코드 리팩토링을 통한 아키텍처 개선"ISCAS 2006
  21. ^ M. Keating : "복잡성, 추상화 및 복잡한 시스템 설계의 과제"의 DAC '08 튜토리얼 [1] Wayback Machine에 보관된 2016-03-28 "실용 설계를 위한 검증 격차 해소: C++ to RTL"
  22. ^ M. 키팅, P. Bricaud:시스템 온 칩 설계의 재사용 방법 매뉴얼, Kluwer Academic Publishers, 1999.
  23. ^ Opdyke, William F.; Johnson, Ralph E. (September 1990). "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.
  24. ^ a b Griswold, William G (July 1991). Program Restructuring as an Aid to Software Maintenance (PDF) (Ph.D. thesis). University of Washington. Retrieved 2011-12-24.
  25. ^ a b Opdyke, William F (June 1992). Refactoring Object-Oriented Frameworks (Ph.D. thesis). University of Illinois at Urbana-Champaign. Archived from the original (compressed Postscript) on 2019-12-16. Retrieved 2008-02-12.
  26. ^ a b "Martin Fowler, "MF Bliki: EtymologyOfRefactoring"".
  27. ^ Brodie, Leo (2004). Thinking Forth. pp. 171–196. ISBN 0-9764587-0-5. Archived from the original on 16 December 2005. Retrieved 3 May 2020.
  28. ^ Sokolov, Andriy. "What is code refactoring?".
  29. ^ Xuan, Jifeng; Cornu, Benoit; Martinez, Matias; Baudry, Benoit; Seinturier, Lionel; Monperrus, Martin (2016). "B-Refactoring: Automatic test code refactoring to improve dynamic analysis". Information and Software Technology. 76: 65–80. doi:10.1016/j.infsof.2016.04.016.
  30. ^ "What's new in Xcode 9".
  31. ^ "Refactoring in Qt Creator".

추가 정보

외부 링크