코딩의 즐거움

나는 코딩이 즐겁습니다. 우아하게 작성된 코드가 결함 없이 견고하게 돌아가는 모습을 보면 기분이 좋습니다. 집중해서 짧은 시간 안에 작성한 경우에는 성취감이 두 배가 되고, 기존 코드에 뭔가를 수정할 일이 있을 때 금방 해결되면 시간을 버는 기분입니다. 코딩은 지저분하고 귀찮은 일이 아닙니다. 바닷가에서 모래성을 쌓거나, 레고 블럭을 갖고 노는 재미를 느껴본 사람이라면 그것보다 더 깊은 재미를 느낄 수 있는 것이 코딩이라고 생각합니다.

그러나 코딩하는 즐거움을 느끼기 위해서는 몇 가지 전제가 필요합니다. 먼저, 코드를 작성하고 있는 자신을 객관적인 위치에서 관찰할 수 있는 시각이 필요합니다. 어떤 문제 상황에서 어떤 방식으로 해결책을 찾고 있는지, 그 해결책들 중에서 어떤 것이 가장 적절한지 관찰하고, 기억하고, 다음번에 적용하는 연습을 해야 합니다. 연습이란 문제해결이 목적이 아니라 문제해결 능력을 키우는 것이 목적입니다. 목전에 당장 해결해야 할 문제가 있으면 연습이 잘 되지 않습니다. 적당한 시간 내에 충분히 해결할 수 있는 문제를 반복해서 풀어보면서 코딩 능력의 향상을 체크해야 합니다.

무작정 연습을 시작하려고 하면 지루하고 잘 되지 않을 것입니다. 그렇다면 좋은 코드를 작성하기 위해서 여러 사람들이 오랫동안 연구해서 만든 도구들을 배우고 적용하면 됩니다. 주변에 무료로 사용할 수 있는 스포츠카가 많이 있는데도 사람들은 사용할 줄을 몰라서 그냥 걸어 다닙니다. 심지어 어디에 쓰는 물건인지조차 모르는 경우도 많습니다.

"Code Complete"는 고전적인 소프트웨어 개발 방법론을 다룬 유명한 책입니다. goto는 정말로 유해한지, 들여쓰기와 줄바꾸기를 어떻게 해야 읽기 좋은지, 네이밍 관례는 어떤 것들이 있는지 하는 사소해 보이는 사항들부터 소프트웨어 개발 프로세스의 거시적인 차원까지 중요한 내용들을 잘 다루고 있습니다. "프로그래밍 완전 정복"이라는 좀 희한한 제목으로 번역되었는데, 절판과 재간을 반복하고 있습니다.

"Code Complete"는 구조적 프로그래밍에서의 고려사항까지만 다루고 있습니다. 객체 지향 프로그래밍을 공부하려면 개념과 문법을 다루는 다른 입문서가 필요합니다. 좋은 입문서들이 많은 것 같은데, 나는 "C++ Primer Plus 1st ed." 로 공부했습니다. C언어와 중복되는 사항까지 일일이 다룬다는 점이 C를 공부한 사람에게는 단점일 수도 있지만, 객체 지향 개념을 설명하는 부분은 잘 돼 있습니다. 최근 판은 개정된 C++문법을 반영하면서 꽤 두꺼워졌습니다.

객체 지향 설계를 연습하다 보면 이것의 유용성에 대해서 의문이 들 지도 모릅니다. 뭔가 그럴듯해 보이는데 손이 너무 많이 가고, 원칙을 곧이곧대로 지키기 보다는 편리한 대로 원칙을 깨는 코드를 작성하고 싶어집니다. 그러면 The gang of four의 "Design Patterns"를 공부하세요. 객체 지향 설계를 할 때 자주 나오는 패턴들을 수록한 카탈로그 북입니다. 이 책의 내용이 피상적이라고 생각된다면 Java의 collections framework이나 swing 라이브러리를 공부하세요. "Design Patterns"에 소개된 패턴들의 모범 적용 사례를 몸으로 익힐 수 있습니다.

Design Patterns를 공부하다 보면 패턴들을 명확하게 표현하는 방법이 필요할 것입니다. 그럴 때에는 UML을 공부하면 해답을 얻을 수 있습니다. 실제로 "Design Patterns"에는 UML의 할아버지뻘 정도 되는 다이어그램들이 객체들의 관계를 표현하는 데에 사용되어 있습니다. UML로 모델링이 잘 되지 않는 설계는 객체지향적이지 않은 설계입니다. 해결하려는 문제 자체가 객체지향과 거리가 먼 경우에는 어쩔 수 없지만, 대부분의 경우엔 설계를 잘못 했기 때문입니다. 이 경우 디자인 패턴을 적용하면 상당 부분 해결됩니다.

