[Refactoring] Chapter 3, 4 과제

과제가 지겨운 감이 있는데... 다음주 부터는 실습을 통한 과제가 나온다고 하니 일단 참고 해보겠습니다ㅜ

 

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

함수의 이름만 보고도 무슨 일을 하고 어떻게 사용해야 하는지 명확히 알 수 있도록 엄청나게 신경써서 이름을 지어야 한다고 저자는 말합니다. 이름은 코드를 명료하게 표현하는데 가장 중요한 요소 입니다. 이름을 짓는데 마땅한 것이 떠오르지 않는다면 설계에 더 근본적인 문제가 있을 수 있다고 합니다. 그래서 혼란스러운 이름을 잘 정리하면 코드가 훨씬 간결해질 때가 많습니다. 단순히 이름을 짓는 행위 뿐 아니라 설계를 다시 돌아볼 필요가 있습니다. 
기이한 이름을 만나면 함수 선언 바꾸기, 변수 이름 바꾸기, 필드 이름 바꾸기를 시도해 볼 수 있다고 합니다. 뒷쪽 챕터에 구체적인 내용이 나와있어서 예시는 못봤지만 함수의 역할을 다시 생각해보고 여러 요소를 변경해볼 수 있습니다. 프로그래밍을 하는 동안 많은 시간은 네이밍을 변경하는데 사용됩니다. 그 만큼 어렵지만 리팩토링에 있어서 핵심적인 부분을 차지합니다. 테스트 코드가 있다면 테스트 코드에서 먼저 함수 이름을 정의하는게 네이밍을 정확하게 깔끔하게 하는데 도움이 될 수 있습니다.

 

2 책에 제시된 악취들 중 YAGNI와 가장 잘 어울리는 항목은 무엇인가(500자 이상)

3.15 추측성 일반화(Speculative Generality)가 YAGNI와 잘 어울리는 악취입니다. 나중에 필요할 거야 라는 생각으로 당장에 필요없는 작업들은 해둔 경우에 발생하게 됩니다. 미래에 사용되면 다행이지만 사용되지 않는 경우도 많습니다. 이런 코드를 만나면 당장 눈앞에서 치워버리자고 저자는 말합니다. 프로그래밍을 할 때 이런 코드를 발견되면 또 다른 곳에 사용될 일이 있을 것 같아서 지우지 못하는 경우가 많은데, 용기를 내서 삭제해야겠습니다. 지금 삭제하더라도 git을 통해 이전으로 돌릴 수 있어서 리팩토링을 통해 코드를 삭제하는 것이 코드를 깔끔하게 유지하는데 도움이 될 것 같습니다.
이런 코드를 수정할 때는 계층 합치기, 함수 인라인하기, 클래스 인라인 하기를 시도할 수 있습니다. 본문에서 사용되지 않는 매개변수는 함수 선언 바꾸기로 없앨 수 있습니다. 
테스트 코드 말고는 사용한 곳이 없는 함수, 클래스에서 흔히 볼 수 있다고 합니다. 혹시 테스트 코드에서만 호출되고 있는 함수나 클래스가 있지는 않은지 확인하는 습관을 들여야겠습니다.

 

3. 주석과 악취의 관계에 대해 서술하시오 (500자 이상)

주석 자체는 좋은 것 입니다. 주석은 악취가 아닌 향기를 입힙니다. 하지만 주석을 잘못 사용해서 탈취제 처럼 사용하는 경우 문제가 된다고 저자는 말합니다. 주석이 장황하게 달려 있다면 코드를 잘못 작성해서 주석이 필요했던건 아닌지 확인할 필요가 있습니다. 특정 코드 블록이 하는 일에 주석을 남기고 싶다면 함수 추출하기를 사용하고, 여전히 설명이 필요하다면 함수 이름을 바꾸어봅니다. 선행조건을 명시하고 있다면 어서션을 추가할 수 있습니다. 이렇듯 주석을 남겨야겠다는 생각이 들면, 가장 먼저 주석이 필요 없는 코드로 리팩토링 해볼 수 있습니다. 
주석이 유용하게 사용될 때도 있습니다. 확실하지 않은 부분에 주석을 남기고, 코드를 지금처럼 작성한 이유에 대해 설명해 둘 수 있습니다. 이런 코드를 작성해두면 나중에 다른 프로그래머가 임의로 코드를 변경하게 되는 일을 막을 수 있습니다. 꼭 필요한 경고문이나 히스토리를 주석으로 남겨두는게 유용한 때가 있었습니다. 따라서 주석을 무조건 나쁜 것으로 여기면 안됩니다.

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

