월간 마이크로소프트웨어 3월호를 보시면 리펑토링에 대한 기사가 나와있다. 리팩토링에 대해서는 관심도 많고 많이 들어보기도 했지만, Paromix군은 리펑토링에 대해서는 처음 들어봤다. 영어 사전을 찾아도 안나오는 것을 보니 리팩토링과 반대되는 개념으로 새로 만든 단어인듯 싶다.
리펑토링(Refuctoring) : 잘 설계된 코드에 작고 가역적인 변화를 도입해서 자기 자신을 제외한 어느 누구도 그것을 관리 할 수 없도록 만드는 과정.
자기 자신만 관리 할 수 있는 코드를 작성하는 것이 참 피곤한 일인데, (경험상 내가 짠 코드를 남들이 이해하기 어려우면 휴가때 전화가 빗발친다.-_-) 피하고 싶을수록 어떤 방법으로 이루어지는지 알아두어야 할 것 같다.
기사를 보면 여섯 가지 리펑토링의 사례를 예제코드와 함께 설명하고 있다.
1. 피그 라틴(Pig Latin) : 제멋대로 이름 붙이기.
-> 누군가 그랬다. 다른 회사에 코드를 보낼 일이 있는데, 뭔가 장난을 치고 싶다면 변수 및 함수의 이름을 제멋대로 바꾸어 보내라고.:D (농담반 진담반이다.)
2. 보물 찾기(Treasure Hunt) : 다른 코드에 대한 참조를 위주로 코드 구현.
-> 제임스님이 말씀하신 한쪽 코드를 들어올리면 다른 코드들이 딸려 올라오는 구조라는 것이 이런것이 아닐까 싶다. 보물 찾기라는 이름은 정말 잘 지었다. 참조로 꼬여있는 코드들을 디버깅해보면 진짜 보물 찾는 기분이니 말이다.^^ 그런데 이런 코드는 작성한 사람도 관리하기 힘들지 않을까.?
3. 자기만의 모델링 언어(Unique Modeling Language) : 보편적이지 않은 모델링 도구로 설계하기.
-> 개인적으로는 자신이 능숙하게 다룰 수 있는 툴을 사용하는 것도 나쁜 것만은 아닌 것 같은데, 설계도면이나 문서를 보고 다른 사람이 이해하기 쉽게 만든다면 금상첨화라는 소리가 아닐까 싶다.
4. 명백한 사실을 상세히 설명하기
-> return문에 대한 주석으로 "// 리턴한다" 이런 식이 되면 좀 곤란하긴 하겠지?
5. 비오는 날을 위한 시나리오 : 일어나지 않을 상황에 대한 코드 짜기.
-> 명백히(100%) 일어나지 않을 상황이라면 모르겠지만, 사실 코드가 수행되는데 일어나지 않을 상황을 정확히 알 수는 없다. -_-
6. 모듈의 중력장 : 모든 일을 하는 객체 만들기.
-> 모든 일을 하는 객체라는 건 이미 객체로서의 의미가 없지 아마.^^
Paromix군은 기사를 읽으면서 네번째 사항 때문에 약간 뜨끔했다. 주석을 많이 다는 편인 Paromix군은(주석이 없으면 코드 내용을 까먹는다. 하하) 명백한 사실을 주석으로 달아놓는 경우도 많았기 때문이다. 주석에 대한 효율을 높일 방법에 대해 좀 생각을 해봐야 할 것 같다.
기초적인 사실이면서도 자주 까먹는 내용들이기 때문에 모니터 옆에 포스트잇이라도 붙여두고 리펑토링을 하는 일이 없도록 주의하면서 즐거운 프로그래밍을 해봐야겠다.:D
관련글
1. 코드의 웃음을 빼앗아가는 리펑토링(Refuctoring) by 임백준
2. Refuctoring by Jason Gorman
출처 : Last Paromix