그런데 별로 도구에 대한 이야기가 나오지 않는 것 같아서, 사내 게시판에 Crucible을 언급하고 javawork 님 포스팅
(http://javawork.egloos.com/2858102) 을 링크했습니다.
그랬더니 '저걸 도입하려고 검토 중인데 사용기가 절실하다.' 라는 메일을 받았네요;
혹시 Crucible 써 보신 분들 계실까 하여 메일을 띄웁니다.
Crucible 한 번이라도 써 보신 분들, 소중한 경험을 나눠주세요~
회사에 Cruicible이 도입되어서 좀 편하게 코드리뷰 해보고 싶다고 몸부림치는 사원 1인..사용기를 간곡히 기다립니다.
(도구 없이 맨땅에 코드리뷰 시~작! 할까봐 겁먹고 있습니다ㅠㅠ)
Jira, Confluence 를 만든 Atlassian 의 코드리뷰로 부터 lessons learned 입니다. 도구를 도입하는데 이정표가 되지 않을까도 싶네요.
http://blogs.atlassian.com/developer/2010/03/code_review_in_agile_teams_part_ii.html
요약하면
* 코드리뷰에 대한 오해
- 버그를 발견하는 것을 보장하진 않는다
- 코드의 결함을 찾는 것이 목적이 아니라, 서로 배우고 가르쳐 주고, 팀의 협업능력을 높여주는 것이어야 한다. (그렇지 않으면 팀이 깨어진다)
* 코드리뷰가 잘 되려면
- 너무 많은 절차와 규칙을 만들지 마라. 절차를 아주아주아주 간단하게 하라
- 강요하지 마라. 대신 Encourage 하라
- 모든 코드 commit 을 리뷰하도록 한다거나 하는 형태로 Micro - Manage 를 하지마라
- 개개인의 작업 흐름을 끊지마라
- 코드리뷰를 통해 발견한 것들을 널리 공유하라
- 코드리뷰를 늦게 하는것은 안하는 것보다 나쁠수 있다. Iteration 에 포함시켜라
- 한꺼번에 덜하기보다는 조금씩 자주하라
- 툴에 얽메이지 마라, 중요한것은 개발자들이 서로 대화를 하고 코드를 공유하는 것이다
- 너무 많은 리뷰어를 참여시키지 마라. 2-4 명이 적당하다
* 어떻게 잘 되고 있는지 알수 있는가
- 쉽진 않다, 사실 필요없을 수도/불가능 할수도 있다, metric 에 집착할 필요는 없다.
- 장기간의 이득은 측정할 수 없지만 많다
- Simple Metric 들이면 충분할 수 있다. (리뷰에 사용된 시간, 리뷰 comment 등).
On 11월3일, 오후5시19분, Min <mini...@gmail.com> wrote:
> 안녕하세요
>
> 저는 code collaborator (http://smartbear.com/products/development-tools/code-review/features/) 밖에
> 사용해보질 않아서
> 직접적인 도움을 드리지는 못하겠습니다만..
>
> 스크린 캡쳐만 보았을때 기능상 크게 다른 것 같지는 않은 것 같습니다.
> 개인적으로 도구를 사용을 한다면, 기능이 많은 것 보다는 사용하기 쉬운것 위주로 선택하지 않을까 생각합니다만.. 이도 주관적인 것이라..
>
> 추가적으로
>
> Jira, Confluence 를 만든 Atlassian 의 코드리뷰로 부터 lessons learned 입니다. 도구를 도입하는데
> 이정표가 되지 않을까도 싶네요.
>
> http://blogs.atlassian.com/developer/2010/03/code_review_in_agile_tea...
>
> 요약하면
>
> * 코드리뷰에 대한 오해
>
> - 버그를 발견하는 것을 보장하진 않는다
>
> - 코드의 결함을 찾는 것이 목적이 아니라, 서로 배우고 가르쳐 주고, 팀의 협업능력을 높여주는 것이어야 한다. (그렇지 않으면 팀이
> 깨어진다)
>
> * 코드리뷰가 잘 되려면
>
> - 너무 많은 절차와 규칙을 만들지 마라. 절차를 아주아주아주 간단하게 하라
>
> - 강요하지 마라. 대신 Encourage 하라
>
> - 모든 코드 commit 을 리뷰하도록 한다거나 하는 형태로 Micro - Manage 를 하지마라
>
> - 개개인의 작업 흐름을 끊지마라
>
> - 코드리뷰를 통해 발견한 것들을 널리 공유하라
>
> - 코드리뷰를 늦게 하는것은 안하는 것보다 나쁠수 있다. Iteration 에 포함시켜라
>
> - 한꺼번에 덜하기보다는 조금씩 자주하라
>
> - 툴에 얽메이지 마라, 중요한것은 개발자들이 서로 대화를 하고 코드를 공유하는 것이다
>
> - 너무 많은 리뷰어를 참여시키지 마라. 2-4 명이 적당하다
>
> * 어떻게 잘 되고 있는지 알수 있는가
>
> - 쉽진 않다, 사실 필요없을 수도/불가능 할수도 있다, metric 에 집착할 필요는 없다.
>
> - 장기간의 이득은 측정할 수 없지만 많다
>
> - Simple Metric 들이면 충분할 수 있다. (리뷰에 사용된 시간, 리뷰 comment 등).
>
> 2011년 11월 3일 오후 2:20, 파란바람 <paranba...@gmail.com>님의 말:
구매가 진행중이라 사용기는 나중에 올려드릴수 있을것 같네요.
평가판만 사용해본 바로는
Code Collaborator
- 다양한 기능을 지원(VS addin 등)
- Pre-Review(저장소에 commit 없이 리뷰)에 강점
- 상대적으로 고가
- 고객지원이 미흡(이메일 답변이 없다거나..)
Crucible
- 최소한의 기능만 지원
- Pre-Review 불편(소스 저장소에서 patch파일을 만들어서 올려야 함)
- 상대적으로 저가
- 설치가 간단하고 쉬운 인터페이스(기능이 적어서 그런지..)
Code Collaborator와 경쟁사 제품 기능 비교
http://smartbear.com/products/development-tools/code-review/compare/codecollaborator-vs-crucible/?compare2=rvboard
리뷰가 많아지면 성능저하가 있군요.
혹시 Crucible에 어떤 DB를 물려서 사용하고 계시는지 여쭤봐도 될까요 ?
On Nov 4, 9:12 am, "Alica N. Park" <name.p...@gmail.com> wrote:
> 지금 회사에서 Crucible 사용하고 있습니다..
>
> 저희는 Jira, Confluence, Crucible 이렇게 아틀라시안의 3제품을 사용하고 있는데
> 개발자들이 처음에 되게 어려워합니다.
>
> 일단 직접 설치해보시고 사용해보시는게.. 사용기 듣는 것보다 나을 것 같은데요.
> evaluation 버전 받으신 후에 라이센스 만료되면 다시 evaluation 버전 받아서 업데이트 하셔서 쓰실 수있습니다.
>
> 설치해서 사용해보시는게 좋을 것 같아요. =)
>
> 2011/11/4 Sangcheol Hwang <k16w...@gmail.com>
>
>
>
>
>
>
>
>
>
> > 어디라고 말할수 없습니다만 국내 포탈기업중 N사에서 Crucible를 사용하고 있습니다.
>
> > 기능은 나쁘지 않은데
>
> > 사용자가 많아지고 리뷰한 내용이 많아지면 성능저하가 심각하다는 단점이...긁적긁적
> > 이클립스 플러그인도 있는데 몇번 업그레이드가 됐음에도 불구하고 느리다는 단점이...긁적긁적
> > 그럼에도 Jira와 잘 연동되는 장점이..
>
> > 도구가 중요한건 아니지만 도구도 편해야 사람들이 코드리뷰를 더 적극적이 되지 않을까 생각합니다.
>
> > 2011/11/3 CHAE.SW <door...@gmail.com>
>
> > 오! 코드리뷰의 바람이 맹렬히 불다니
> >> 참 좋은 것 같습니다...만...
>
> >> 윗분의 의지! 라는 부분에서 잠시 복잡한 심경에 빠집니다..
>
> >> 잘 되셨으면 좋겠습니다!
>
> >> 2011/11/3 파란바람 <paranba...@gmail.com>