좋은 코드를 가늠하는 확실한 방법은 ‘얼마나 수정하기 쉬운가’이며, 좋은 코드를 위한 리팩터링은 기능은 유지한 채 유지보수가 쉽도록 코드를 재구성하는 것이다.
리팩터링 시에는 기능을 건드리지 않고 오롯이 리팩터링만 해야하며, 기능 추가를 할 때는 기능 추가만 하여야 한다.
특정 기능을 하는 함수조각을 분리하여 해당 기능을 쉽게 보여줄 수 있다.
함수를 쪼개면서 임시 변수를 최대한 제거한다.
함수의 기능을 직관적으로 알 수 있도록 함수의 이름을 바꾸는 리팩토링.
처음부터 최선의 좋은 이름으로 바꾸려 하지 않아도 된다. 여러 번 보다보면 적절한 이름이 떠오를 때도 있다.
특정 상황에서는 class 문법을 적절히 사용하여 조건부 로직을 다형성으로 바꿀 필요가 있다.
나는 중첩함수를 만들 때 어느곳에서도 사용할 수 있도록 매개변수를 전달하려는 경향이 있는데, 이미 선언된 변수를 사용하는 것이 좀 더 명확하게 보일 수 있다.
쪼갠 함수블럭을 통해 구한 값은 result = {} 와 같이 오브젝트 값으로 넣고, result.customer, result.totalAmount, total.VolumeCredits 와 같이 각각의 값으로 넣어 result를 반환한다면 진행사항을 저장할 수 있을 뿐만 아니라 결과값을 활용하기도 쉬워진다.
인풋값 체크나 에러체크가 중요한 것은 알지만 늘 놓치게 되는 부분이다. 원하지 않는 값을 입력하면 에러를 반환하여 이후 버그가 생기지 않도록 한다.
여느 프로그래밍 책에서도 강조하는 것이지만 리팩터링에서도 테스트를 강조한다.
테스트의 필요성이 가장 와닿았던 부분은 다른 사람이 작성한 코드를 리팩터링할 때 테스트코드가 없다면 리팩터링하기가 매우 힘들어진다는 것이다.
당장 내가 작성한 코드도 괜히 건드렸다가 잘못될까봐 못건드리는 상황이 많은데, 다른 사람이 작성한 코드는 더 심하다. 이때문에 리팩터링하기 꺼려지는 프로젝트들이 꽤 있는데, 테스팅코드가 있다면 기꺼이 리팩터링을 진행하지 않았을까 싶다.