리팩토링을 해야 될 때
-
모든 이름은 무슨 일을 하는지, 어떻게 사용해야 하는지 명확히 알 수 있어야 한다. 이름만 잘 지어도 문맥을 파악하기 쉬워진다.
만약 마땅한 이름이 떠오르지 않는다면 설계 자체에 문제가 있을 수 있다.
-
중복 코드가 보일 경우, 비슷한 부분을 모으고 함수로 추출해본다.
-
함수가 길수록 이해하기 어려워진다. 함수를 이해하기 위해 코드를 왔다갔다 읽어야 하지만 짧은 함수로 쪼개서 구성하면서 얻는 잇점이 훨씬 크다.
주석을 설명할 수 있으면 함수로 만든다. 함수의 이름은 '의도'가 드러나게 짓는다.
함수의 매개변수와 임시 변수를 줄여야 한다.
조건문, 반복문 등이 보이면 함수로 따로 추출할 수 있는지 고려한다. -
긴 매개 변수 목록을 줄인다.
-
전역적인 자료를 줄이고 변수를 캡슐화 하여 정해놓은 함수만 사용해서 값을 수정하게 해야 한다.
-
가변(mutable) 데이터를 다룰 때 원본 데이터를 변조하지 않게 해야 하고 유효범위를 줄여야 한다.
-
코드를 수정할 때 로직들이 뒤엉켜 있어서 여러 부분을 수정해야 하는 코드는 안좋다. 필요한 부분만 최소한으로 수정할 수 있는 코드일수록 이상적이다. 맥락별로 분리해야 한다.
-
코드를 변경할때마다 자잘하게 수정할 부분이 많은 것도 안좋다. 이 경우는 맥락별로 코드를 모아서 맥락을 명확히 구분짓는다.
-
특정 함수가 자기가 속한 모듈의 함수나 데이터보다 다른 모듈의 함수나 데이터와 상호작용이 많으면 안좋다. 함수를 분리하거나 옮겨줘야 한다.
-
서로 연관된 데이터 뭉치는 하나의 객체로 묶어준다. (클래스로 만드는 것을 추천)
-
switch 문을 사용하지 말자. switch문은 조건절이 추가될 때마다 다른 switch 문들도 모두 수정해야 하는 패턴을 발생시킨다.
-
반복문은 filter나 map 같은 파이프라인 연산으로 제거할 수 있다.
-
당장 쓰지도 않는데 지나치게 후일을 도모하는 죽은 코드도 별로 좋지 않다. 나중에 이해하기 어렵거나 관리하기 어려워질 수도 있다.
-
체이닝 하는 코드는 객체 네비게이션 구조에 대한 종속성을 의미한다. 만약 중간단계를 수정해야 된다면 전체 코드를 수정해야 될 수도 있다.
// 예시
managerName = aPerson.department.manager.name- 클래스가 너무 거대해지면 필드가 많아지고 중복코드가 생기기 쉽다. 클래스도 따로 추출해서 필드를 쪼개고 같은 비슷한 컴포넌트끼리 묶어준다.
- 서브클래스가 부모로부터 상속받을 때 필요없는 것들은 상속받지 않게 한다.
- 주석은 적당한 양을 달아줘야 한다.
