냄새나면 당장 갈아라 - 켄트 백 할머니의 육아 원칙 1. 기이한 이름 추리 소설이라면 무슨 일이 전개되는지 궁금증을 자아낼수록 좋지만, 코드는 아니다. 세계적인 기인이라는 느낌을 풍기고 싶더라도 꾹 참고 코드는 단순하고 명료하게 작성해야 한다. 코드를 명료하게 표현하는 데 가장 중요한 요소 중 하나는 바로 이름이다. 그래서 함수, 모듈, 변수, 클래스 등은 그 이름만 보고도 각각이 무슨 일을 하고 어떻게 사용해야 하는지 명확히 알 수 있도록 엄청나게 신경 써서 이름을 지어야 한다. 하지만 아쉽게도 이름짓기는 프로그래밍에서 가장 어렵기로 손꼽히는 두 가지중 하나이다. 그 때문에 우리가 가장 많이 사용하는 리팩터링도 함수 선언 바꾸기, 변수 이름 바꾸기, 필드 이름 바꾸기처럼 이름을 바꾸는 리팩터링들이다...

함수는 프로그램을 작은 부분으로 나누는 주된 수단이다. 함수 선언은 각 부분이 서로 맞물리는 방식을 표현하며, 실질적으로 소프트웨어 시스템의 구성 요소를 조립하는 연결부 역할을 한다. 건축과 마찬가지로 소프트웨어도 이러한 연결부에 상당히 의존한다. 연결부를 잘 정의하면 시스템에 새로운 부분을 추가하기가 쉬워지는 반면, 잘못 정의하면 지속적인 방해 요인으로 작용하여 소프트웨어 동작을 파악하기 어려워지고 요구사항이 바뀔 때 적절히 수정하기 어렵게 한다. 다행히 소프트웨어는 소프트하기 때문에 연결부를 수정할 수 있다. 단 주의해서 해야 한다. 이러한 연결부에서 가장 중요한 요소는 함수의 이름이다. 이름이 좋으면 함수의 구현 코드를 살펴볼 필요 없이 호출 문만 보고도 무슨 일을 하는지 파악할 수 있다. 하지만 ..

변수는 함수 안에서 표현식을 가리키는 이름으로 쓰이며, 대체로 긍정적인 효과를 준다. 하지만 그 이름이 원래 표현식과 다를 바 없을 때도 있다. 또 변수가 주변 코드를 리팩터링하는 데 방해가 되기도 한다. 이럴 때는 그 변수를 인라인하는 것이 좋다. 절차는 다음과 같다. 1. 대입문의 표현식에서 부작용이 생기지는 않았는지 확인한다. 2. 변수가 불변으로 선언되지 않았다면 불변으로 만든 후 테스트한다. 3. 이 변수를 가장 처음 사용하는 코드를 찾아서 대입문 우변의 코드로 바꾼다. 4. 테스트 한다. 5. 변수를 사용하는 부분을 모두 교체할 때까지 이 과정을 반복한다. 6. 변수 선언문과 대입문을 지운다. 7. 테스트 한다. 이것을 리팩토링하면 간단하다.

변수를 추출하는 것은, 리팩터링의 목적 중 하나인 코드의 가독성을 높이는 역할을 한다. 우테코 미션에서도 리뷰어 님들이 중간에 알아보기 힘든 코드가 있으면, 변수로 추출하라고 리뷰를 남겨주시기도 한다. 그런데 인라인으로 두어도 되는 코드를 일부러 변수에 할당하여 가독성을 높이라고 하셨던 리뷰어님도 계셨는데, 이 원칙을 지키다 보니, 모든 코드를 가독성을 주기위해서 변수에 할당하고 있었다. 어떤 미션에는 비동기 로직을 작성하는 코드가 필요했는데, 간단히, get,post,delete,put에 대해서 fetch를 하는 함수였다. response라는 객체로 무조건 응답값을 받아서 반환하고 있었는데, 이런 경우는 오히려 인라인으로 작성하라는 리뷰를 받았었다. 왜냐하면, "수정될 일이 적고", "누구나 이해할 수..

표현식이 너무 복잡해서 이해하기 어려울 때가 있다. 이럴 때 지역 변수를 활용하면 표현식을 쪼개 관리하기 더 쉽게 만들 수 있다. 그러면 복잡한 로직을 구성하는 단계마다 이름을 붙일 수 있어서 코드의 목적을 훨씬 더 명확하게 드러낼 수 있다. 이 과정에서 추가한 변수는 디버깅에도 도움된다. 디버거에 중단점을 지정하거나 상태를 출력하는 문장을 추가할 수 있기 때문이다. 변수 추출을 고려한다고 함은 표현식에 이름을 붙이고 싶다는 뜻이다. 이름을 붙이기로 했다면 그 이름이 들어갈 문맥도 살펴야 한다. 현재 함수 안에서만 의미가 있다면 변수로 추출하는 것이 좋다. 그러나 함수를 벗어난 넓은 문맥에서까지 의미가 된다면, 그 넓은 범위에서 통용되는 이름을 생각해야 한다. 다시 말해서 변수가 아닌 함수로 추출해야한다..

함수 인라인하기는 함수 추출하기의 정반대의 기법이다. 분명히 함수 인라인하기를 읽을 때에는, 내 코드를 슈도코드 급으로 가독성이 있게 만들겠다라는 생각이 들었는데, 오히려 그 함수를 인라인함으로써 가독성이 떨어질 수 있고 코드가 더러워질 수 있다는 생각을 들으니, 어디까지가 적절한 수준인가에 대한 의문이 들었다. 뭐가 읽기좋고 나쁘고는 결국엔 개인의 주관이 많이 개입할 것 같은데, 흠.. 이 부분은 의식하고 있다가 나에게 같은 경우가 생긴다면, 고려를 해봐야하나? 굳이 정하자면 제 3자가 읽기에 불편하지 않는 선에서는 인라인을 유지해도 괜찮을 것이라는 생각을 했다. 일단 확실하게 인라인하면 안되는 경우를 먼저 짚어보자. => 인라인하려는 함수가 다형 메서드일때, 서브클래스에서 오버라이드를 안해버리면 정상..

리팩터링 책은 목적이 분명히 드러나는 이름의 짤막한 함수를 이용하기를 권한다. 그래야 코드가 명료해지고 이해하기 시워지기 때문이다. 하지만 때로는 함수 본문이 이름만큼 명확한 경우도 있다. 또는 함수 본문 코드를 이름만큼 깔끔하게 리팩터링할 때도 있다. 이럴 때는 그 함수를 제거한다. 간접 호출은 유용할 수도 있지만 쓸데없는 간접 호출은 거슬릴 뿐이다. 간접 호출을 너무 과하게 쓰는 코드도 흔한 인라인 대상이다. 가령 다른 함수로 단순히 위임하기만 하는 함수들이 너무 많아서 위임 관계가 복잡하게 얽혀 있으면 인라인해버린다. 그중 간접 호출을 유지하는 편이 나은 경우도 있겠지만, 모두 그렇지는 않을 것이다. 함수 인라인하기를 활용하면 유용한 것만 남기고 나머지는 제거할 수 있다. 절차는 다음과 같다. 1...