Page history of 일기장/2007-08-12

그 동안 창업해서 일하면서 배운 것이 참 많지만 프로그래밍에 대해서도 깨달음이 좀 있었던 것 같다. 사실 내 프로그래밍 실력이 이제 거의 정점에 다다랐다고 자만했던 적도 있었다. 하지만 다시 성장은 끝이 없다는 것을 느끼게 되니까 참 기분이 좋다. 그 동안 얻은 깨달음을 정리해본다면...

1. 멍 테스트
   • 생각 없이 코드를 약간 수정하고 실행해서 목적 의식 없이 이리저리 테스트 해보는 행동. 태근이를 통해서 발견한 패턴이지만 나 스스로도 엄청 자주 빠지는 함정이다. 피로할 때 자주 나타나는 현상이다. 생각하기가 싫으니까 그냥 이리저리 단순 테스트를 하고 생각 없이 코드를 고치면서 우연히 돌아가는 코드가 나오길 비는 심리가 있는 듯하다. 당면 목표에 대한 인식이 잘 안되어 있거나 문제가 잘 안 풀릴 때, 알고리즘을 명확하게 생각하지 않고 코드부터 만들 때 흔히 나타난다. 해결책은 의외로 쉽다. 이런 현상이 자신에게 생긴다는 것을 인지하는 것만으로도 큰 변화가 있다. 나도 이 패턴을 인지하고 나서 문제 해결 능력이 엄청나게 발전한 것 같다. 멍 테스트를 하다가도 금방 깨어난다. 그리고, 몇 가지 수단들이 있다. 가장 훌륭한 도구는 물론 TDD다. 하지만 지금처럼 TDD를 못하는 상황에서도 TDD의 장점을 끌어올 수 있다. TDD에서 테스트를 작성하듯이 이 코드가 맞다면 어떻게 되어야 하는지를 명확하게 정의해두고 출발하는 것이다. 그리고 실행할 때는 그것만 검증하고 다른 버그를 찾기 위한 시도는 따로 안하는 게 좋다. 우연찮게 버그를 찾더라도 그 버그에 대한 대응을 바로 하는 것은 좋지 않다. 문제가 잘 안 풀릴 때 일단 컴퓨터 앞을 벗어나는 것도 좋은 방법이다. 컴퓨터 앞에 앉아 있으면 깊이 있는 생각 없이 기계적인 코드 변경과 테스트만 반복하게 된다.
2. Do not extract method

   • 이클립스의 자동 리팩토링 기능 중 가장 프로그래머들이 좋아하는 것이 아마 rename과 extract method일 것이다. 그리고, 가장 남발하는 리팩토링이기도 하다. 나 역시 긴 메소드를 보면 일단 extract method부터 생각한다. 하지만, 이것도 생각 없이 기계적으로 하게 되면 더 나쁜 코드를 만들게 된다. 규영이가 언젠가 말한 바 있는데 메소드는 그 자체가 GoTo의 문제점을 해결한 것이 아니다. GoTo의 문제는 코드의 순서와 실행 순서가 맞지 않아서 사람이 코드를 읽어 내려 가다가 다른 곳으로 점프해서 봐야 하기 때문에 사고의 흐름이 끊긴다는 것이다. 그런데, extract method를 기계적으로 하게 되면 똑같은 문제가 생기는 것이다.

     그럼 이 문제는 어떻게 피할 수 있을까? 사실, 이 문제도 쉬운 문제다. 리팩토링의 기본 원칙에만 충실하면 된다. 중복을 제거하고 의도를 드러내는 것이다. 이 두 가지 목적을 만족시키지 못하는 extract method는 메소드가 아무리 길어도 해선 안된다. 특히 주의해야 할 것은 의도를 드러내는 리팩토링을 해야 한다는 것이다. extract된 메소드는 가서 보지 않고도 무슨 일을 하는지 알 수 있어야 한다. 가서 봐야 하면 GoTo와 똑같은 문제가 생기는 것이다. 이 문제는 메소드 작명과도 상관이 있다. 이벤트 핸들러 이름 짓는 걸 보면 onClick 핸들러의 이름을 _onClick이나 clickHandler 등으로 짓는 경우를 많이 보게 되는데 이것 역시 GoTo의 문제점을 고스란히 안고 있다. 실제로 그 메소드가 하는 일을 메소드 이름에 담아야 한다. 클릭했을 때 다이얼로그를 띄워 준다면 onClick 핸들러의 이름을 showDialog 등으로 지어야 하는 것이다. 결국 의도를 드러낸다는 것은 더 accountable한 코드를 만든다는 것이다. http://c2.com/cgi/wiki?MethodsShouldBePublic , http://jania.pe.kr/wiki/jwiki/moin.cgi/MethodsShouldBePublic 도 도움이 될 것이다.

3. 자동화된 TDD가 정말로 불가능하거나, 비효율적인 경우도 있다. 그러나, 그런 경우에도 TDD의 장점을 활용할 수 있다.
   • 예전에는 어떤 분야든 자동화된 TDD가 가능할 꺼라고 생각했다. 하지만 이제 생각이 좀 바뀌었다. GUI 테스팅에 대해서 여러 가지 이야기가 많은데, 이번에 플래시 애플리케이션 개발을 해보면서 느낀 것은 이 분야를 자동화시키긴 아주 어렵다는 것이다. GUI 툴킷을 이용해서 GUI 애플리케이션을 만드는 거라면 꽤 높은 수준의 자동화가 가능하다. 그러나, GUI 툴킷 자체를 만들어야 한다면? 거의 불가능에 가까운 도전이 될 것이다. 이걸 제대로 해낸 사람이 있다면 가서 한 수 배우고 싶다. 하지만, 지금까지 내가 판단하기로는 이건 정말 쉽지 않다. GUI 튜닝도 마찬가지, TDD의 영역이 아니다. 하지만, 그래도 TDD의 장점은 살릴 수 있다. xUnit 없이도 TDD를 할 수 있다. TDD의 장점은 목표를 먼저 명확히 정의한다는 것(=테스트를 작성하는 것)이다. TDD에 대한 오해 중 하나가 TDD를 하면 별 달리 생각하지 않고도 반복적인 실행을 통해서 코드를 만들어갈 수 있다는 것이 있다. 하지만, 이게 가능한 이유는 테스트를 작성하기 때문이다. 테스트를 작성하려면 문제를 적절한 크기로 쪼개야 하고 또 어떻게 동작해야 하는지를 명확하게 정의해야 한다. 이 과정을 거치기 때문에 이후의 과정이 쉬운 것이다. 그래서 TDD를 할 때 제일 많이 생각하고 시간을 들여야 하는 부분은 테스트를 만드는 시간이다. 이런 면에서 BDD는 유익하다. 이 점만 잘 인지하고 있으면 테스트 자동화 없이도 얼마든지 TDD의 장점을 활용할 수 있다. 물론 자동화되어 있을 때처럼 빠르고 편하지는 않지만 안하는 것보다는 월등히 좋은 결과를 낼 수 있다.