가벼운 설계는 작은 프로그램에 적합하지만 기능이 추가될수록 설계에 예외상황이 등장하면서 유지보수의 발목을 잡습니다. 반대로 정교한 설계는 많은 기능을 가진 프로그램에 적합하지만 여러 사항을 고려하고 작성해야 하므로 초기 개발 시간이 더딥니다. 초기에 가벼운 설계로 시작해서 기능이 추가됨에 따라 설계를 변경하는 작업은 유연한 프로그램을 작성하는 데에 필수적입니다. 프로그램의 기능은 유지하면서 코드 수준의 설계만을 변경하는 작업이 refactoring입니다. 리팩토링을 가장 직접적으로 익힐 수 있는 방법은 실시간 문법 검사와 리팩토링을 지원하는 IDE를 사용하는 것입니다. 유명한 Java IDE들은 대부분 이 기능들을 지원하고 있습니다. 리팩토링을 지원하지 않는 환경에서 리팩토링을 연습하는 것은 효율 저하가 상당합니다. 귀찮아서 안 하게 되지요. 아직 읽어보지 않은 책이라 언급하지 않으려고 했는데, "Refactoring"은 이 분야의 권위적인 저술입니다. 나도 곧 읽어볼 생각입니다.

코드를 고치다 보면 나도 모르게 전에 되었던 기능까지 잘못 작동하게 만들어버리는 경우가 있습니다. 그런 결함이 대번에 나타나는 경우에는 금방 고칠 수 있지만, 잘 드러나지 않는 곳에 있다면 원인불명의 버그가 되어서 개발자를 괴롭히거나, 최종 릴리즈까지 숨어들어가서 사용자를 괴롭힐 것입니다. 그렇다고 이미 잘 작동되는 것을 확인한 기능까지 사소한 것을 수정할 때마다 재삼재사 테스트하는 것도 귀찮은 일입니다. 이런 경우에는 테스트 프로그램을 작성해서 구현한 로직이 기대한 대로 작동하는지를 자동으로 검사해 주면 됩니다. 이런 작업을 위해서 JUnit이나 CppUnit같은 유닛 테스팅 프레임웍들이 개발되어 있습니다. 테스트 케이스는 리팩토링에 필수적인데, 설계를 변경하는 도중에 실수로 기능을 망가뜨리지 않았다는 보장을 해 주기 때문입니다. 테스트 케이스 작성은 프로그래밍을 근본적으로 다른 시각에서 접근하도록 해 줍니다. 기능을 구현한 다음 그것을 테스트하는 코드를 작성하는 것이 아니라, 테스트 케이스를 먼저 작성하고 그것을 만족시키는 코드를 구현하는 것입니다. "Test Driven Development"에는 테스트 주도 개발 방법론에 대한 충실한 소개가 되어 있습니다.

여러 사람이 협업하는 환경에서는 효과적인 문서 관리가 필요합니다. cvs를 사용하면 언제 누가 무슨 이유로 어떤 코드를 고쳤는지 추적할 수 있습니다. 잘못된 변경은 되돌릴 수도 있고, 예전 코드와의 차이점을 비교할 수 있는 도구들도 마련되어 있습니다. 변경 로그는 각 개발자의 프로젝트 기여도를 적절하게 측정할 수 있는 근거자료로도 활용할 수 있습니다. 최근에는 cvs의 결함을 보완한 svn이 점차 비중을 넓혀가고 있습니다.

API문서의 유용성은 익히 알고 있을 것이지만, 자신이 작성한 라이브러리의 API문서를 충실히 작성하는 사람은 많지 않습니다. 세련된 라이브러리를 작성할 만한 능력을 지닌 사람이 드문 탓이기도 하지만, 문서 작성은 근본적으로 귀찮은 일이기 때문입니다. 자바로 작성한 코드의 경우에는 JavaDoc을 이용해서 API문서를 자동으로 생성할 수 있고, 다른 언어로 된 코드는 doxygen(http://doxygen.org/)을 이용해서 API문서를 생성할 수 있습니다.

지금까지 언급한 개발 방법론들과 개발 도구들은 어떤 개발 프로젝트를 수행하더라도 적용할 수 있는 기법들입니다. 이것은 새로운 기술이거나 소수만 알고 있는 비법이 아닙니다. 저명한 오픈소스 프로젝트들에서는 이 기술들을 사용하는 것이 당연한 것으로 간주되고 있으니까요. 그런데도 국내 개발자들은 개발 방법론에 어둡습니다. 자기가 잘못해서 엉망인 코드를 짜 놓고 밤을 지새우면서 개발자가 된 것을 후회합니다. 공부할 시간이 없다는 변명은 제대로 생각해보지 않고 하는 이야기입니다. 개발 방법론을 공부하면 잘못 작성한 코드 때문에 스스로를 고생시키는 일이 줄어들 것입니다. 그렇게 번 시간으로 자기 계발에 투자하거나 여가를 즐긴다는 생각을 하면 어느 모로 따져도 이만큼 남는 장사가 없지요.