Refactoring

아래 내용은 Clean code내용을 주로 기반으로 하였다. 이 책의 저자도 본인이 무조건 옳다고 주장하는 것은 아니므로, 단순히 의견으로만 받아들이고, 고민할 수 있는 내용이 되었으면 한다.

Refactoring

1. Reafctoring Introduction

• What is Refactouring?
  • 외부 동작(소프트웨어의 관찰되는 동작)은 유지한 채, 내부 구조를 변경하는 것이다. 즉, 리팩토링은 사용자들이 몰라도 상관 없다.
    개발자가 리팩토링을 하는 목적은 소프트웨어를 이해하기 쉽고, 수정용이하도록 변경하는 것이다. 우선, 무엇인지 알아본 후에 왜 해야하는지 다시 초첨을 맞춰보자.

 

• Two Hats - Kent back
  • 이 이론은 하나에만 집중하라는 데, 중점을 두라는 뜻이다. 리팩토링이라는 모자와 기능구현이라는 두 개의 모자가 있다고 가정할 때, 기능구현이라는 모자를 쓰고 있다면, 그것에만 집중해라. 내가 무엇을 하는지 정확하게 알고 진행할 것.
    • 기능 구현 adding functions
    • 리팩토링 refactoring

 

red-green-refactor

• Red-green-refactor
  • Robert C Martin의 Clean code에서 나오는 TDD에 관한 내용이다.
  • 리팩토링을 위해서는 사전적으로 존재해야하는 것이 충분히 Unit Test가 작성되어 있는지가 중요하다.
  • Unit Test가 충분하지 않다면, 내가 수정을 하더라도 안정적으로 수정이 되었는지 확인하기가 까다롭다.
    그게 아니더라도 수정한 나부터 이게 맞는지 불안해진다.
  • Red green refactor의 3단계 
    • Red: 에러나는 Unit Test 를 작성
    • Green: 테스트케이스들을 통과하도록 코드 작성
    • Refactor: 가독성과 유지보수성이 좋게 하자.
• Why Should We Refactor?
  • 유지보수성을 높이기 위해
  • 코드 이해하기 쉽게
  • 버그 발견을 돕기 위해
  • 프로그래밍을 빨리하기 위해
    즉, 리팩토링이 더 큰 비용이 발생하면, 하지않는게 맞다.
• When to refactor?
  • 요구사항은 항상 변한다.
  • The Rule of Three (3 strikes!)
    1. 요구사항에 맞게 그냥 구현한다.
    2. 유사한 요구사항이 또 들어온다.
    3. 또 유사한 요구사항이 들어온다면, 리팩토링 하자.
• Promblems with refactor
  • 리팩토링은 전적으로 개발자의 몫이다.
  • 리팩토링은 효율성을 위한 것이다. 즉, 개발자의 편의를 위한 것이므로, 요구사항을 해결하는데 걸리는 시간이 지저분한 코드 때문에 걸리는 시간이 더 많이 소모 되어야 리팩토링이 의미가 있는 것이다.
  • 테스트를 통해, 리팩토링 후 동작에 이상이 없는지 확인해야 한다. (마이클 패더스. 레거시 활용 전략)
  • Code ownership, 유관부서에서도 코드 수정이 가능하게 하고, 코드리뷰를 통해서 반영할 수 있도록 허용한다.
• How to refactor
  • 리팩토링은 작은 변화의 연속으로, 각각의 변경은 기존코드를 점차 개선하고, 프로그램은 정상동작을 유지하여야 한다.
  • 테스트코드가 없는 것은 공사장에서 안전장비 없이 하는 것과 같다.
• Steps to refactoring
  • 리팩토링을 위해서는 견고한 test set 을 가져야한다.
  • 코드의 문제점을 찾는다.
  • 기존 동작이 문제없는지 확인한다.
• 코드 리팩토링은 trade-off 관계다.
  • add parameter <-> remove parameter
  • hide delegate <-> remove middle man
  • 상황에 따라 다르고, 팀에 따라 다르다.(퍼포먼스 중시이냐, 가독성 중시이냐)
  • 다양한 리팩토링 방법 중 적합한 방법으로 하자.
  • https://github.sec.samsung.net/yj51-yang/Refactoring_technique

 

Code Smell

• 개발을 느리게 만드는 구조상 약점, 버그나 실패를 야기할 수있는 부분, 오동작과는 무방하다.
• Mysterious Name
  • 좋은 이름을 사용하면, 주석을 줄이고, 코드이해를 도움줄 수 있다.
    • Rename Variable, Field
• Duplicate Code
  • 반복되는 함수 뿐아니라, 반복되는 코드도 줄일 것
    • Extract Function, Slide Statement 코드 재정렬.
• Long Function
  • 함수의 코드 라인이 긴 경우
    • 일반적으로 10라인이 넘어가면 의문을 가져보아야 한다. 20줄도 길다. - R. C Martin
• Long Parameter List
  • 3~4개 이상의 Parameter가 전달되는 경우
• Global data
  • 코드 전역에서 수정가능한 data는 최소화 하자. (Global variable, claass field, singleton)
    • encapsulate Variable. 사용할 때, getter and setter를 이용한다.
• Mutable data
  • 의도치 않은 data 변경을 야기할 수 있는 경우
    • encapsulate Variable.
    • split Variable. 하나의 목적으로만 사용하도록 선언
    • 계산되는 시점과 사용 시점이 다르다면, Replace derived Variable with query
    • 범위를 통제, Combine Funtions into class transform. 유사한 함수들을 하나로 묶는다.
    • Change Reference to Value.
• Divergent Change
  • 하나의 모듈이 다양한 원인 때문에 다양한 방식으로 수정되는 경우
    • Function이 하나의 responsibility
• Shotgun Surgery
  • 하나의 수정 사항 발생 시, 여러 클래스에서 자잘하게 고쳐야하는 경우
    • Move Function, Field
    • Combine
• Feature Envy
  • 메서드가 다른 클래스에 더 많이 접근하는 경우
    • Move, Extract Function
• Repeated Switches
  • Replaace Type code with subclass
    • typecode 따라 분기가 달라지는 경우 서브클래스, Type class 생성
  • Replace Conditional with Polymorphism
    • 하위클래스에서 오버라이딩하도록 구성(abstract)
• Replace Loop with pipeline
  • Use Loop. List names = people.steam().filter(...).map(...).collect(Collectors.toList())
• Lazy Elements
  • 리팩토링 후 남은 요소들 삭제
• Temprorary Field
  • 특정 상황에서만 값이 할당 되는 경우

 

 

ref)

https://marsner.com/blog/why-test-driven-development-tdd/