일상 혹은 이상

프로그램 읽기에도 그에 맞는 접근법이 필요하다. 소설과 달리 프로그램은 처음부터 끝까지 차례대로 읽는 방식이 항상 최선은 아니다. 그렇다고 해서 추리 소설처럼 클라이맥스 바로 앞 부분에서 건너뛸 수는 없다. 또는 외설 잡치처럼 사라들이 접어 놓은 곳이 그중 가장 볼 만한 부분이라 생각할 수도 없다. 프로그램에서 어느 부분이 재미있을 것인지는 예상할 수 없다. 나중에 디버깅이나 최적화 등을 할 때 관련된 핵심부분을 찾아내는 방법을 알게 될 테지만 말이다. 대신 우리는 프로그램 각 부분의 발단으로 구성된 개념적인 프레임워크를 토대로 프로그램을 읽어야 한다. 즉, 코드를 한 줄 만날 때마다 "이 코드가 왜 여기에 있을까?"를 생각하는 것이다.

--- 프로그래밍 심리학,  "프로그램 읽기" 중

프로그래밍 심리학에 좋은 내용이 많지만 이 부분 만큼 내게 큰 통찰을 가져다 준 부분은 없었던 것 같다. 이 부분만 있었다고 해도 나는 기꺼이 이 책을 샀을 것이다.

오늘 처럼 무언가 정리되지 않아 보이는 코드, 리팩토링에서 말하는 소위 악취가 풍겨오는 코드를 만났을 때 이 말을 먼저 떠올렸으면 좋았을 것을.. 코가 마비되었는지 정신이 마비되었는지 이성적으로 루틴을 쫓아가기 보다는 그저 깨진 창문을 만났으니 나도 같이 깨뜨려주마.. 하며 너저분한 코드에 어울리는 너저분한 코드를 가정을 바탕으로 마구마구 생산해냈으니.. 삽질에 삽질을 거듭하고.. 땜빵에 땜빵을 거듭하고.. 결국 문제는 해결했지만 그다지 세련된 해결책은 아니라 결국 내일을 기약하고 자정이 다 되서야 회사를 나섰다.

터벅터벅 집까지 걸어오는 길에 곰곰히 생각하니 오늘 내가 대체 무슨 짓을 한 거야! 하는 생각이 들었다.

겉보기에 맘에 들지 않는 코드라도 대충 훑어 보고 동작이 이해가 가질 않아라고 절규하기 보다는 이 녀석이 적어도 동작하는 코드라면 '이 코드가 왜 여기에 있을까?' 하고 차근차근 검토했어야 하는 건데 말이다. 아직 수양과 덕이 부족한 모양이다.

그러는 한편 왜 코드가 저런 상태가 된 걸까? 비단 프로그래머만의 잘못일까? 하는 생각도 해보았다. 오늘 나의 경우에 비추어 볼 때는 오늘 몇 시까지 해내야 한다는 시간의 압박이 여러 가정들을 만들어 냈고 그 가정 속에서 문제를 해결하려다 보니 실제 사실(진짜 코드)을 인식하는데 많은 시간을 소비했던 것 같다. 아마 이 전에 그 코드를 거쳐간 프로그래머들 역시 이런 일정 압박에 쫓겨 깨진 창문을 방치하다 보니 그렇게 된 것은 아닐까..

어쩔 때 보면 소프트웨어 개발이라는 것은 단지 사람과 컴퓨터와의 관계가 아니라 사람과 사람의 관계라는 생각도 든다. 시킨 사람과 하는 사람.. 만든 사람과 그것을 고치는 사람.. 과거의 사람과 현재의 사람.. 등등..

내일은 가서 쓰레기도 줍고 깨진 창문도 고치고 해야겠다. 일단은 이 녀석이 왜 여기 있는거야!를 고민해 보는게 먼저겠지만.. :)