알면서 왜 안할까? TDD라는 글을 읽었다.
나는 어떻게 해왔을까? 처음에 프로그래밍을 배우고 C아닌 다른 스크립트 언어들을 이것저것 해볼때는 문법 레퍼런스를 읽기가 귀찮아서 그저 문법확인 용도로 테스트 코드를 만들었다. 이 문법이 이렇게 동작할까? 하는 것에 대해 확신이 들면 어느정도 코딩 진행이 가능했었으니까...
Java를 처음 접했을때는 문법확인용 테스트 코드 조차도 만들기가 쉽지 않아서 잘 적응을 못하다가, JUnit 을 이용하면 편하게 그런 용도로 쓸 수 있다는 걸 알게되었고, JUnit 덕에 자바도 다른 스크립트 언어들처럼 금방 적응할 수 있게 되었다.. (물론 그렇게 작성된 테스트 코드는 지극히 일회성이기 때문에 커밋하지 않았다. 나 혼자 문법 확인하는 용도로만 사용했다.) 이게 제대로된 TDD는 아니더라도 그냥 이언어 저언어 하다보니 헷갈리는 문법 확인하는 테스트만 해도 충분하다고 생각되는 때도 많았다. 혼자할때는 TDD를 거의 개인적인 궁금증을 해결하는 용도로 테스트 코드를 만들어보고, 되네? 하고 확인하고 그치는 정도로 충분히 만족했다.
그러다가 2인이상이 협업해야하는 프로젝트를 TDD에 관심있는 분들과 하게 되면서 부터는 좀 더 TDD를 TDD스럽게 해봤던 것 같다. 단순히 문법 확인용의 테스트 코드가 아닌 내가 새로 추가한 단위 코드들은 어떤게 있고, 그것들이 어떤식으로 동작하는지 간단한 설명과 예제를 테스트 코드로 알려줄 수도 있었다. (진정한 프로그래머는 코드로 말한다고 하지 않았던가? TDD를 통해서 비슷하게 그런 행위가 가능했던 것이다!) 꾸준히 테스트 코드들을 만들면서 소스트리에 커밋했다. 게다가 테스트를 자동으로 일괄 실행하고 그 결과를 한눈에 볼 수 있으니까 왠지 모를 뿌듯함... 재미있었다.
결정적으로 테스트 케이스를 만들고 잘 되는걸 보면서 다음 코드를 확신과 용기를 가지고 자신있게 진행해 나갈 수 있으니 코딩에 속도가 붙었다. 속도가 붙고 그 과정도 가시적이다보니 절로 신이났고 퇴근을 하고 나서도 다음날 빨리 출근해서 코딩이 하고 싶었다. (꼭 TDD 때문에 재미있다기 보다는 다음 코드를 자신있게 코딩할 수 있다는 사실 자체가 즐거움을 줬던거 같다.) 그렇게 TDD를 나름 잘 쓰면서 개발했다고 생각했다.
그런데... 그 후에는 어떨까? 솔찍히 말하면 유지보수 업무가 많아지면서 TDD를 잘 안하게 된다. (시작부터 멀하고 싶은지도 모르는 기획서 가지고 개발을 시작해서 하루에 수십번씩 이건 이렇게 말고 저렇게 하는게 좋을 것 같은데요 라는 경우는 제쳐놓더라도) 초기 개발완료 이후 당연히 끊임없이 발생하는 기존 기능에 대한 크고작고 자잘하고 무수히 많은 수정요청들...
그래도 (커밋은 하지 않고 혼자 궁금해서 작성해보는) 문법 확인용 테스트 코드는 여전히 만들어보곤 있지만, 유지보수하면서 잦은 변경요청이 있을때 기존의 테스트 코드부터 수정하고 본코드를 수정하는 것이 너무나도 귀찮기도 했다.
예를들면, 이건 그냥 파라미터 한개만 추가하고 소스 약간만 수정하면 금방 적용이 되는건데, 테스트 코드까지 함께 수정할려니 그렇게 귀찮을 수가 없다. 수정이 많이 가해진 경우에는 수정할게 많아서 귀찮기도 하고... (물론 내가 좀만 더 신경써서 하면 되는데... 하고 하루에도 수십번 생각한다.)
TDD를 왜 계속 안하냐고 묻는다면 솔찍히 그렇다. 나도 힘들고 재미없다는 생각이 들면 하기 싫다. 솔찍히 이정도 수정사항은 테스트 코드 없이도 순식간에 수정할 수 있다는 생각에 테스트 코드는 그대로 두고 본 코드부터 수정해버리고 마는 경우가 자주 생기게 된다. 이미 다 처리했는데 테스트 코드 깨진것까지 신경쓸 생각조차 안하게 된다. 왠지 시간이 아깝다는 생각도 든다. (나말고 다른 사람은 테스트 코드를 신경도 안쓰는 상황이라면 그것도 크게 한몫한다.)
이상적이지만, 인터페이스를 추가하고 리펙토링을 해서 그에 맞는 테스트코드를 또 새로 추가하면, 기존 테스트코드와 실제코드를 손대지 않고 처리할 수도 있을 것 같은데... 하는 생각을 하면서도... 겨우 이거 하나 하는데 그렇게 까지 해야 되나 하는 자잘한 수정요청 사항들도 많다. (겨우 그거 하는데 그렇게 오래걸려? 하는 것 같은 느낌때문에 빨리 끝내야할 것 같은 강박관념;;;)
그렇게 한두번 그냥 넘어가게 되면 제대로 해야하는 경우가 생겨도 그냥 넘어간게 한두개가 아닌 상황에서 이제와서 무슨.. 하는 생각이 들게 되기 마련이다. 내가 다른 사람에 비해 유독 게으르고 성실하지 못해서 그런걸까... 나름 성실하고 부지런한 편이라고 생각하면서 살아온 나도 이런 생각을 하는데 다른 사람들은 더 하겠지라고 스스로 합리화를 하게 된다. 부끄럽지만 솔찍한 심정이다. 난 아닌데? 라는 사람들이 더 많을려나...;;
난 TDD를 가끔씩 하긴 한다. 근데... 갈 수록 잘 안하게 된다. 없는걸 새로 할때는 TDD로 하면 재미있다. 그런데 기존에 있는걸 수정할때는 TDD로 하면 재미가 없다. 내가 만들었던 코드가 아닌 것을 TDD 하기가 왠지 짜증도 난다. 까짓꺼 수정요청 생길때마다 조금만 시간할애하고 몇번만더 타이핑 하면 되는데... 생각도 말도 쉬운데, 언제나 그렇듯이 실천은 어렵다. 그만큼 시간과 정성을 들여야 하기 때문이다.
하지만, 여전히 궁금한걸 테스트 코드로 만들어서 실행해보고 아 이렇게 되네? 하는걸 확인하는 과정은 재미가 있다. 제대로된 자동화된 테스트코드를 계속 만들어내진 못하지만, 커밋하지 않는 문법확인용 테스트 코드는 계속 만들면서 하는건 여전히 재미는 있다.
ps.
요즘들어 왜 자바스크립트랑 CSS가 더 좋아지는 걸까... 자질구레한 서버셋팅 설정등 부가적으로 알아야하는 그 상황에 맞는 그 프로젝트에 해당하는 설정사항들을 신경써야 하는게 짜증이 나서 인지도 모르겠다. |
예전에 이어 둘다 되야 맞는것 같은데, IE에서만 되고 FireFox에서 안되는 경우가 생겼다.
obj.getElementsByTagName('TD');
위 처럼 한 건 IE, FF 둘다 잘 작동한다. (당연하지~)
그런데, nextSibling 나 previousSibling 를 이용해서 이웃 객체의 특정 태그에 해당하는 자식노드들을 얻어오려고 하면, 분명 이웃 객체가 존재하고 있는데도 FireFox 에선 getElementsByTagName is not a function 이런 에러를 뿜는다;;
ex)
obj.nextSibling.getElementsByTagName('TD'); // 이건 IE만 작동한다. 특별히 복잡한 걸 할려고 한건 아니고, 단지 자바스크립트로 UI 제어만을 위해서 특정 객체를 얻어와서 그 객체 하위의 특정 태그에 해당하는 자식 노드들만 얻어오는 연습을 해볼라고 getElementsByTagName 함수를 사용했다.
표준 문법을 어긴건가? 왜 안되는지 모르겠다. 국내 검색결과엔 해당 내용이 전무하다... 구글엔 질문은 잔뜩있는데 어떻게 해야한다는 건지 답을 못찾겠다. 그래서, 국내 검색결과 수 좀 늘려볼라고 포스팅... --; (꼬부랑 글씨는 읽으려고 하면, 어떻게 해서든 단어 하나하나 찾아가며 번역하던지 영어 잘하는 동생 시켜서 읽어볼 순 있겠지만, 그런 것 찾는 것만도 눈알이 빠질 것 같은 가독성 때문에 답답...)
ps.
가끔씩은 코딩질 하는 사람의 입장에선 IE에 점수를 더 후하게 주고 싶은 경우가 많다. 실제로 코딩질 하다보면, 요구사항을 다 들어주는 걸 만드는게 구현하는게 더 어렵고 난이도도 높으니 말이다... 개발자 입장에선 표준이 있고 표준대로만 동작하는걸 구현하기란 사실 허무할 정도로 쉬운일인 경우가 많다. 대부분 개발의 난제는 이 문제를 어떻게 해결할지 고민하는데 있는데, 그게 다 해결된 경우라면 이미 끝난거나 다름 없으니 말이다... (할 수 있거나 안되거나가 분명해서 둘중 하나를 고르면 끝이니까... 할 수는 있을 것 같은데... 이런건 정말 어려운거다...) 대부분의 경우 표준대로 만들어 달라고 하지 않고, 이렇게 될 것 같은데 이렇게 해주세요 라고 해서 이모냥 이꼴이다.....
20080716:
헉... 포스팅 한지 한시간 정도 된거 같은데... 구글에 벌써 노출된다;; |
|
|