개발의 어려움

사람마다 다르겠지만, 나의 경우에 있어 가장 어려운 것은 아마도

버릴지, 가질지, 혹은 언제 버릴지?

라는 것이다.
지금 작성하던 부분을 계속 잡고 늘어 져서 끝까지 고칠 것인지,
아니면 그것을 버리고 새로 작성할 것인지,
그리고 그것을 어떻게 재사용을 할 것인지, 이러한 부분들이 가장 어렵고 힘들다.

간단하게 대답하자면, 결국은 선택의 문제이지만,
글쎄.. 잡고 있었던 시간 만큼 쉽게 놓지 못하는건 미련에 아쉬움이고
이를 떨쳐내고 더욱 빠르게 원하는 시간내에 새로 만들수 있음에도 불구하고
그 아쉬움에 묶여 있는 것은, '무'로 돌릴 용기가 없기 때문이다.


물론 '무'는 아무것도 없는 것이 아니다.
그 문제를 해결하려 하면서 습득한 정보들로 인해서 아주 조금이라도 늘었으니 말이다.

그래도 그러한 무형의 증가보다
눈에 보이는 코드의 길이가 0으로 된다는 것은 쉽지 않은 결정이다.






나의 개발 방법은 다음과 같다.

1. 최소한의 입력과 출력을 정한다.
   - 함수는 black box로 입력과 출력을 가지고, 내부 작동은 타인이 모르도록 한다
   - 객체지향개념으로 봐도 무관하려나?

2. 사용가능한 이미 제작된 함수가 있는지 살펴보라
   - 내가 만드는게 빠르다고 생각될지 몰라도,
     디버깅에 필요한 시간을 따지면 이미 작성된 안정된 소스를 사용하는것이 유리하다
   - 그렇다고 그 함수가 너무 복잡하다면 차라리 자체 제작을 해서 최적화 시키는것이 낫다.

3. 원본 데이터는 되도록이면 손상시키지 않는다.
   - 요즘 시스템은 거의 대부분 메모리가 남아 돈다. 굳이 메모리를 아끼기 위해 cpu를 쓸필요는 없다.
   - 원본 데이터는 말그대로 원본이므로 원본을 유지해준다. 함수에서는 내부적으로 사본을 만들어 조작한다.

4. 함수가 커지면 함수를 조각내서 그것을 감싸는 함수를 만든다.
   - refactoring이라고 하던가?
   - 단일 기능을 가지는 함수들을 조합해서 더욱 큰 기능을 구현해 낼수 있고 이는 유닉스의 'simple is beautiful' 철학이다.

5. 주석을 남긴다. 하지만 그렇다고 남발하지 말 것.
   - 주석이 있으면 나중에 보기는 편하지만, 솔찍히 주석으로 보는것 보다는 너무 복잡하지 않다면 코드가 더 이해가 잘된다.
   - 주석을 위한 주석보다는 정말 이해하기 힘든부분에만 주석을 남긴다.
   - 주석을 남길정도가 된다면 함수로 분리를 한다. 함수 이름을 기능으로 나타내는게 더 알아 보기 쉽고 재사용에 유리하다

6. 주석을 남기고 싶다면 차라리 별도 문서로 작성하라.
   - 주석을 남겨야 할 정도로 복잡하다면 이미 주석으로 남기기에는 2% 부족하다.
   - 이러한 부분은 차라리 독립된 문서로 ppt나 doc 혹은 pdf로 별도 문서로 작성한다. (다음 사람을 위해)