리팩터링이 필요한 이유
- 일부 코드를 메서드 밖으로 빼서 별도의 메서드를 만들고, 코드 일부를 상속 구조의 위, 아래로 올리거나 내리는 등의 작업이 누적되면 설계가 놀랍도록 개선된다. 소프트웨어가 부식된다는 개념의 정반대가 바로 리팩터링이다.
- 잘 정리된 용어는 개발 도구가 제공하는 자동화된 리팩터링을 선택하는 데 도움을 준다.
- 이해에 어려움을 느낀 부분을 정리하기
- 왜 이해가 안되는지 혹은 왜 이해 못한 것 같은지 고민해보기
- 긴 함수를 리팩터링할 때는 먼저 전체 동작을 각각의 부분으로 나눌 수 있는 지점을 찾는다.
- 함수명: (~에 대한 금액), 추출한 함수에는 그 코드가 하는 일을 설명하는 이름으로 지음
- 추출된 함수 코드를 들여다 보면서 지금보다 명확하게 표현할 수 있는 간단한 방법은 없는지 검토하며, 이를 통해
thisAmount
를result
로 변경. 저자는 변수의 반환 값에 항상 result 라는 이름을 씀. 그래야 변수의 역할을 쉽게 알 수 있음 - 첫 번째 파라미터 perf를 aPerformance로 리팩토링. 자바스크립트와 같은 동적 타입 언어는 타입이 드러나게 작성하면 도움이 됨. 매개변수 이름에 접두어로 타입 이름을 적는데, 매개변수의 역할일 뚜렷하지 않을 때는 부정 관사(a/an)을 붙임.
- 임시변수를 질의 함수로 바꾸기
컴퓨터가 이해하는 코드는 바보도 작성할 수 있다. 사람이 이해하도록 작성하는 프로그래머가 진정한 실력자다.
좋은 코드라면 하는 일이 명확히 드러나야 한다. 변수 이름은 커다란 역할을 한다.
- 반복문 쪼개기: 변수 값을 누적시키는 부분을 분리
- 문장 슬라이드하기로 변수 초기화 문자을 변수 값 누적 코드 바로 앞으로 옮김
- 함수 추출하기로 적립 포인트 계산 부분을 별도 함수로 추출
- 변수 인라인하기로 volumeCredits 변수를 제거
- redrebel
- youngbeomrhee
- devJang
- accidentlywoo
- korkorna
리팩터링을 업무에서 사용하기 어렵다는 질문을 드림
Typing Duck
리팩터링을 학습한 이후 회사에서 하루 종일 리팩터링을 하고 있다.
dev Jang
결국 회사는 이익을 추구하기 때문에 리팩터링을 사업적인 관점에서 이득을 추구하기 위한 작업으로 본다면 트레이드 오프가 어렵다 생각합니다.
redrebel
기능을 추가하기 위해선... 수정을 거치지 않을 수 없다. 리팩터링은 필수이다.
냄새가 나는 코드를 지나칠 수는 없다. 리팩터링은 프로의 자세이다.
함수에 대한 이야기를 나누던 중 '함수 이름이 나쁘면 그 코드 또한 나쁘다'는 이야기가 나와서 함수 이름을 다들 어떻게 지으시는지 물어봄
WhyBe
저도 이름 지을때 구글 번역기 많이 돌려요
dev Jang
저도 꼭 번역기 돌립니당
Typing Duck오후 10:35
가독성이 너무 안좋아서 추가기능을 넣을 수 없어요
redrebel
어떤 날은 출근해서 업무의 80%가 함수 이름짓는 일일 수도 있다.
함수는 하나의 역할만을 하는 것이 맞다.