BLOG main image
분류 전체보기 (92)
Cocoa Touch (11)
Cocoa (10)
Objective-C (13)
Swift (6)
Development (11)
Tools (11)
Books (7)
etc (21)
Application release (1)
Document Project (1)
106,090 Visitors up to today!
Today 0 hit, Yesterday 7 hit
daisy rss
tistory 티스토리 가입하기!
'리팩토링'에 해당되는 글 2건
2008. 9. 6. 17:18
많은 개발자들에게 가장 유용한 방법론이 뭐였냐고 물어보면 "CCV방법론"이라고 우스개 소리로 대답한다. 이것은 Ctrl-C, Ctrl-V를 지칭하는 것으로 맥에서 같으면 Command-C, Command-V라고 보면 될것 같다. 즉, 소스의 다른 부분을 "베껴다" "붙이는" 방법론(?)인 것이다.
소스의 재사용성을 높이고 귀찮은 타이핑 작업을 줄여준다는 점에서 찬양(?)되는 방법론(?) 중 하나이다.

하지만, 절대로 사용하지 말기를 바란다.

첫번째 이유는 CCV는 중복된 코드를 생성 시킨다. 마틴 파울러의 "Refactoring"을 봐도 소스코드에서 나는 나쁜 냄새의 No 1으로 duplicated code를 꼽고 있고 앤드류 헌트와 데이비드 토머스의 "The Pragmatic Programmer"에서도 많은 분량의 내용이 중복의 해악에 대해서 다루고 있다. 두 책을 보신 분이라면 부연 설명이 없어도 공감하실거라 생각한다.

"The Pragmatic Programmer"에 나오는 중복이 생기는 이유에 대해서 한번 들여다 보자.
  • 강요된 중복 - 개발자들은 다른 선택이 없다고 느낀다. 환경이 중복을 요구하는 것처럼 보인다.
  • 부주의한 중복 - 개발자들은 자신들이 정보를 중복하고 있다는 것을 깨닫지 못한다.
  • 참을성 없는 중복 - 중복이 쉬워 보이기 때문에 개발자들이 게을러져서 중복을 하게 된다.
  • 개발자간의 중복 - 한 팀에 있(혹은 다른 팀에 있는)는 여러 사람들이 동일한 정보를 중복한다.
여기서 말하는 "참을성 없는 중복", 이것이 CCV방법론과 완전히 일치하지 않는가? 중복된 코드는 프로그램을 수정하기 힘들게하고 버그를 키운다. 나는 조금이라도 중복된다 싶은 코드의 경우 일단 다른 중복 되는 부분과 함께 comment로 남겨놓는다. comment 역시 코드에서 나는 "나쁜 냄새"라는 말을 신뢰하는 나로서는 이렇게 해둔 부분은 확실하게 나쁜 냄새를 풍기는 위치가 되고 우선적으로 리팩토링 대상이 된다. 중복이 되는 경우가 생겨도 인지하고 리팩토링 대상으로 올려놓는 과정인 샘이다.

두번째 이유, 만일 내 자신의 코드가 아닌 다른 부분 또는 샘플에서 CCV를 하는 것은 어떤가? 이것 역시 권하고 싶지 않은 방법이다. 보통 이런 코드들은 직접 제작한게 아니다보니 꼼꼼하게 들여다 보지 않게 되고 잘못 사용되는 경우도 종종 발생하며, 버그를 안고 있을 수 있다. 다른 곳에서 잘 돌던 코드가 내 코드와 함께해도 잘 돌 것이라고 단정해서는 안된다. 그래서 나는 CCV로 작업하는 것 보다 조금 불편하더라고 일일이 코드 한줄 한줄을 보고 이해한 후 제대로 쓸려고 노력한다. 스스로 소화시켜내지 못하는 긁어온 소스코드는 나중에 암과 같은 존재가 될 수 있다.

