코드 정리는 작은 리팩토링
코드 정리는 작게 시작하는 것이 좋다
조건문 안에 많은 코드를 작성하기 보다는
반대되는 조건으로 코드 상단에 return 문을 작성
if (조건) return
부합하는 경우에 작성하면 좋지만
너무 여러 조건에 대해 작성하면 이해하기 힘들다
안쓰는 코드는 지운다
나중에 필요할 경우 형상 관리 도구를 사용하여 복구할 수 있다
지울 때는 조금씩 지운다
if 문을 쓸 것인지 삼항 연산자를 쓸 것인지 등
여러 스타일로 작성할 수 있는 코드 스타일을 하나로 정하여
전체적으로 통일성 있게 작성해야 읽기 쉽다
루틴 호출 시 기존 인터페이스 때문에 어렵거나 복잡하다면
인터페이스를 새로 구현해서 호출한다
새 인터페이스를 사용하도록 모두 이전되었다면 기존 인터페이스를 지운다
코드를 읽기 좋은 순서로 다시 정렬하면 좋다
순서 정렬 시 세부 사항에 대해서도 눈에 들어온다면
순서 정렬과 세부 사항 둘 중에 하나를 선택하여 먼저 완료 후
다음 작업을 진행한다
하나의 동작에 여러 곳에 흩어져 있는 코드는 읽기 어렵다
코드의 순서를 바꿔 변경 요소들을 가까이 두어야 한다
두 루틴에 결합도가 있으면 가까이 둔다
파일도 두 파일에 결합도가 있으면 같은 폴더에 넣는다
결합도를 제거할 수 있다면 그게 가장 좋은 방법
다음과 같은 이유로 결합도 제거가 어렵다면 응집도를 높이는 배치를 실행
데이터 종속 순서를 고려하여 옮겨야 한다
긴 표현식들을 변수에 담아
변수 이름으로 코드를 설명하도록 하여
가독성을 좋게 하자
리터럴 상수로 사용된 곳은 상징적인 상수로 바꾸면 좋다
변수와 같은 맥락인 것 같음..
객체를 전달받는 함수의 경우 객체 내의 어떤 정보가 필요한 것인지 명시적으로 알기 어렵다
필요한 것만 전달할 수 있도록 명시적으로 바꿔주면
함수의 기능에 대해 더 빠르게 이해할 수 있다
긴 코드에서 서로 다른 역할을 발견하면 줄바꿈으로 구분을 주어 분리한다
일단 관련 있는 코드끼리 뭉쳐두는 것으로 더 좋은 방향으로 가기 위한 발판을 만든다
추려내어 도우미로 추출한 후에 이름을 붙인다
루틴 속에서 나머지 코드와는 상호작용이 적은 블록을 만날 때가 있다
그런 블록은 따로 추려내어 도우미로 추출한 후에 이름을 붙인다
이름은 작동 방식이 아니라 목적에 따라 이름을 짓는다
-> 메서드 추출 리팩터링
되도록 자동화 도구를 사용하는 편이 좋다
응집도가 높은 요소 만들기로 이해할 수 있다
순서가 보장되어야 하는 경우
foo.a()
foo.b()
의 경우
ab()
a()
b()
코드가 여러 개의 작은 조각으로 나뉘어 있을 때
흩어져있으면 코드를 전체적으로 이해하기 어렵다
필요한 만큼 하나의 더미처럼 느껴질 때까지 흩어진 코드를 모아서 정리한다
코드를 만들 때 가장 큰 비용은 작성이 아니라 읽고 이해하는데 드는 비용이다
작은 코드 조각들이 서로 교류하는 방식은 코드를 더 알기 어렵게 한다
코드를 한데 모아서 이해하기 어려운 부분은 추출하여 새롭게 정리한다
하나의 더미는 반 정규화 같은 느낌인듯
코드를 처음 읽는다고 생각하고
명확하지 않은 내용에 대해서 주석을 적는다
미리 알았으면 좋았을 점이나 코드의 의도 등
코드 결함 발견 시 그 즉시 해당 위치에 주석을 단다
코드만으로 이해할 수 있다면 주석은 지운다
간단한 코드에 대한 주석은 비용만 발생하고
혜택은 없다