회사의 업무로 코드를 리뷰하게 되었다. 모두 5개의 블럭으로 한 개의 블럭은 대략 100장 정도의 출력량이다. 오늘 끝냈는데 너무 싫은 작업이었다. 힘들게 진행하고 느낀게 징한만큼 무언가 적어서 정리해 놓아야 할 것 같은 의무감 까지 든다.

그렇게 힘든 것에 대한 이유를 그럴싸한 핑계와 나자신의 역량 부족으로 나누어 보자.

우선 핑계를 대본다면

c처험 코딩한 c++이라는 점. 전혀 oop같이 코딩되어 있지 않았다. 클래스라는 것은 단지 코드의 단위에 불과할 뿐이고, 데이터와 알고리즘이 같이 있다는 오직 그것 하나만을 만족 시켰다. 그외에는 기존의 c코드와 똑같다. 모든 멤버 변수와 메소드는 public이었고, 함수 이름과 변수 이름은 무지막지하게 축약되어 있고(왜 그토록 축약에 목을 매는지 이해가 되지 않는다.) 이름에 일관성이 없으며, 직관성 없는 이름, 일관되지 않은 헝거리안 식 접두사, 대충 지어놓은 함수 이름, 전혀 객체 간의 관계가 없고, 코드 파악을 위해서는 이곳 저곳을 몇 차례 순회해야 하는 등 등등등. 이 코드를 작성한 이는 회사에서 꽤나 인정받고 똑똑하고 일 잘하기로 소문난 사람이다. 그런데 과연 그가 이런 코딩을.

실장은 그렇게 얘기했다.(리뷰와 관계없이) 이곳의 코딩 스타일에 적응해야 한다고. 그러기 위해서는 시간이 필요하다고. 실장이 말한 적응이라는 것은 이러이러한 스타일이 좋으니 그것을 익히라는 것 보다는 이러이러한 진흙탕에서 몸부림쳐 나아가는 것에 익숙해 지라는 것일까?

또한 문서 하나 없고, 주석 없고, 테스트 케이스도 없다. 제공 api를 위한 샘플이 살짝 있을 뿐이다. 리뷰의 목적은 버그를 찾아내는 것이다.(요건 소극적 목적이다. 적극적 목적은 리뷰한다는 자체에 의해, 문서를, 코드 정리됨을, 테스트 케이스를 작성하게 하여 품질 자체를 높이자는 것이다.) 그러하기 위해서는 코드를 이해하여야 한다. 어짜피 구문상의 오류는 컴파일러가 잡아줄 것이고, 컴파일러가 보지 못하는 로직상의 오류를 찾아내기 위한 것이다. 그런데 코드를 이해하지 못한다면 리뷰의 의미가 없어진다. 5개의 블럭을 리뷰하는데 3주의 시간이 걸렸고(3주 맞습니다), 제대로 잡아낸 버그라고는 겨우 3개였다. 코드 자체에 버그가 정말 없었을 수도 있지만, 그렇지는 않을 것 같다. 대상 코드를 리뷰하려면 그 코드를 이해하고 있는 자가 리뷰해야 되는 상황이다. 그러나 이는 바람직하지 않다. 해당 업무와 관계없는 자가 리뷰하여도 성과가 나와야 한다. 그렇게 하기 위해서는 해당 블럭을 먼저 이해하여야만 하는데, 그런 상황이 아니다.

또한 총 500 페이지에 해당하는 코드량을 한번에 리뷰하는 것도 바람직하지 않다. 자주 조금씩 리뷰하여야 리뷰 자체의 로드도 줄이고 빠른 피드백과 혹시 잘못 개발했을 때의 전환이 가능하다. 이전 직장에서는 2주마다 리뷰를 진행했으며, 한번의 리뷰 시간도 30분이면 족했다. 그리 부담이 되는 로드가 아니었고, 그로 인한 충분한 효과를 봤었다. 코드의 바탕이 되는 설계문서의 유무확인, 해당 코드에 대한 테스트케이스의 존재 여부와 그 모양새. 테스트 케이스의 코드가 지저분할 수록 원 코드가 엉망인 것이다. 그리고 원 코드에서는 단지 가독성만을 보고 로직은 거의 신경쓰지 않았다. 클래스 간의 관계는 따로 보았고. 이렇기 때문에 훌훌 훑어가면서도 리뷰가 가능했었다.