예제코드 없이 한 줄도 코딩 할 수 없는 개발자는 더 이상 개발자가 아니다. 코더일 뿐이다.
박종암 | 2008.09.14 06:42 | PERMALINK | EDIT/DEL | REPLY
Trackback이 안걸리는 거 같네요.
http://jongampark.wordpress.com/2008/09/13/coding-convention-which-is-more-important-than-design-patterns/
littlehj | 2008.09.14 20:47 신고 | PERMALINK | EDIT/DEL | REPLY
허걱....난 Copy & Paste만 하는데.....흑흑흑
maccrazy | 2008.09.15 19:43 신고 | PERMALINK | EDIT/DEL
이건 팀장님 같은 고수한테는 해당되지 않는 내용이지 않나요? :) CCV하셔도 중복된 코드는 안 만드시잖아요. 게다가 다 이해하고 사용하시는 거니까...
littlehj | 2008.09.16 04:58 신고 | PERMALINK | EDIT/DEL | REPLY
아직 똥오줌을 구분못하는 내가 우연찮게 계속 그런 경우에 해당하고 있는건지도....흑흑흑...
근데...티스토리를 통한 이야기를 진행하는 게 재밌네....슬슬 재미가 붙고 있으~ 아이웹을 버려야징....ㅎㅎ
브람스토커 | 2008.09.17 22:55 신고 | PERMALINK | EDIT/DEL | REPLY
예제코드 없이 한 줄도 코딩 할 수 없는 개발자는 더 이상 개발자가 아니다. 코더일 뿐이다... 에궁.. ㅠㅠ
littlehj | 2008.09.18 00:00 신고 | PERMALINK | EDIT/DEL
여기서는 너하고 나를 지칭하는 말이야...흑흑흑....
반성하며 살자.....엉엉
Name
Password
Homepage
Secret
2008. 8. 29. 23:33
리팩토링은 개발의 전 과정에 있어서 끊임없이 지속되어야 하는 작업이라는 것이 필자의 생각이다. 그 만큼 개발자들은 리팩토링에 많은 시간을 사용하고 있다고 봐야 할텐데 사실 이 작업을 함에 있어서 도구를 사용하는데 인색한 것도 사실이다.
어쩌면, 도구를 사용하기 싫어서라기 보다 마땅한 도구가 없기 때문일 수도 있다. 우리가 주로 사용하는 리팩토링 도구들은 어떤게 있을까? find/replace, copy&paste 그리고 수많은 단순 작업들이 아닌가? 심지어 유닛테스트 마저 제대로 갖춰놓지 않아서 매번 리팩토링 후에 일일이 손으로 테스트하고 있지는 않는가?

Xcode에는 오래 전 부터 리팩토링을 도와주는 툴이 존재했다. Edit 메뉴의 Refactor... 메뉴가 그것인데 사실 나도 잘 사용해본 적이 없었다. 이상하리만치 그런 작업은 일일이 눈과 손에 의존 해서 처리해야 실수가 적다는 근거없는 맹신 때문이었을 수도 있다. 요즘 시간에 좀 여유가 생긴 덕분에 그 툴에 대해서 조금이나마 들여다볼 기회가 생겼다.

먼저 Refactoring 툴의 기능을 확인 해보면 아래와 같은 것들이 지원됨을 알 수 있다.
  • Rename
  • Extract
  • Create Superclass of
  • Move Up
  • Move Down
  • Encapsulate
  • Modernize Loop
위의 모든 내용을 다 테스트 해보지는 못했다. 뭐, 특별한 것은 없을 듯 하다.

