리팩터링 2/3/4장.

2장. 리팩터링 원칙

• 리팩터링이란 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 방법.
• '리팩터링'을 하느냐, '기능추가'를 하느냐를 명확히 구분해서 작업하자.
• 3의 법칙 (1)일단 그냥해 (2)중복? 일단 그냥해 (3)중복 또? 그러면 리팩토링하자.
• 내부동작을 이해해야 할 시점에 리팩터링해야 효과를 제대로 볼 수 있다.
• 코드리뷰시 다른사람의 코드를 이해하는데 도움을 줄 수 있다.
• 궁극적인 목표는 개발속도를 높여서 더 적은 노력으로 더 많은 가치를 창출하는 것이다.
• 브랜치따서 개인이 개발 오래하면 나중에 통합할 때 다른 사람이 브랜치 업데이트할 때 힘드니 지속적 통합(CI)을 하자.
• **리팩토링 계획이 있을시 먼저 팀원에게 해당 계획을 공유하자.**
• 자가 테스트 코드와 리팩터링을 묶어서 TDD(Test Driven Development)라 한다.
• 리팩터링을 통해 기능 추가같은 작업이 빨리 끝나므로 프로그램의 프로세스 성능에 더 집중할 수 있다.
• **예측해서 짜두는 코드와 같은 오버코딩을 줄이자.**

3장. 코드에서 나는 악취

• 이름만 보고도 각각이 무슨 일을 하고 어떻게 사용해야 하는지 알 수 있도록 이름을 지어보자. **함수이름이 좀 길어지더라도 이해하기 쉽게 지어주자.**
• 중복코드를 피하기 위해 '함수 추출하기', '문장 슬라이드하기', '메서드 올리기'를 활용하자.
• 하나의 메서드는 하나의 기능만을 가지도록 하자.
• 전역 데이터를 주의하자. 전역데이터가 적어도 캡슐화하자.
• 비슷한 데이터를 다루는 함수가 많다면 '여러 함수를 클래스로 묶기'를 적용하자.
• 데이터 구조를 변환하거나 보강하는 함수들에는 '여러 함수를 변환 함수로 묶기'를 적용하자.
• 묶은 함수들의 출력 결과를 묶어 다음 로직으로 전달할 수 있으면 '단계 쪼개기'를 적용하자.
• 주석을 남겨야겠다는 생각이 들면 주석이 필요없는 코드로 리팩터링을 해본다. **주석은 남기지 않는게 좋다. 코드로 설명하자.**
• 반복문의 경우 필터나 맵을 활용해서 처리 과정을 밝혀주자.
• 당장 눈앞에 걸리적거리는 코드는 치워버리자.
• 모듈사이의 데이터 거래가 있다면 그 양을 최소로 줄이고 모두 투명하게 처리하자.

4장. 테스트 구축하기

• 모든 테스트를 완전히 자동화하고 그 결과까지 스스로 검사하게 만들자.
• 실패해야할 상황에선 반드시 실패하게 만들자.
• 문제가 생길 가능성이 있는 경계 조건을 생각해보고 그 부분을 집중적으로 테스트하자.
• 어차피 모든 버그를 잡을 수 없다고 테스트 코드를 작성안하면 대부분의 버그를 잡을 기회를 놓치는 것이다.
• **위험한 코드, 중요한 코드에만 테스트 코드를 작성하는 것도 고려하자. 커버리지에만 너무 집중하면 효율이 떨어질 수 있다.**

 

 

책) 리팩터링 2탄