단순함의 미학.

이런 말이 있다.

Simple is beautiful.

충분히 동의하는바이다... 가만보면, 좀 더 생각하고 고려해서 한방향으로 쉽게 갈 수 있는길을... 대충 생각하고 이렇게저렇게 하다보니 '어? 안되네?' 하고 다시 옆길로 샛다가 다시 돌아오는..우회도로 코드를 작성한다. 결과는? 원래 생각한 대로의 방식이 아니므로 논리적이 구멍이 생기고 그로 인해 버그가 발생한다...

그래서 하나의 함수 및 클래스는 하나의 일만 담당하는것이 좋다.

그러나 만들다보면....특정 클래스(혹은 함수)에서 A, B 작업이 있는데 거의 대부분의 작업들이 A -> B 순서대로 진행되어진다. 그럴경우 많은 개발자들이 사용자 편의를 위한답시고 저 2가지의 함수를 아예 합쳐버리거나(...) 혹은 클래스 public 함수로 하나의 함수를 더 만든다. 그러지 말자는것.

차라리 따로 helper 함수를 하나 만드는것이 훨씬 좋다. 지금 A->B 상태라지만 나중에 C가 추가되어서 A->B->C가 될수도 있잖아? 어떻게 바뀔지는 아무도 모르는일. 그렇다면, 클래스 자체에서는 깔끔하게 하나의 작업만 하는 함수들을 남겨두고, 일괄처리같은거를 helper 함수로 해놓았으니 그것만 수정한다면, 기존 소스코드를 고치는 일도 적어지고, 보다 flexible 하게 대처할 수 있는것이지.

C로 생각한다면, struct A, B 가 있다고 치자. 근데 둘간에는 공통분모가 있다고 한다면 그것을 따로 빼서 A, B, C로 만들고, C를 처리하는 함수를 fooC()로 하고나면, fooA() 에서는 A에 해당되는부분 처리 후 fooC() 를 호출하고, fooB()에서는 B에 해당되는부분 처리 후 fooC()로 처리하는것.

구조체 개수가 2개에서 3개로 늘어났으니 더 관리가 힘들어졌다? 전혀 그렇지않다. 오히려 기존의 fooA,fooB 함수에서 처리하던 공통적인 부분을 fooC()로 분리해냈으니 코드 사이즈가 줄었고, 공통적인 부분인 C 부분에 대한 코드가 duplicate 되어있던것을 삭제했으니 오히려 개선효과가 있는것이다.

결론은? 기능추가 시에 급하다고 무턱대고 추가말고, 좀 더 생각해보면 간단한 방법은 존재하기 마련이라는것.




ps : 그러나...simple is best 는 아니다. 분명히 복잡하게 풀어야하는 것도 존재한다. 그러나, 그 복잡한 문제마저도 보다 간단하고 명료하게 문제를 풀 수 있는것이야 말로, 더 좋은 개발자가 되는 방향이 아닌가 싶다.