먼저 rename의 경우 기존의 작업 방식대로 할라치면 find - review - replace의 연속 작업이 될 것이다. 물론 Xcode가 지원하는 Find in project... 기능을 사용핱텐데 필자는 가끔 귀찮으면 선언부만 rename하고 바로 빌드 해버리는 무식한 짓도 서슴치 않는다. 다행이 요즘 컴퓨터들은 속도가 무척 빨라서 어떤 툴 보다 빨리 문제가 있는 부분들의 목록을 뽑아준다. :(
(결코 권하고 싶은 방법은 아니다...) 하여튼, 이 대책없는 작업을 refactor툴은 어느 정도 품위있게 할 수 있게 도와준다.
변경할 새 이름을 넣고 review를 누르면 각 파일별로 어느 위치에서 뭐가 수정되었는지 보여주는데 File Merge툴과 유사한 방법으로 사용 할 수 있다.
좋다. 참 마음에 들었다. 한가지 버그를 발견 하기 전 까지는... 문제는 클래스 이름을 수정하고 연관된 파일명까지 수정하라고 옵션을 줬을때 다른 파일에서 import문 안에 있는 파일 명을 찾아서 고쳐주지 못하는 문제가 발생했다. 당연히 컴파일 할때 에러 대량 발생... 그래, 뭐, 컴파일 할 때라도 알 수 있으니 다행이라 생각하자.

다음 테스트 해본 기능은 Create Superclass of이다. 현재 내가 선택한 클래스의 슈퍼클래스를 만드는 기능인데 사실 별로 힘든 작업이 아닌데 굳이 툴의 도움을 받아야 할지 의문이다. 차라리 흩어진 여러 클래스들의 공통 슈퍼클래스를 만들고 공통적인 변수들이나 메소드들을 끌어 올릴 수 있는 기능이라면 모를까... 하여간 이 기능은 별것 아닌데서 또 문제를 일으켰다. 작업 중 크래쉬... 결국 다시 Xcode를 띄운 후 Xcode가 생성해놓은 마무리 못지은 파일을 삭제하고 다시 시도 후 성공... 그러나 또 문제가 생겼다. 슈퍼클래스의 부모가 NSObject가 되는 상황인데 위에 딸랑 #import "NSObject.h" 이렇게 해놓은게 아닌가? 당연히 컴파일 에러 발생. 결국 손으로 #import <Cocoa/Cocoa.h>로 고친 후에 빌드에 성공 할 수 있었다.

사용자 삽입 이미지
Create Superclass of 실행 화면

이쯤 되니 슬슬 내가 이 툴을 왜 테스트 하고 있는지 의심이 들기 시작했다. 이거 쓸만한거 맞긴 한건가... 하지만 몇개만 더 해보기로 했다 이번 테스트 항목은 Move Up. 특정 변수를 선택해서 그 변수와 연관된 함수를 슈퍼클래스로 옮길 수 있게 해준다. 뭐, 얼마나 유용한지는 여전히 의문이지만 한번 해보기로 했다. 변수와 관련된 억세스 메소드(accessor)가 슈퍼클래스로 잘 옮겨 갔다. 뭐.. 그냥 그냥 되는구나. Move Down은 역시 비슷할듯 해서 생략했다.

자 하나만 더 해보자. Encapsulate. Modernize Loop의 경우 fast enumeration으로 바꿔주는 기능인데 필자가 아직은 잘 사용하지 않는 기능이니 생략하기로 했다. 특정 변수를 선택해서 encapsulate를 선택하니 먼저 그 변수의 억세스 메소드(accessor)를 만들어 주고 그 변수를 사용하는 모든 곳에서 억세스 메소드만 사용하게 코드를 수정해 줬다. 다 좋다. 그런데 그 변수를 가지는 객체 자체에서 사용하는 것 마저 억세스 메소드 호출로 바꿔버렸다. 뭐, 자주 그렇게 쓰기도 한다. 하지만 init, dealloc에 있는 변수마저 그렇게 해버리면... 코드 읽기가 대략 난감 해지는 상황이다. :(
사용자 삽입 이미지
Encapsulate 실행 화면

Refactor 툴이 소개된게 2006년 WWDC에서이다. 뭐, 그때에 비해서 많이 향상 된것 같으나 아직 신뢰하면서 쓰기엔 2% 부족한 툴이 아닌가 싶다. 물론 빠르게 리팩토링을 진행함에 있어서 도움이 될 부분이 분명히 있을 것이다. 하지만, 프로그래밍이란 매우 신중한 작업이라는 점을 고려한다면 여전히 메이저 툴로서 자리 잡기에는 불안한 요소가 많이 있지 않나 싶다. 유닛 테스트 툴의 발전 속도에 비해서 리팩토링 툴의 발전 속도가 더딘 것이 당연한 것인지도 모르겠지만 말이다.
박종암 | 2008.09.03 04:41 | PERMALINK | EDIT/DEL | REPLY
저는 이 refactoring 기능을 사람들이 많이 쓰면 좋겠다싶은 면이 있어요. 그건 자동화를 해주기 때문이 아니고, 다른 사람이 쓴 코드를 척 보고 알 수있는, 정형화된 코드를 만들어주기 때문에 그렇습니다. 저희 회사 코드를 보다보면.. 아무래도 기술적 백그라운드가 다 다르다보니..
전자과 출신들은 "돌아가서 문제가 해결되면 되는 코드"에 치중을 하다보니, 코드의 관리성, 유연성은 무시하는 코드를 만든다는 것을 알게 되더군요. 그 사람들에게 이런 코드는 이래서 잘못이다라고 설명하면 이해를 못합니다. 제대로 돌아가고 제대로 된 값이 나오면 "맞는 코드"죠. 즉 그들이 잘못되었다는게 아니라, 생각하는 범주가 틀리다는거죠.

아직 Xcode 3.1이 문제가 자잘하게 많이 있는거 같습니다.
빨리 좀 좋아지길 바래요.
Name
Password
Homepage
Secret
prev"" #1 next