refactoring #1 composing method

composing method

 refactoring 의 제일 기본. 코드가 길면 이해하기 어려워지고, 이해하기 어려우면 변경하기도 어렵다. 변경하기 어려워지면 방치될 수 있고, 잠재적인 결함의 원인이 되거나, 비즈니스 로직의 변경에 대처하는 비용이 증가하게 된다.

 독일에 와서 일하기 시작하면서,  code review 엄격하게 하는 환경이 되었는데. 가장 먼저 내가 받았던 review 들은 너무 길어서 이해하기 힘들다는 것이다. 별로 안길다고 생각했는데, 다시 생각해보니 "모르는 사람, 혹은 처음보는 사람 입장에서 코드를 봤을 때 이해하기 쉬운지" 의 관점에서 생각해본적은 한번도 없는 것 같다. 여러차례 review 에서 지적을 받은 끝에, 지금은  commit 할 때마다 길이를 다시한번 확인하는 습관이 생겼다. 제일 기본적인 내용이지만 생각해봐야 할 점들이 있다.

1. refactoring 혹은 review 를 하다보면 주석으로 적혀있는 것이 그대로 함수명이나 변수명이 되는 경우, 혹은 assert 의 문구가 되는 경우가 있다. 그런 경우 함수명이나 변수명이 그 뜻을 제대로 내포하지 못했다는 뜻이거나, 주석이 더 잘 표시했다는 경우이다.  우리회사에서의 주석의 정체는, what 보다는 why 에 대해 남기자는 정책인데,  why 에 대한 입장에서 naming 하는것이 더 깔끔한 경우가 있는것 같다. Exception 을 던지는 경우에도, Exception 옆에 주석을 다는 것보다, Assert(condition, "comment"); 로 표시하는 것이 더 깔끔해보였다.

2. 쪼개는 것의 단점

if(a() || b()) 의 경우,  a() 가 true 이면 b 는 실행하지 않는다. 어차피 true 이기때문이다. 하지만 이걸 extract 해서 위로 빼면 

aa= a()

bb = b()

if (aa || bb)

같은 식이 되므로, 이때는 항상 a(), b() 를 모두 실행한다. 따라서 refactoring 으로 인해 성능에 영향을 줄 수도 있다.

 비슷한 맥락에서, 변수를 사용하지 않는 경우 변수에 할당하지 않고 결과를 바로 리턴하는게 좋지만, 결과를 구하는 cost 가 상당해서 그 결과를  caching 해놓는게 좋은 경우는 변수에 저장을하는게 from the cost of performance point of view 더 나을수도 있다. 

 replace temp with query도 마찬가지. 한번 호출할 함수를 세번 호출하는데, 아무리 최신 cpu이고 효율적인  compiler  이고  간단한 연산이라도 cpu time  에 차이가 하나도 없을 수 있을까? refactoring 을 할 때 무조건 빼고 뽑고 쪼개는 것이 능사는 아닐수도 있다.

3. 간결함 vs  설명

 composing method  중에 method 의 내용이 단 한줄이면,  따로 빼지 않고 method 를 호출하는 쪽에 inline으로 처리하는 내용이 있다. 그런데 회사에서 접했던 코드 내용 중에는, 단 한줄이지만 그것이 무엇을 하는지를 설명하고 이름을 붙여 함수를 뺌 으로써, 읽는 이에게 도움을 주기 때문에 뺀 경우도 있었다.

 무엇이든 정답은 없지만, 요약하자면 길고 복잡해지면 어려워지고 중복이 발생할 수 있고 문제가 발생할 수 있기 때문에 잘 쪼개고 나누는것이 좋다. 하지만 쪼개고 나눈다는건 한번 계산할 걸 두번 할 수 있기 때문에 성능적인 측면에 영향을 끼칠 수 있음과, class  나 method  가 증가해서 전체적인 복잡도는 증가할 수 있다는 점도 알고 있어야한다.

vagaries

marginally

skimp

discrepancy