1.함수의 이름을 짓는 방법과 관련하여 책에 서술된 조언을 쓰시오

• 이름은 코드를 명료하게 표현하는 가장 중요한 요소이다. 이름만 보고도 각각이 무슨 일을 하고 어떻게 사용하는지 명확히 알 수 있도록 신경을 써서 이름을 지어야한다. 이름을 잘 지으면 문맥 파악하는데 헤매는 시간을 크게 줄일 수 있다. 이름을 바꾸는 리팩터링에는 '함수 선언 바꾸기', '변수 이름 바꾸기', '필드 이름 바꾸기' 등의 리팩터링이 있다. 이름을 명명하는데, 마땅한 이름이 떠오르지 않는다면 설계에 문제가 있는지 고려할 필요가 있다. 이름을 잘 정리하면 코드가 간결해질 수 있다.

2. 책에 제시된 악취들 중 YAGNI와 가장 잘 어울리는 항목은 무엇인가

• 미래의 필요할지 알 수 없는 기능들을 미리 추가하는 것은 지양해야 하라는 YAGNI 원칙을 저자가 소개했다. 추측성 일반화는 YAGNI 요소와 관련된다고 볼 수 있다. '나중에 필요할 거야'라는 생각으로 당장은 필요 없는 모든 종류의 후킹 포인트, 특이 케이스 처리 로직을 작성해둔 코드에서 냄새가 생긴다. 이는 이해하기 어려워지거나 관리하기 어려운 코드가 된다. 추측성 일반화로 생기는 실제로 사용되지 않는 코드는 제거하는 것이 좋다. 추측성 일반화는 테스트 코드 말고는 사용하는 곳이 없는 함수나 클래스에서 흔히 보게 된다. 테스트에서만 사용되는 코드들을 테스트 케이스부터 삭제한 후 죽은 코드 제거하기로 날려버리도록 한다.

3. 주석과 악취의 관계에 대해 서술하시오

• 주석은 나쁜 것이 아니다. 하지만 주석이 장황하게 사용한다면 코드를 잘못 작성했는지 의심해야한다. 코드만 제대로 작성했을 때 주석은 필요없을 내용일 수 있기 때문이다. 이를 주석에서 악취가 난다고 볼 수 있다.
• 특정 코드 블록이 하는 일에 주석을 남기고 싶다면 함수 추출하기 적용해 본다. 이미 추출되어 있는 함수임에도 여전히 필요하면 함수 선언 바꾸기로 함수 이름을 바꿔본다. 시스템이 동작하기 위한 선행조건을 명시하고 싶다면 어서션 추가하기.주석은 무엇을 할지 모를 때, 현재 진행 상황, 확실하지 않은 부분에 주석에 남긴다. 코드 작성한 이유를 설명하는 용도로 달 수 있다.

4. OOP 개념을 적극 적용하지 않아 함수와 변수들이 제각각 흩어진 코드가 있다. 이 들을 모아 하나의 클래스로 만들고 싶다. 이에 해당하는 ‘악취’에는 무엇이 있는가, 그 이유를 설명하라.(의도 답 : 데이터 뭉치, 산탄총 수술, 그러나 대부분의 예시가 제시된 리팩터링 과정에 적용 가능한 만큼, 설명이 충분히 설득력 있다면 점수 가능)

OOP 개념을 사용하여 데이터, 함수들을 묶을 때, 무리하게 데이터를 묶다보며 데이터 항목 서너 개가 뭉쳐 다닐 수도 있다. 흩어져 있는 함수, 변수들이 상당한 중복이 발생하는 데이터 뭉치인지 고민을 해야한다. 데이터 뭉치인지 판단하기 위해서는 값 하나를 삭제하였을 때 나머지 데이터만으로 의미가 없으면 악취가 풍기는 데이터 뭉치라는 신호이다.

반대로 함수, 변수를 분리하였을 때 OOP 개념을 적극 적용하지 않아 산탄총 수술이 발생할 수 있다. 기능 수정이 필요하였을 때, 자잘하게 수정해야하는 클래스가 많을 때 악취가 발생할 수 있다. 변경할 부분이 코드 전반에 퍼져 있는 문제가 발생할 수 있다.

5. 책에 제시된 악취들 중 서로 상충되는 두 악취를 한 쌍 고르고, 이 둘 사이에 적당한 지점을 찾는 법에 대해서 개인의 생각을 서술하시오.

산탄총 수술과 뒤엉킨 변경을 저자는 정반대의 요소로 설명하고 있다. 뒤엉킨 변경은 변경이 발생할 때 한 코드에 섞여 들어가고 산탄총은 변경이 여러 코드에 흩뿌려져 있는 것을 수정하는 점에서 상충한다고 할 수 있다. 설계나 리팩터링을 하게 되었을 때, 해당 코드가 맞는 책임을 다하고 있는지 고민을 해야 한다. 저자는 맥락 구분을 잘 할 필요할 필요성을 강조한다.

코드가 이해하기 쉽고 책임을 다하는 영역을 파악하여, 데이터와 함수를 묶거나 어설프게 분리된 로직을 함수 인라인하게나 클래스 인라인하기로 산탄총 수술에 대처할 수 있다. 리팩터링은 저자의 강조하는 요소이다. 더 좋은 형태로 냄새를 제거하여 리팩터링한다.