가독성과 유지보수성을 위해
- 성능을 최적화하는 것은 별도의 문제
읽기쉽고 이해하기 쉬운코드를 작성하여 협업을 용이하게 하기위해
버그를 찾는데 도움이 되기도 한다
그로인해 프로그램의 개발속도 향상에도 이어진다
리펙토링을 할때
- The Rule of Three : 유사한 내용이 세번 이상 반복할 때,리펙토링 고려
- 무조건은 아니고 상황에 고려하여 결정
- 새로운 기능을 추가할때
- 지금 상황에서 새로운 기능을 추가하기 어려울때 리펙토링을 진행해야하는데, 이럴 경우 유지보수성이 떨어지며, 가독성도 좋지않다
- 코드 리뷰
리팩토링을 통한 프로그래밍 개발
1. Two Hats
- 리팩토링과 기능을 추가하는 것. 어떤 방식,순서로 하는지도 중요하다
- 기능을 추가할 때는 기존코드를 수정하지 말고,기능과 테스트만 추가
- 리팩토링을 할 때는 기능을 추가하지 말자
- 리팩토링을 하면서 기능을 추가하는 것이 아닌 기능단위로 추가,테스트 후 리펙토링을 해야한다
- 요구사항이 잦은 변경에 따른 프로토타입을 지속적으로 주기 위한것이 아니다
- 어느정도 설계기반으로 변경
1. 테스트 프로그램 세팅
- 리팩토링은 기능을 유지하면서 코드를 개선하는 것이 목적이다
- 리팩토링 후, 기능을 동일하게 작동하는지 확인하는것은 당연한것이다
- TDD 테스트 주도 개발과 함께 진행하면 좋음
- Unit Test에서 자주 진행,Integration Test에서도 좋음
2. 확장 구조 만들기
- 새 기능을 추가하기전에 기능을 추가하기 용이하게 개선 후, 추가하는 것이 효과적이다
- 기능을 추가하면서 동시에 리팩토링을 하는것은 코드의 일관성,컨벤션 룰에 방해되는 요소
- 리팩토링 후 새기능을 추가 할때 직전의 리팩토링 결과물을 고려하고, 적용한 방법들을 바로 적용 가능하므로 효율적
- 테스트와 검증은 매우 중요
1. Extract Method
- 긴 메소드의 일부 코드를 새 메서드로 만드는 것을 의미한다
- 이해를 위해,주석을 이용해서 필요한 부분을 보통 분리한다
- 메소드명은 짧고, 이 기능을 잘 설명할 수 있어야한다(가독성과 재사용성 향상)
- 한번만 사용할 기능이나 다수로직의 파편화가 오히려 디버깅에 힘들다고하는데 이부분은 Block(주석이 항상 있어야한다)으로 관리
2. Move Method
- 한 메소드가 정의된 클래스의 위치가 적절한가
- 객체의 상태를 전혀 사용하지 않음(정적 메소드를 고려)
- 다른 클래스에서 더 많이 사용할 경우(책임 재분배,SRP)
- 정의 위치(클래스)를 변경하는 리팩토링
- 기존 클래스에서는 위임호출로 유지하거나,완전히 제거를 고려한다
- 불필요한 책임에 대한 재분배가 필요
3. 불필요한 임시변수 제거
- 임시 변수는 대부분 메소드로 대체 가능
- 임시변수의 사용은 코드의 길이를 증가시킬수도 있다
- 임시변수 메소드화는 코드길이 축소및 재활용성에 좋다
- 임시 변수제거는 Extract Method 리팩토링을 수월하게 한다
4. 분기 제거 Remove Control Flag
- 일종 분기처리들은 조건의 추가및 삭제에 유연하지 못한다
- 객체지향에서는 이 분기들을 다형성으로 리팩토링할 수 있다
ex) 전략패턴으로 Code속성에 따라 적절한 행위 수행이 가능
- 객체지향에서 if 없이 코딩은 가능하지만,적당한 선을 찾는것이 중요
- 무분별한 Control Flag는 소스코드에서 다중으로 중첩이 될 가능성이 높아 Performance에서 직간접적으로 영향을 줄 수 있으며, 가독성과 변경용이성을 보장할 수 없다
- Control Flag를 사용을 금하는 것이 아닌 지양하여 최적의 선을 찾아 사용
- 디자인 패턴 중 Strategy패턴을 적용하여 행위를 클래스로 캡슐화해 동적으로 행위를 자유롭게 바꿔줄 수 있다
리팩토링의 문제
- DB의 변경
- 많은 비지니스 로직들이 DB스키마와 매우 의존적
- 해결을 위해 호환객체(Adapter)를 이용하는 것을 고려
- 호환 객체의 호환부분만 수정하면,DB에 덜 의존적일 수 있다
- 호환객체는 DB의 의존을 최소화
- 메소드 서명의 변경(디스크립터 변경)
- 오버로드를 이용하는 방식
1. 기존 이름을 남기고, 새이름을 가진 메소드 제작
2. 기존 이름을 새이름을 가진 메소드를 호출하도록 변경
- 경우에 따라서는 기존 이름을 사장(Deprecated)시켜놓는 방법도 있다
- 사장이유 미 해결에 대한 Document를 남긴다
리팩토링을 하지 말아야 할 때
- 리팩토링 대신에 다시 작성하는것이 좋은 경우
- 설계가 크게 변경된다면,재작성이 더 좋은 경우도 있다
- 대신 대부분의 기능이 정상적으로 작동을 해야한다
- 현재로직을 세부 컴포넌트로 분리하고,리팩토링할 것을 고려
- 마감시간이 다 되었을 때
- 설계도 중요하지만 기간도 중요하기 때문에
