한동안 코드 품질의 절대적 기준은 가독성이라고 믿고 있었다. 성능, 메모리 사용, 등등의 여러 품질 속성이 있겠지만, 그런거 필요없이 가독성이 절대적이라고 믿고 있었다. 특히나 요건 성능때문에 이런거에요 라는 변명은 여지없이 묵살해 주었다. 실지로 보면 이유이라기 보다는 습관적으로 아무런 생각없이 찍어낸 코드에 대한 변명에 불과하다. 자신이 코딩하는 클래스가 어떤 것인지 개념도 못잡고 있는 경우도 있으며, 마구잡이식의 메소드 이름 혹은 변수명 역시 단순히 가독성이라는 기준으로 걸러질 수 있다. 주석 필요없이 코드 만으로 읽히고 이해되는 코드가 제대로된 것이라 믿고 있었다.

요즘 어떤 문서를 만들고 있다. c/c++ 개발쪽 분들을 위한 java쪽의 trend를 알려주기 위한 목적이다. 다소 위험한 문서인데, 그 중의 한 항목이 가독성에 대한 얘기이다. 이것 저것 다 필요없고 가독성이 절대 기준이라고 한. 바로 위에서 언급한 그. 문서 자체도 위험하지만 요말 자체로도 꽤나 위험하다. 그럼에도 불구하고 강조할 필요가 있다고 느꼈었다. 더군다나 누군가가 언급했던 프로그래밍은 알고리즘과 데이타구조라고 했던 것조차 거부하는 내용도 있었고.

그런데 잊고 있었던 것을 깨닭았다. 요즘 Beautiful Code를 읽고 있는데, 첫 챕터의 정규식 표현을 처리하는 코드를 보았다. 그야말로 깔끔하고 훌륭하다. 물론 가독성도 당연하지만, 그 코드에는 가독성이외의 것이 있었다. 이런 것이 알고리즘이라고 하겠다. 프로그램에는 알고리즘이 빠질 수가 없는 것이다. 왜 잊고 있었을까

조엘이 그랬던가. 평범한 개발자를 아무리 투입해도 명작은 나오지 않는다고. 우리가 접하는 수많은 개발자들은 조엘이 말하는 그런 인재는 아니다. 그런 필요가 있는 곳에서는 그런 인재를 투입해야 하지만, 대부분의 경우 평범한 개발자들과 일하게 된다. 그들에게 바라는 것은 그런 훌륭한 코드가 아닌, 후에도 쉽게 유지보수할 수 있을 정도의 기본적인 가독성이었다. 경력 몇년에 걸맞지 않는 형편없는 코드 겉모습에 진저리가 쳐지고 그래서 가독성 가독성을 우겼었던 것 같다. 그런 와중에 알고리즘은 묵살해 왔었던 것 같다. 하지만 프로그램에는 알고리즘이 빠질 수 없다.

하지만 가독성이 그래도 중요하다는 믿음은 여전하다. 다른 품질 요소들 어느 하나 무시할 수는 없지만, 가장 중요한 것은 가독성이라 믿는다. 논란의 여지가 꽤 있겠지만.