리팩토링
- 정의
> 소프트웨어를 보다 쉽게 이해할수 있고, 적은 비용으로 수정할수 있도록 겉으로 보이는 동작의 변화 없이 내부 구조를 변경하는것
- 퍼포먼스 최적화
> 리팩토링과 반대되는 의미로 사용될수도 있다. 최적화를 위해서 코드의 가독성을 희생해야 할수도 있기 때문에 리엔지니어링?에 가까운거 같다.
언제 리팩토링 할까?
틈틈히!
- 삼진 규칙
> 중복 된 코드가 3번 보일때 리팩토링
- 기능 추가 할때
> 왜냐면 좋은 디자인으로 작성된 코드는 기능을 추가하기 편하다. 하지만 그렇지 않은 상황에서는???
- 버그를 수정할때
- 코드리뷰를 할때
- 프로그램에 대한 작업을 어렵게 하는 이유는 ..
• 읽기 어려운 프로그램은 수정하기 어렵다
• 중복된 로직을 가지고 있는 프로그램 수정하기 어렵다.
• 실행중인 코드를 변경해야 하는 특별한 동작을 요구하는 프로그램은 수정하기 어렵다
• 복잡한 조건문이 포함된 프로그램은 수정하기 어렵다
관리자를 설득 하는 비법
역시 글은 어그로가 최고임
관리자가 기술적인 지식이 있다면 리팩토링한다고 솔직히 이야기하자.
관리자가 품질에 더 관심있다면 역시나 솔직히 이야기하자
위 두가지 상황이 아니면 말하지 말자
보통 대부분 관리자들은 스케쥴을 중요시한다. 대부분은 품질보다 스케쥴을 더 선택한다.
스케쥴에 맞추고 시간남으면 하거나 혹은 다음번에 진행하자고 할것이다.
소프트웨어 개발자는 전문가다. 효과적인 소프트웨어를 가능한 빨리 만들어내는 것이다.
- 퍼포먼스
- 시스템이 어떻게 돌아가는지 알고 있더라도 추측만하지 말고 실제로 퍼포먼스 측정을 해보라
- 프로그램이 잘 분해 되어 있으면 세세한 부분 좀더 세밀한 분석이 가능하다.
- 모든 코드를 최적화 하면 90%는 낭비다. 대부분 코드의 작은 부분에서 발생하고 해당 부분을 수정하면 된다.
위와 같은 사유로 리팩토링은 퍼포먼스 향상에 도움을 준다.