코드를 이해하기 힘들다는 것은 높은 품질이 아니라는 것을 증명하는 것이다. 문제가 있다는 것이고 유지보수를 어렵게 만든다는 것이다.

이상이 그럴싸한 핑계이다. 워낙 코드가, 그리고 기타 산출물이 허접이어서 리뷰하기 힘들었다고.

하지만 이것을 솔직하게 회사에 얘기할 수 없다. 이러한 식의 접근 방법은 기존 조직의 결과물 가치에 대한 대한 직접적인 부정이 되기 쉽다. 3,4일이면 끝날 줄 알았던 리뷰가 다른 업무와 섞여서 3주가 넘어서야 마무리 한 현 상황에서는 이런 것들이 이유라 하더라도 핑계로 되어버리고 만다. 그저 잘 이해안되서 힘들었네요 하며 웃고 있어야 한다.

그리고 아무리 개판 코드라 하더라도 합리적인 시간안에 리뷰해 낼 수 없었다는 것은 어쨋든 나 자신의 역량이 부족한 것을 말하고 있다. 역량 부족으로 시원하게 뚫어 볼 수 없는 것도 있었고, 답답함에 진행해 나가면서도 집중하지도 못했고, 재미도 없었기에 손도 가고 싶지 않고. 지난주, 지지난주에 주말에 진행해 봐야 겠다고 출력된 것을 집에 가져갔었으나, 한장도 보지 않았다. 손이 가지 않았다. 평소 집에서는 결코 일하지 않는다라는 철칙을 깨뜨려가며 진행할 정도로 진행 속도에 부담이 있었다.

이번 리뷰를 진행하면서 처음 맏닿은 갈등은 리뷰의 기준의 변경이었다. 그리도 중요시 하던 네이밍은 완전히 제외하기로 했고, 문서 여부 신경쓰지 않고, 테스트 케이스 역시 무시하고, 클래스 간의 관계 역시 무시해야 한다는. 그리고 예외를 사용하지 않는 함수 정의에 대하여서도 무시하고. 그렇다면 도데체 무얼 리뷰해야 하는지에 대한 죄책감?이 리뷰 내내 같이 있었다.

분명 c/c++ 개발자와 java개발자는 문화가 틀리다. c/c++로도 당연히 훌륭한 코드의 작성이 가능하다. 당연하다. 그러나 내가 겪은 대부분의 코드는 그렇지 않았다. java개발자가 언어의 특성 혹은 혜택으로 추상화된 관계를 고민할 때 c/c++에서는 포인터와 메모리 문제, 지역적인 알고리즘에 고민할 수 밖에 없었고, 이런 사항은 일종의 문화까지 다르게 한 것 같다. 문화는 별거 아닌 습관의 총칭인 것이다. 어느 쪽이 훌륭하다 옳다 나쁘다 할 것은 없다. 하지만 굳이 바람직하지 않은 것을 고집하는 혹은 습관에서 벗어나지 못하는 것은 좋게 보이지 않는다. 가장 눈에 띄는 것이 축약이다. 어떻게서든 한자라도 줄이는 것이 과연 개발에 도움이 될까 싶다. 축약된 변수명과 함수명을 보면 눈물이 날 지경이다. 리뷰 내내 제일 못참게 했던 것이 축약이었다. 대충 짐작이 가능 경우라면 그렇다 싶지만, 그렇지도 않은 경우에는 불러다 물어보고 싶었다. 그런데 일일이 계속 불러댈 수도 없는 것이고.

오늘 java와 flex의 리뷰를 다시 받았다. 300장은 되는 것 같다. 궁굼하다. 역량이 부족한 것이었는 지 개판 코드 였었는 지.