과정과 결과

관리자는 과정을 보고, 사용자는 결과를 본다.

어디에나, 어떤 것에나 과정과 결과라는 생각 거리가 있다. 모나리자를 만든 과정이 우리에게 중요할까? 잘 달리고 있는 지하철 5호선이 어떻게 만들어졌는지가 현재 우리에게 중요할까? 이렇듯 만드는데 참여하지 않은 대다수 사용자에게는 마지막 결과물이 중요한 경우가 많다.

개발자들에게는 개발 과정 중에 일어나는 코드의 변화를 관리해야할 필요가 생기게 된다. "버전관리"(SCM)라고 되어 있는 것 중 코드를 다루는 개발자들에게 중요한 것은, 언제 왜 그 코드가 거기에 들어가게 되었는가를 따져보는 것도 중요한 일 중의 하나이다.

svn blame

흔히 annotate 로 알려져 있는 명령이다. "svn praise" 라는 명령도 같은 일을 한다. 이 명령들은 과거에 어떤 일이 일어났는지 행단위로 알 수 있게 해준다.

과정이 중요하다는 것과 달리 이 글에서 말하고 싶은 것은, "결과가 중요하지 아니한가"는 것이다. 아니 개발을 멋있게 했다고 그래도 최종 코드가 예뻐야하지 않는가? 코드가 볼 만해야하지 않는가? 코드를 일부 수정하여 커밋할 때마다 항상 다음과 같은 생각을 염두에 둔다. 기본이다.

• 내가 지금 반영하는 코드의 각 부분부분의 변화가 정말 의미 있는 것인가?
• 혹시 인덴트가 바뀌었다고 커밋하지는 않았나?
• 혹, 네이밍 컨벤션때문에 커밋하지는 않았나?
  
• 내가 올리는 이 단순한 커밋때문에 과거의 기록이 묻혀버리지는 않을까?
  

중요한 생각들이며, 반드시 해야한다. 위에서 말한 과정 속에서 변경 기록을 남기기 위해 지켜야할 규칙들이다. 커밋하기 전 diff를 해보고, 내 변경이 이전 변경에 대해 기록을 덮어 쓰게 되지는 않는가?그것이 바이너리 파일이 아닌바에는 한 줄 한 줄의 변화가 의미 있어야하는 것이다. 커밋하나 할 때마다 이런 규칙들이 정교하게 지켜져야한다. 그러니 적어도 스스로 자책하지 않으려면, 최초에 인덴트, 네이밍 확실하게 해야한다. 예를 들어 보자

Revision 1: 최초 구현

1: for( i=0; i < MAX; i ++ )
1: {
1:     do_something( i );
1: }

Revision 2: MAX 를 사용하는 것이 버그였으며 BUFF_MAX 를 이용해야하므로 수정함.

2: for( i=0; i < BUFF_MAX; i++ )
1: {
1:     do_something( i );
1: }

Revision 3: 들여쓰기 오류가 지적되어 "{" 위치와 "( )" 앞 뒤의 공백을 조정

3: for(i=0; i < BUFF_MAX; i++) {
3:     do_something(i);
1: }

("{" 를 내리는 것도 문제가 된다.)
물론, BUFF_MAX 보다 인덴테이션이 더 중요했다고 말하면 할 말이 없다. 하지만, 이런 오류는 파일전반에 걸쳐 지적되기 쉽고, 상당히 많은 곳에 "들여쓰기 오류로 인해 수정" 이라는 기록이 마지막이 될 것이다. 예를 들어 설명했지만, 이와 같이 커밋이 처음부터 신중하게 되어 규칙을 지켰더라면 더 아름다운 기록이 될 것이다.

이렇게 생각하고 나면, 정말 커밋이 두려워지고, 사소하다 생각된 들여쓰기를 수정하지 않으면, 나중에 보다보면 들여쓰기도 위아래가 들쭉날쭉이 된다. 단순한 예를 들어 설명했지만, 이런 비슷한 것에는

• 행 끝에 주석 달기
• 함수 위치 옮기기
• 함수 위치를 다른 파일로 옮기기
• 노출 되지 않는 함수에 static 달기
• 변경되지 않는 함수 인자에 const 달기
• 변수 이름 변경하기
• 숫자를 define으로 치환하기
• 보기 좋게 enumeration 정렬하기

등이 있다. 이런 기본적인 것이 되지 않은 다른 사람의 코드나 어릴적(?) 코드를 보게 되면 사실 과거 히스토리를 생각하면, 수정하여야겠다는 욕구를 억눌러야하고, 실제로 억누른다. (나만 이러한가?)
파일 이름을 바꾸거나 다른 곳에 옮길 때도 svn의 경우 "svn copy" 를 써서 히스토리를 가져올 수 있어야한다. 그렇지 않으면 이전 변경 기록들은 모조리 사라지게 된다.

어찌, 과정을 중요시하는 것이 예쁜 결과를 눈 앞에 두고도 고치는 것을 억눌러야하는가! 사실, 코딩 컨벤션이나 엉성하게 작성된 코드는 나름 과거도 관리해야할 필요가 없을 정도로 커밋되었을 가능성이 많지 않은가?! 아우우~!

관리자로서, 코드의 변화를 중요시하고 이력관리를 해야하는 것과 잘못 작성된 코드에 대해 고쳐야하는 심정은 스스로 싸우게 되기 마련인것 같다.

내적갈등의 외적 표현이라 생각하시고 글읽기를 마무리 해주셨으면 한다.