티스토리 툴바

BLOG main image
분류 전체보기 (68)
Cocoa Touch (15)
Cocoa (6)
Objective-C (10)
Development (8)
Tools (6)
Books (6)
etc (14)
Application release (2)
Document Project (1)
드리밍 인 코드
The note of Legendre
MakeItBlue의 생각
tuna's me2DAY
위피 내년 4월부터 의무화 폐지..
맥, 기술, 영화, 도서 그리고 삶
[News] iPhone OS 2.2 출시?
maccrazy's blog
Self Encapsulate Field
maccrazy's blog
22,061 Visitors up to today!
Today 1 hit, Yesterday 9 hit
daisy rss
tistory 티스토리 가입하기!
2011/12/11 11:07

오래전에 CCV방법론(?)에 대해서 한번 이야기 한적이 있었는데 오늘 다시 그때 이야기에 이어 관련된 이야기를 하고자 한다.


최신의 개발 스타일은 이제 더 이상 단순히 에디터와 개발자의 순수한 노력에만 의지 하지 않고 있다.

개발을 조금 더 체계적으로 지원해주는 많은 툴들을 이용하는데, 특히 코드의 품질을 유지하기 위해 CI를 위한 Jenkins(Hudson)같은 툴도 많이 이용하고 있고 그에 더불어 Static Analysis, Unit Test, Coding Convention Checking, Cyclomatic Complexity 툴등 다양한 도구들을 이용하고 있다.