코드를 변경할 떄마다 수정해야하는 클래스가 파편화되어 있다면 '산탄총 수술' 악취가 풍기는 것으로 판단할 수 있습니다. 변경할 부분이 한 군데 있지 않으면 찾기 어렵고 꼭 수정해야하는 부분을 놓치기 쉽습니다. 실수하기 어려운 설계가 좋은 설계라는 이야기가 있습니다. 여러 코드에 흩뿌려진 내용들을 맥락별로 모아두는 과정이 필요합니다.

변수 몇개가 비슷한 곳에서 발견된다면 클래스로 만들어지기를 원하는 데이터 뭉치들 일 수 있습니다. 데이터 뭉치 중에서 값 하나를 삭제해보고 나머지 데이터 만으로는 의미가 없다면 객체로 다시 만들어주는 것이 적절할 수 있습니다. 이러한 변수들을 클래스로 만들어주면 좋은 향기를 만들 기회가 생깁니다. 많은 중복을 없애고 추후에 개발을 유용하게 해주는 도구가 될 수 있습니다. 업무를 할 때도 비슷한 패턴으로 나오는 변수들을 봤었는데 UI 동작을 위한 몇가지의 트리거 모음들이 그러했습니다. 해당 변수들을 클래스로 묶어주면 좀 더 나은 코드를 만들 수 있겠다는 생각이 들었습니다.

 

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

뒤엉킨 변경과 산탄총 수술이 비슷한 원인으로 발생하는 악취입니다. 여러 변경 내용이 한 코드에 섞여 있는 경우와, 하나의 변경 내용이 여러 코드에 흩어져 있는 경우로 볼 수 있습니다. 결과적인 모습은 비슷한 모습이 되어야 할텐데 하나의 변경 요소는 하나의 객체와 함수에 모아져 있는 모습으로 리팩토링 되어야 합니다.

 

6. ‘가변 데이터’ 와 ‘전역 데이터’ 악취 각각에 대해, 그리고 가변 데이터가 동시에 전역 데이터인 악취에 대해 설명하시오. (500자 이상)

가변 데이터는 변수를 수정 가능한 상태로 열어둘 때 발생할 수 있는 악취입니다. 객체의 역할과 상관없이 변수를 변경 가능하도록 하면 의도치 않은 동작이 발생할 수 있습니다. 그래서 함수형 프로그래밍에서는 사이드 이팩트를 줄이기 위해 불변형 객체를 사용합니다. 객체지향에서는 가변 데이터가 발생할 수 밖에 없으므로 악취를 줄일 수 있는 여러 방법을 사용합니다. 변수 캡슐화하기, 변수 쪼개기, 세터 제거하기 등을 사용할 수 있습니다.

전역 데이터는 코드의 어디서나 변경할 수 있기 때문에 디버깅 하기가 힘든 경우가 많습니다. 어디서 어느시점에 변경했는지 찾아내기가 어렵기 때문에 악취로 분류됩니다. 이러한 데이터를 발견하게 되면 함수로 감싸는 것이 도움이 됩니다. 함수로 감싸면 데이터를 수정하는 부분을 찾기 쉬워집니다.

가변 데이터인 동시엔 전역 데이터인 경우는 꽤나 까다롭습니다. 값이 바뀌지 않는다고 보장된 전역 데이터인 경우라면 안전한 편 입니다. 코드 어디서든 변경이 되는 데이터가 디버깅하기 훨씬 힘듭니다.