"CCV방법론 - 중복의 해악"이라는 글에서 이미 이야기 했듯이 코드의 중복은 수만은 문제를 일으키고 리팩토링을 통해 코드를 최상의 상태로 유지하기 위해서는 코드의 중복을 확인 하는 일은 매우 중요하다. 그래서 그런데 사용할 툴을 Code Clone Detector라는 이름으로 개발하는 사람들이 있는데 C, C++, Java같은 언어들을 지원하는 툴은 이미 많이 나와있지만(PMD http://pmd.sourceforge.net/cpd.html, 관심있는 분들은 한번 보셔도 좋을듯) Objective-C에서 사용할 수 있는 것은 찾기 쉽지 않았다.

Mac OS / iOS 개발에 있어서 다른 툴들은 다 어떻게든 구해보겠는데 Code Clone Detector는 Simian이외에는 아직 찾지 못했다. Simian은 비상용, 오픈소스 프로젝트에 사용하는 것은 무료이지만 그 외의 용도에서는 라이센스에 따라 최소 $99이상의 가격이 책정되어있다.


갑자기 duplicated code detection에 대해서 관심을 가지기 시작한 이유는 엉뚱하게도 다른 이슈 때문이었지만, 평소에도 command키와 c키, 그리고 v키를 키보드에서 뽑아버리고 싶은 충동을 느껴왔었다.

심지어는 code clone이 너무나 심각해져서 코드를 조금만 건드려도 여기저기서 문제를 일으키는 코드도 많이 봤다. 소위 전문가(?)들이 작성한 코드가 그러니 말 다했다.

결국 그런 코드를 정리하거나 컨설팅해줘야 하는 입장에서는 그런류의 일을 효율적으로 할 수 있는 도구가 필요하다. 하지만 아직 정말 이정도면 좋다라는 툴을 찾지는 못했다.


애플은 xcode에 엉뚱한 것을 자꾸 넣지말고 이런거 좀 넣어주면 안되나…

저작자 표시 비영리 변경 금지
Trackback Address :: http://maccrazy.tistory.com/trackback/84 관련글 쓰기
Name
Password
Homepage
Secret
2011/12/11 00:14
[etc]
가만히 보니 나는 1년에 블로깅을 몇번 안하는 매우 게이른 블로거인것 같다. 아니, 블로거라고 하기도 참 민망하네.
그러다보니 글들이 푹푹 삭아가는데, 오늘은 방문자 통계를 보다보니 갑자기 당황스러워 지는 것이, 아주 오래전 글, 그러니까 지금 기준에서 보면 조금은 쓸데없어지거나 내용이 바뀔 수도 있는 글들로도 계속해서 사람들이 유입되고 있는 것이다.
어이쿠. 검색엔진이 해당 글이 얼마나 낡은 글인지도 함께 알려주면 참 좋겠다만...
뭐, 그것 뿐이겠는가? 이 온라인 세상에는 엉터리 정보도 얼마나 넘쳐나지 않는가... (나도 마찬가지)
하여튼 그렇다고 해서 나의 게이른 블로깅을 어찌 할 수 없을듯 하긴 하지만 그래도 조금 쓰긴 해야 하는 것일까? 
저작자 표시 비영리 변경 금지
Trackback Address :: http://maccrazy.tistory.com/trackback/83 관련글 쓰기
박종암 | 2011/12/20 04:33 | PERMALINK | EDIT/DEL | REPLY
살아계셨군요!!!!
Name
Password
Homepage
Secret
2011/03/30 23:20
사실 이런 저런 바쁜 일들로 최근에 독서라는 걸 해본지가 까마득 해질려고 하는데, 어쩌다 보니 "생각의 탄생 (로버트 루트버너스타인, 미셀 루트번스타인)"이란 책을 읽기 시작하게 되었다. - 사실 이 책을 손에 쥔지 거의 4달만에 읽기 시작했다.
지금 다 읽은 것도 아니고 이제 겨우 1/10 정도 읽었을까? 답답한 마음에 목차 먼저 쭉 훑어보고 대충 이리 저리 뒤적 뒤적해본 결과 대략의 주제는 파악한듯 하다. 하지만 꼼꼼히 읽어봐야지, 어차피 주말엔 병원에서 보내야 하니...
여튼, 중요한 것은 그것이 아니고 이 책을 읽다보니 문득, 우리가 "관찰"이란 것에 대해서 얼마나 느슨하게 생각을 하고 있었는지 반성하게 되었다.
사실 사고의 시작을 관찰이라고 본다면 어떤 사고의 집합체인 프로그래밍 역시 관찰에서 시작되어야 할텐데 사실 그렇지 못한 경우가 너무나 많았던 것 같아 반성하게 된다.
물론 구현하고자 하는 내용에 대한 관찰도 매우 중요하지만 뭐 그런것 까지 바라지 않더라도 당장 내가 작성한 코드를 "관찰"하는데 얼마나 게을렀던가 반성하지 않을 수 없다.
버그가 발생했을 때 제대로 된 개발자는 사용할 수 있는 거의 모든 방법을 동원해서 그 현상과 결과 그리고 해당하는 코드, 디버거를 이용해서 변수와 콜스택 등등 들여다 볼 수 있는 모든 것들을 관찰해야 하고 그 내용을 기반으로 생각을 만들어 나가야 하는데... 사실 손이 먼저 나간다. (물론 관찰과 사고의 과정들이 너무나 빨리 순식간에 이뤄져서 금방 버그를 고치는 경우도 있지만...)
나도 그렇지만 많은 사람들이 버그의 원인에 대한 관찰과 분석 없이 현상을 틀어막는데 급급하지 않나 싶을 때가 있다. 물론,  시간에 쫒기거나 내용을 이해하기 힘들어서 그렇게 얼렁뚱땅 버그를 묻어버리는 경우가 많다는 것은 알고 있다. (그래, 분명히 나도 그런 적 있다.) 하지만, 이제서야 (뭐 사실 조금 더 오래되긴 했지만) 그런 만행에 대해서 통렬히 반성하고 있다.
역시 사람은 독서를 해야 하나보다. 책을 읽다보니 내가 예전에 무슨 짓을 저질러놨는지 보이니 말이다.
저작자 표시 비영리 변경 금지
Trackback Address :: http://maccrazy.tistory.com/trackback/82 관련글 쓰기
Name
Password
Homepage
Secret
prev"" #1 #2 #3 #4 #5 ... #23 next