FishEye, Crucible 4.4 버전이 릴리스 되었습니다. 자세한 사항은 FishEye 4.4 릴리스노트 를 참조하십시요..
블로그

블로그

Crucible 4.4 버전이 릴리스 되었습니다


Crucible 4.4 버전이 릴리스 되었습니다.


Crucible 4.4.0 다운로드 페이지에서 다운로드 하실 수 있으며 자세한 릴리스 노트는 Crucible 4.4 릴리스노트 문서를 참조하십시요.

 

거의 모든 조직에서 팀원들은 협업을 통해 업무를 완료합니다.

소프트웨어 팀에서는 일반적으로 코드 개발, 코드 검토, 테스트 같이 업무가 서로 다른 직원 간에 작업(문제)을 이전합니다 (모두 같은 팀 소속이어도 마찬가지).

 

팀원 간 문제를 이전할 때는 이전받는 사람이 문제에 대해 완벽히 이해하는 데 필요한 램프업(ramp-up) 양을 최소화하는 것이 중요합니다. 작업(문제) 이전은 팀원 한 명이 아닌 두 명의 시간이 필요하므로 많은 비용이 들 수 있습니다.

 


하지만 코드 검토는 소프트웨어 팀 사이에서 모범 사례에 해당합니다. 

 

코드 검토는 코드베이스의 정보를 배포하여 팀이 더욱 유연해지고, 기민해지며, 결함 포용력이 강화되는 데 도움이 됩니다. 코드베이스 지식이 팀 전체에 배포되기 때문에 팀이 코드베이스 전반에 걸처 진전을 이루는 데 팀원 중 누구도 장애물이 되지 않습니다.

 

코드 검토는 개별 지식을 보다 강력한 배포된 지식으로 바꿉니다.

 

 

그렇다면 어떻게 하면 팀원들이 다른 팀원에게 새로운 문제에 대해 효율적으로 쉽게 소개할 수 있을까요?

 

해결책은 적절한 문제 추적 관행입니다. 잘 알려진 문제는 모든 이력을 한 곳에 보관하여 모든 팀원들이 문제를 그 작업 항목에 대한 대시보드로 볼 수 있습니다. 이 대시보드를 만들고 팀원 간 이전 시간을 최소화하는 다섯 가지 핵심 관행을 살펴보겠습니다.

 

1. 완료에 대한 명확한 정의를 내려야 함

 

 

완료에 대해 일관성 있는 정의를 내리면 코드 작성자와 코드 검토자 사이에 명확한 경계가 생깁니다. 개발자들은 개발을 진행하며 보통 서로 협업합니다.

이는 좋은 일이며 팀이 문제를 해결하도록 권장되어야 합니다. 코드 완료의 의미에 관한 명확한 측정 기준이 있으면 검토자가 검토할 때 일관성 있는 기준과 품질 잣대를 갖게 됩니다.

 

결과적으로 JIRA로부터 검토를 요청하는 알림을 받는 사람은 해당 코드가 이미 체크인 및 빌드되었고, 일정 수준의 자동 테스트를 통과했음을 알 수 있습니다.

이를 통해 검토자는 시간이 잘 활용되고 있다는 확신을 갖게 됩니다. 악랄하게 빌드를 중단시키는 코드를 검토하는 것을 좋아하는 사람은 없습니다.

 

2. 명확한 조치를 취해야 함: 상태 및 양수인

 

코드 작성과 코드 검토는 서로 다른 별개의 작업입니다. JIRA 내부에 이 두 작업에 대해 각각 별도의 상태가 있으면 다른 팀원들이 쉽게 작업의 진행상황을 파악할 수 있습니다.

검토 대기 중인 코드는 체크인 및 빌드되어 자동 테스트를 통해 유효성이 검증된 것으로 알려집니다. 이를 다른 팀원들과 회사에 알리는 것이 중요합니다.

 

 

검토 과정에서 원래 문제의 양수인을 코드 검토자로 이전하는 팀도 있지만 검토자라는 맞춤 필드를 생성하고 이 정보를 추적하는 것을 선호하는 팀도 있습니다.

후자의 방법을 선택할 경우 JIRA 관리자는 개발자가 '진행 중'에서 '검토 중'으로 문제를 이전할 때 코드 검토자를 선택하는 화면을 추가할 수 있습니다.

 

ProTip: 팀에서 맞춤 필드의 검토자를 추적하는 경우 JIRA Agile의 기본 필터인 '내 문제만(Only My issues)'을 assignee=currentuser() 또는 reviewer = currentuser로 수정합니다.

 

 

JIRA 6.3의 경우 문제 추적이 개발의 기본 확장 기능이 됩니다. JIRA의 새로운 워크플로우 트리거 기능을 사용하면 상태 간 문제 업데이트 과정을 쉽게 자동화할 수  있습니다.

JIRA는 공통적인 개발자 조치를 잘 듣고 Stash, Bitbucket, GitHub 뿐만 아니라 Subversion, Perforce, Mercurial with Crucible의 워크플로우를 업데이트합니다.

예를 들어, 개발자가 풀 요청(pull request: 코드리뷰 요청)을 생성하면 JIRA는 자동으로 문제를 '진행 중'(in progress)에서 '검토 중'(in review)으로 전환합니다. 그러면 해당 팀의 모든 팀원이 특정 시간에 문제의 상태를 알게 됩니다.

 

 

3. 도구 통합

 

 

JIRA는 Atlassian Marketplace를 통해 전체 Atlassian 도구 세트 뿐만 아니라 기타 많은 도구와 통합됩니다.

도구가 통합되면 검토자가 원 개발자의 작업 흐름을 따르는 것이 더 쉬워집니다. 문제와 관련있는 모든 애셋은 JIRA의 문제 세부정보 보기라는 곳으로 연결됩니다.

 

1. 맥락 알아보기: Confluence로 연결

 

많은 팀들이 Confluence를 사용하여 개념정의 단계의 요구사항을 추적합니다.

제품 소유자가 Confluence에서 JIRA로 요구사항을 불러오면 Confluence는 각각의 JIRA 문제에서 해당 요구사항이 언급된 페이지로 연결되는 링크를 생성합니다.

코드 검토자가 특정 기능이 구현된 이유에 대해 의문이 생길 경우 원래 사양으로 쉽게 돌아갈 수 있습니다.

 

 

 

Confluence 링크는 JIRA 링크 패널의 문제 링크 옆에 나란히 표시됩니다.

 

2. 코드 검증하기 – Bamboo

 

검토자는 코드가 확실히 컴파일되고 최소한 전체 기능 영역에 대한 자동 테스트를 통과할 것을 기대합니다.

JIRA 6.2의 전개판(development panel)은 코드가 제대로 빌드되었는지 검토자가 알 수 있도록 빌드 및 배포 상태로 풀(pull) 합니다.

 

 

분기 워크플로우당 문제를 사용하면 메인라인 분기로부터 개발자의 변경사항을 분리할 수 있습니다.

Bamboo는 개발자 또는 빌드/릴리스 팀의 인건비를 많이 발생시키지 않으면서 분기 빌드에 대해 완전한 검증을 실행할 수 있다는 점에서 차별화됩니다.

이를 통해 코드 검토자는 커밋 된(committed) 코드에 대해 올바른 테스트가 실행되었다는 것을 확인할 수 있습니다.

이 워크플로우는 Git의 간편한 분기 및 병합 기능과 페어링되어 있어 팀에 이상적입니다.

분기가 마스터로 병합되기 전에 쉽고 완벽하게 검증할 수 있습니다. 하위 버전팀(Subversion teams) 역시 CI로 이익을 얻습니다. 검증하고 검증하고 또 검증합니다.

 

3. 검토할 코드 보기 – Bitbucket/Crucible

 

마지막으로 코드 검토자는 검토해야 하는 코드에 쉽게 접근할 수 있어야 합니다.

JIRA의 개발 패널(development panel)에는 직접 접근을 위한 각 분기, 커밋, 풀 요청이 표시됩니다. 검토자는 마스터로 병합되지 않은 풀 요청과 같은 중요한 이력을 확인할 수 있습니다.

 

 

JIRA가 코드베이스에 연결되어 있어 검토자가 쉽게 문제의 코드를 보고, 전문적으로 정확히 맥락을 따져 댓글(Comments)를 남기며, 원 개발자에게로 다시 문제를 이전할 수 있습니다.

Git에는 Stash/Bitbucket, Subversion/Perforce/Mercurial에는 Crucible을 사용합니다.

 

4. @mentions 기능을 사용해 대화내용 한 곳에 보관하기

 

JIRA의 댓글(Comments)는 팀 전체의 협업 관련 내용을 기록하는 탁월한 방법입니다.

개발 중에는 자연히 질문이 나옵니다.

이메일보다 JIRA 내부에 이러한 대화내용을 보관하면 검토자가 개발 과정을 더 잘 파악할 수 있습니다.

 

 

JIRA 내부의 @mentions 기능을 사용하면 외부 당사자에게 의견이 필요하다는 알림이 JIRA로 연결되는 링크와 함께 전달되므로 JIRA  내에 대화내용을 쉽게 보관할 수 있습니다.

활동 패널에는 문제의 자세한 이력이 보관되어 조사가 용이합니다.

 

5. 올바른 문제 생성 용이하게 하기

 

개발자는 문제를 해결하는 데 필요한 올바른 정보를 제공하는 문제를 사용자가 쉽게 등록하도록 할 수 있습니다. JIRA의 탄력적인 REST API는 거의 모든 애플리케이션과 쉽게 통합될 수 있습니다. 따라서 애플리케이션이 로그를 업로드하고 중요한 환경 정보를 JIRA로 바로 보고할 수 있습니다.

 

로그를 가져오는 것은 보통 어렵고 시간 소모가 많은 과정이지만 개발자는 이 단계를 쉽게 자동화하여 해결하기 더 쉬운 문제를 만들 수 있습니다.

개발자의 상황맥락 정보가 풍부할수록 검토자의 상황맥락 정보 역시 풍부해지고 더욱 효과적인 검토가 가능합니다.

간단히 시작하세요. 문제 제기자가 애플리케이션에 입력하는 미리 지정된 JIRA 이슈키로 환경정보를 기록하는 방법을 구축하면 디버그하는 데 매우 유용할 수 있습니다.

 

또한 JIRA Capture는 마크업 뿐만 아니라 JIRA 문제에 대한 웹 환경정보가 포함된 고충실도 캡처 화면을 자동으로 추가하여 비전문 사용자도 JIRA 내부의 풍부한 개발정보를 가져오는 문제를 쉽게 생성할 수 있습니다.

 

이슈 추적 기능

 

이슈 추적 기능은 코드 검토자가 코드 검토에 사용할 수 있는 명확한 대시보드를 제공합니다. 코드 검토는 소프트웨어 개발의 모범사례로 널리 인식되어 있습니다.

팀에서 코드 검토가 너무 부담스러운 작업이라고 보고하는 경우에는 조직의 이슈 추적 시스템의 기본사항을 확인하세요. 

 

 

Crucible 2.9.1 버전이 릴리스 되었습니다

We have released Crucible 2.9.1. This is a bug fix release.

Crucible 2.9.1 can be downloaded here: http://www.atlassian.com/software/crucible/download

Please also view the Crucible 2.9 Changelog for the list of resolved issues.

Cheers,
The Crucible Development Team

 

Crucible 2.8.2 버전이 릴리스 되었습니다

We have released Crucible 2.8.2. This is a bug fix release.

Crucible 2.8.2 can be downloaded here: http://www.atlassian.com/software/crucible/download

Please also view the Crucible 2.8 Changelog for the list of resolved issues.

Cheers,
The Crucible Development Team

 

Crucible 2.8.1 버전이 릴리스 되었습니다

We have released Crucible 2.8.1. This is a bug fix release.

Crucible 2.8.1 can be downloaded here: http://www.atlassian.com/software/crucible/download

Please also view the Crucible 2.8 Changelog for the list of resolved issues.

Cheers,
The Crucible Development Team

Crucible 2.8 버전이 릴리스 되었습니다

The Crucible team is very pleased to announce that Crucible 2.8 is now available. Highlights include:

  • Mentions
  • Shares
  • Improved performance of the projects listing
  • Support for Subversion 1.7
  • End of life announcements

Crucible 2.8 can be downloaded from:
http://www.atlassian.com/software/crucible/download

For complete details about the release, please see the Release Notes at:
https://confluence.atlassian.com/display/CRUCIBLE/Crucible+2.8+Release+Notes

Cheers!
The Crucible team

 

Crucible 2.7.14 버전이 릴리스 되었습니다

We have released Crucible 2.7.14. This is a bug fix release.

Crucible 2.7.14 can be downloaded here: Cruicible 다운로드  

Please also view the Crucible 2.7 Changelog for the list of resolved issues.

Cheers,
The Crucible Development Team

Crucible도 10달러에 사용해 보십시요

Crucible Starter 라이센스가 생겼습니다; 그리고 새로운 전환점에 도착

Jon SilversStarter 에 대해 이야기 합니다.

Atlassian 의 Starter 라이센스 는 매우 유명합니다.

이 10달러 버전은 이제 시작하는 회사나 시작단계의 툴로서 넓게 사용되어지고 있으며, 100여개국에 팔리고 있습니다.

이 러한 강력한 개발도구를 얻는 이유와는 별도로, 판매금액 전체가 개발도상국에 교육 리소스를 제공하는 국제 자선단체인 Room to Read 에도 기부되고 있습니다.

Starter 라이센스를 판매하기 시작한 이후, 많은 분들이 Crucible (code review software) 에 대해 언제 Starter 라이센스가 사용가능한 지 문의주셨습니다.

그리고 이제 Crucible 또한 Starter license family 에 포함되게 되었습니다. 마찬가지로 5명의 사용자에 대해 10달러에 사용가능하게 된 것입니다.

전세계 수많은 개발팀들이 Crucible을 이용하여 소스코드의 품질을 멘토링, 개선하고 있습니다. Crucible은 소스코드에 대한 여러가지 논란을 없애줍니다.

또한 Crucible을 JIRA를 포함한 다른 Atlassian 툴과 연동하실 수도 있습니다.

$700,000 이상의 달러가 모금되었습니다.

Room to Read에 대해 이야기 하면, 이미 700,000 달러 (한화 7억) 이상의 기부를 하였습니다. 지난 $500,000 milestone 을 돌파한것이 겨우 지난 4월 이었으며, 이제는 $1,000,000 (한화 10억)을 목표로 하고 있습니다.

이 속도라면, 곧 도달될 것으로 Crucible Starter 라이센스의 추가와 더불어 예상됩니다.

$700,000 (한화 7억)으로 무엇을 하느냐고요? Start 라이센스 판매로 모금된 돈은 베트남, 캄보디아, 라오스, 스리랑카의 38,600 명의 어린이들에게 도움을 줍니다. 지원하는 프로젝트의 일부만 나열하면 다음과 같습니다:

  • 77개 도서관: 16개 캄보디아 도서관 + 18개 베트남 도서관 + 43개 라오스 도서관
  • 330 명의 소녀에게 1년의 전반적인 교육: 68명 소녀 (캄보디어) + 150명 소녀 (베트남) + 32명 소녀 (스리랑카) + 80명 소녀 (라오스)
  • 2개 로컬 언어교재: 1개 캄보디어 교재 (2009년, 10,000 부) + 1개 스리랑카 교재 (2010년, 10,000 부 예상)
  • 4개 학교: 2개 유치원 + 2개 초등학교 (스리랑카)

기타
기존의 7개 Starter 라이센스 에 추가로, 아주 많은 무료 애드온 과 일부 파트너사에서 제작한 상업용 플러그인들 "extras" 도 10달러에 이용하실 수 있습니다.

다음 단계는?

코드리뷰 적용 작은(?) 성공담

Agile팀에서의 코드리뷰 - part I



Wojciech SeligaAgile에 대해 이야기 합니다. (2009년 11월)



Atlassian에서 우리는 "애자일" 개발에 대한 믿음을 가지고 있습니다. 가능한 우리는 애자일 스럽게 되려고 하며 확실히 그 장점을 보았습니다.

확실히 "더 애자일" 스러운 팀도 있고, 덜 애자일 스러운 팀도 있습니다.
거의 모든 팀이 서로 다른 애자일 방식을 적용하고 있습니다.
이러한 현상은 우리가 스스로 조직을 구성하고 아래로부터의 진화를 믿는 한은 전혀 문제가 없습니다.
그러나 우리는 애자일 철학에서 4가지 기본 원칙 을 신뢰하고 이것은 우리 회사의 회사의 가치 와도 부합합니다.

Crucible 이 Atlassian 제품군에 포함되었을 때, 많은 직원들이 어떻게 코드리뷰를 우리 애자일 환경에 매칭시킬 수 있을 지 의문스러워 했습니다.
2년이 지난 지금, 코드리뷰는 우리 애자일 개발자들의 하루 일과로 완전히 녹아들었습니다.
어떤 직원은 매우 중독되었습니다. 왜 그런지 이야기해 보겠습니다.

저는 코드리뷰 자체의 명확한 장점인 코드품질의 향상에 대해서는 이야기 하지 않겠습니다. 대신에, 코드 품질은 좋은 부산물이지, 우리팀의 코드리뷰 목적은 아니라고 이야기 하고 싶습니다.

코드리뷰는 애자일의 기본선언인 "프로세스와 도구를 통한 개인과 상호작용" 원칙을 적용하기 위한 하나의 방법입니다. 여기 코드리뷰가 어떻게 더 좋은 협업을 할 수 있도록 하는지에 대한 예가 있습니다.

새로운 팀 멤버





Atlassian은 지속적으로 성장 하고 있습니다. 열정적이고, 때로는 우리의 복잡한 코드작업에 빠르게 참여할 필요가 있는 상당히 경험많은 개발자도 채용합니다. 새로운 채용뿐 아니라, 기존의 팀원도 때로는 완전히 다른 혹은 임시의 위치로 순환근무 하기도 합니다.

코드리뷰는 새로운 코드베이스(소스코드)에 더욱 빠르고 용이하게 접근할 수 있도록 도와줍니다.
그리고 팀과 회사의 기술적인 지식을 유지하도록 도움을 줍니다.

회사의 소스코드에 이미 익숙해진 사람들은 새로운 직원의 댓글에 대해 리뷰하고 (버그나 기능에 대한 코딩을 하는 것보다 제품에 대해 배우는 더 좋은 방법은 없습니다), 새 직원의 디자인 불일치에 대해 조언해 주고, 새 직원이 배우고 익혀야 할 도구나 컴포넌트에 대해 공유합니다.

거꾸로, 새 직원은 중요한 경험과 좋은 기술적 예, 유용한 라이브러리, 훌륭한 패턴, 기법등을 이전의 팀에서 가져와 소스코드를 개선시키는데 도움이 될만한 관점을 제공하기도 합니다.

간단히 말해, 코드리뷰는 양방향 대화인 것입니다. 작성자와 리뷰자가 모두 서로 통신하고 각자에게 배우는 것입니다.

코드리뷰는 중급의 개발자가 팀에 합류할 때 더욱 중요합니다.
고급 개발자는 스스로 코딩을 해야 하므로 중급 개발자를 도와줄 시간이 없습니다.
그렇지만, 중급 개발자의 소스코드를 가끔 리뷰하는 것은 그리 큰 일은 아닙니다.
결과는? 고급 개발자는 자신의 코드 개발에 하루의 대부분을 집중하고 중급 개발자가 변경한 소스코드를 리뷰하는데 하루에 10-15분씩 2,3번 정도 시간을 소비합니다.

중급 개발자는 이 피드백을 통해 도움을 받고, 고급 개발자는 중요한 코딩 시간을 빼앗길 필요가 없는 것입니다.

지리학적 분산 (Geographical distribution)



Atlassian 회사는 3개의 나라에서 소프트웨어를 개발하며, 각각의 시간대는 10시간이 차이납니다.
동일한 코드베이스의 소스코드 작업을 하는 대부분의 팀들은 같은 지역에 있게 됩니다. (정말로 도움이 됩니다)
그렇지만, 때로는 이것이 실용적이거나 가능하지 않습니다. 그래서 결국 우리는 몇 개의 지리학적인 배포팀을 구성하였습니다. – 짝 프로그래밍과 매일 스탠드업과 같은 일부 애자일 실행방법에서는 큰 문제입니다.

코드리뷰가 지원되는 툴은 여기서 서로 다른 지역간의 지식흐름을 이용하고 활용하는데 좋은 해결책이 됩니다.

비동기적인 코드리뷰를 통해, 시간대의 차이는 단점이 아닌 장점이 될 수 있습니다. 때로는 오후 (그날의 작업에 대한 요약으로서) 에 리뷰를 작성하고 태평양 건너 있는 다른 직원에게 리뷰를 부탁한 후 집으로 갑니다.
다음날 아침 우리가 회사에 도착하면, 리뷰에 대한 피드백을 바로 확인할 수 있습니다: 우리가 잠자고 있을 때 동료직원이 리뷰를 해 준 것입니다.
매일 아침 첫번째 작업으로 이러한 피드백을 답변하고 확인된 문제를 수정한 후, 일상의 개발작업을 진행해 갑니다.

통합



코드베이스(소스코드 저장소)는 분리되어 있지 않습니다. 대부분의 Atlassian 제품은 서로 여러가지 방식으로 통합되어 있습니다.

예들 들면, 저는 미국에서 IDE Connectors개발 작업을 수행하는데 시드니에 주로 위치한 Atlassian 서버와 Remote API로 통신할 필요가 있습니다.

이 API는 지속적으로 개선되는데, 때로는 IDE Connector 팀의 요청에 의해 개선되기도 합니다.

서버 제품 팀은 주로 시드니에서 근무하고 그쪽은 저희 작업이 시작할 때 업무가 끝나는 상황입니다. (미국 캘리포니아와 호주 시드니의 시간차이로 인해)

코드리뷰는 IDE Connector 팀이 의존하는 remote API 관련해 피드백을 제공하는 주요 수단입니다.

Remote API에 관련된 변경사항이 발생 할 때마다, 저는 리뷰어 중 한 사람이 됩니다 – 그래서 서버측에서 상황이 어떻게 된 것인지 알 수 있고 API의 수정상황에 대해 건설적이니 비판을 하기도 하며, 변경사항이 진행되기 전에 최소한 제 팀이 연관된 것임을 확실히 알려주시고 합니다.

유사한 경우가 바로 일반적으로 작업하지 않는 제품에 대해 무엇인가를 프로그래밍 하는 경우가 발생했을 때 입니다. 우리는 이것을 "손님(게스트) 프로그래밍" 이라고 부릅니다 – 예를 들면, 오직 자신만의 개발환경에서만 발생하는 문제를 수정하거나 혹은 누락된 API를 추가하거나 누락된 플러그인 포인트를 추가하는 경우입니다.

코드리뷰는 양쪽을 자극하여 손님(게스트) 프로그래밍을 가능하게 합니다.

제품을 담당하는 팀은 외부사람이 자신들의 코드를 건드리는 것을 좋아하지 않고 손님 프로그래머는 다른 사람들이 나쁜 버그를 막기 위한 자신의 코드를 리뷰해 줄 것이기 때문에 용기를 가질 수 있습니다.

용기에 대해 이야기하면 – 우리 팀 중 일부는 실제로 코드리뷰가 없을 때 매우 걱정을 합니다.

유닛 테스트는 귀찮은 재반복(리그레션) 테스트 없이 코드를 개선하고 리펙토링 할 수 있는 용기를 가지도록하는 안전망을 구성해 줍니다.

유사하게, 코드리뷰는 또 다른 안전망이어서, 사람들에게 당신의 특이한 아이디어가 제품에 반영되기 전에 미리 다른 사람들에게 평가 받을 것이라는 느낌을 주게 하며, 당신의 훌륭한 디자인, 유틸리티, 기법이 다른 팀에 의해 다른 장소에서 재사용될 수 있도록 확산될 기회를 제공합니다. 이것이 진정한 팀워크입니다.

코드리뷰는 어렵고, 실제 적용 유지하는데 비용이 많이 들 수 있습니다.
그러나, 모든 팀과 모든 팀원이 짝 프로그래밍을 원하지는 않는 상황에서, 코드리뷰 미팅은 상당한 시간을 소비하게 합니다.

우리는 Crucible을 사용하여, 리뷰 작업을 수행하고, 개발자가 코드리뷰의 중요한 작업에 집중할 수 있도록 합니다: 코드와 피드백 제공에 대해 생각해 보십시요.

다음 블로깅에서는 애자일 팀 혹은 회사에서 표준 절차로서 코드리뷰를 실행하는데 있어 연관된 몇 가지 조언과 주의사항을 공유할까 합니다.

그리고 세번째, 혹은 최종 블로그에서는 코드리뷰와 짝 프로그래밍을 비교해 보고, Atlassian에서 적용해 온 코드리뷰에 대해 몇 가지 규칙을 알려드리도록 하겠습니다.

(골드피처 주)



코드리뷰는 소프트웨어를 개발하는 회사에서는 이제 누구나 한번쯤 들어보았고 필요성에 대해서도 공감을 하는 내용입니다.

그러나 실제 업무에 적용하는 것은 말처럼 그리 간단하지 않은 것이 현실입니다.

우선 소스저장소를 운영하지 않는 회사는 소스저장소를 운영하면서 형상관리툴을 사용하는 것부터 익숙해 져야 하는데 이것도 아직 국내에서는 정착되지 않은 경우가 많습니다. 특히나 오래된 회사일수록 이러한 개발환경을 변경하는 것은 상당한 모험이니까요.

하지만, 언제까지 미룰 수는 없습니다. 코드리뷰가 모든 업무나 모든 사람에게 필요한 것이 아니라 하더라고 분명 효과를 얻을 수 있는 사람이나 부서가 있습니다.

또한 회사차원에서는 신입직원의 교육이나 소스코드에 대한 정보 축적 관점에서는 분명 투자대비 얻는 효과는 부서나 직원이 얻는 효과와는 비교도 되지 않는다고 할 수 있는 것입니다.
이제 직접 시도해 보시지 않으시겠습니다. Crucible 에서 다운로드 하여 사용해 보십시요.

Atlassian Connector for Eclipse 2.0 – 더 나은 Crucible 리뷰와 추가기능



Jesse Gibbseclipse 에 대해 이야기 합니다. (2010년 3월)

최신 Atlassian Connector for Eclipse 에 대해 추가된 기능에 대해 이야기 하겠습니다.
이번 Eclipse plugin 은 Atlassian의 Crucible 소스코드리뷰 툴(code review tool) 을 사용하는데 있어서 매우 중요한 개선사항을 포함하고 있습니다.

리뷰(Review)와 편집모드 – 모두 동시에!



새로운 Crucible 리뷰 퍼스펙티브를 통해 파일내용과 리뷰를 동시에 작업할 수 있게 되었습니다. 또한 탐색과 댓글의 보기/추가/삭제도 화면을 번갈아 왔다갔다 하지 않고도 동시에 같이 작업 하실 수 있습니다.
Crucible 리뷰 퍼스펙티브는 또한 여러분의 작업공간을 논리적인 레이아웃으로 구분하여 더욱 리뷰를 쉽게하도록 도와줍니다.



리뷰 생성, 업데이트하는 더 많은 방법



또한 여러분의 이클립스 IDE에서 pre 혹은 post-commit 리뷰를 생성하는 여러가지 방법을 추가하였습니다.
그리고 이번 릴리스에서는 Crucible의 웹기반 인터페이스 시작없이도 리뷰에 파일을 추가하는 기능도 포함되었습니다.

이 외에도 100여개 이상의 버그 수정과 작은 개선사항들이 포함되었습니다.



전체 릴리스노트를 읽어보시거나 혹은 직접 설치 해 보십시요.

웹 페이지의 UI 와 성능

사용자 인터페이스와 성능의 결합



Seb RuizCrucible 에 대해 이야기 합니다.

Crucible 팀에서 일반적으로 직면하는 싸움 중 하나는 어마하게 많은 DOM 구조의 리뷰 보기 시 웹 브라우저의 성능문제 입니다.

저는 예전 저 의 이전 블로그 에서 어떻게 Crucible 팀이 이벤트 델리게이션과 라이브 이벤트를 사용하여 많은 페이지 요소를 가지는 오버헤드가 큰 바인드 호출을 대치하 수 있는지 언급하였습니다.

이번에는, 많은 작업을 보여주는 페이지를 처리할 때, 선능을 개선하기 위한 다른 2가지 방법을 공유하고자 합니다.

리플로(reflows) 회피



만약 여러분이 성능과 관련된 웹 개발 작업을 하였었다면, 이미 가능한 경우의 페이지 리플로(reflow)를 회피하는 개념에 대해 익숙하실 것입니다.

Steve Souders 의 말에 따르면:

리플로(reflow)는 CSS 규칙이 재적용 되는 것을 필요로 하며, 이것은 브라우저가 한번 이상 모든 CSS 셀렉터를 매칭해야 하는 것을 의미합니다.

만약 CSS 셀렉터가 효율적이지 않다면, 리플로(reflow)는 많은 시간이 소요될 것입니다. - 사용자가 인식할 만큼의 긴 시간 말입니다.

이 인용문에서, Souders는 셀렉터를 평가하는 것이 얼마나 효과적인 방법인지를 가지고 리플로(reflow)의 영향에 대해 이야기 하고 있습니다. 언급되지 않았지만, 리플로 타임 또한 그러한 스타일 규칙 (DOM 크기 같은) 을 적용하는 페이지의 항목 수에 매우 의존적입니다.

페이지에서 리플로를 발생시키는 방법은 일반적으로 많습니다만, 때로는 리플로를 구동하는 횟수를 줄이려는 시도에 대한 내용도 아셔야 할 필요가 있습니다.

만약 이전에 이런 내용을 본적이 없다면, 여기 위키피디어를 로팅할 때 페인트 액션을 보여주는 좋은 비디오가 있습니다:

(골드피처 주) 비디오는 가져오기 기능이 되지 않아 이곳 에서 확인하시기 바랍니다.


UI 고스팅(Ghosting)




구성요소의 차수를 변경하는 것은 분명히 리플로(reflow)를 발생시킵니다. 일반적인 Crucible 리뷰의 페이지 구조는 아래 그림과 같습니다.



우측칸은 문서 구조의 (대략 80%) 대부분을 포함합니다. 왼쪽칸은 크기가 조정될 수 있는데 이 때 두 칸 모두의 차수가 변경되며, 이것은 브라우저가 컨텐츠를 리플로(reflow) 하도록 만듭니다.

여러분의 브라우저 윈도우를 상상해 보십시요. 크기변경바를 드래그 하면, 윈도우는 자연스럽게 크기가 변경되고 거의 실시간으로 컨텐츠를 재 구성하여 업데이트 합니다. 이것은 대부분의 경우 요구되는 것이지만, 컨텐츠를 다시 그리고 계산하는 작업이 리사이즈 이벤트 사이의 시간보다 적게 소요되는 경우에만 해당합니다. (혹은 그러기에 오버헤드가 크기않은 경우)

이전 Crucible 릴리스에서는, 이 컨텐츠 사이의 스플리터(splitter)의 크기를 조정하면 바로 컨텐츠를 다시그리기 하였습니다. 그렇지만 이것은 아주 큰 데이터의 리뷰의 경우는 부분적으로 적합한 내용인데 왜냐하면 리플로(reflow) 작업이 매우 많은 시간이 걸리는 경우가 있을 수 있기 때문입니다. (거의 수백 밀리초)

우리는 이것을 깔끔한 방법으로 처리하였는데, 바로 UI 고스팅 입니다.

중복된 구성요소를 불투명하게 오버레이함으로서, 사용자가 최종 크기를 결정하기 전까지는 리플로(reflow)를 발생하지 않도록 하였습니다. 확인해 보십시요:



jQuery UI를 사용한다면, 이러한 효과를 크기변경가능한 위젯의 ghosting option을 통해 간단히 수행할 수도 있습니다.

여기 또다른 컨텐츠 채움을 요구하는 경우가 있습니다. 매우 큰 DOM 으로 인해 윈도우 크기조정에 문제가 있는 경우 대부분의 트리가 보이는 시각에서 벗어나는 경우가 있습니다.

이것은 그것을 보일 필요가 없고 바로 필요한 내용이 아닌 경우 DOM 에서 컨텐츠를 안정하게 제거할 수 있음을 의미합니다.

만약 스크롤바가 모든곳에 존재하는 것을 우려한다면, 실제 컨텐츠의 높이를 아는 동안만은, CSS 스타일로 이것을 처리할 수 있습니다.

사용자가 페이지를 스크롤할 때, 바로 보이는 부분에 근거하여 컨텐츠를 추가 혹은 삭제할 수 있습니다.

더욱 편리한 접근을 위해 Ajax를 통해 컨텐츠를 요청하거나 혹은 JavaScript로 컨텐츠를 로드할 수도 있습니다. 기본 개념은 아래와 같습니다:

 

이 방법을 통해 페이지는 언제나 빠르게 느껴지고, 이것은 실제 페이지에서 컨텐츠가 적게 로드되기 때문입니다. 우리는  이 방법을 매우 효과적으로 이용하여 다른 여러곳에서 새로운 side-by-side diffs를 처리하였습니다.
이 블로그를 통해 여러분이 매우 큰 웹 페이지를 처리해야 하는데 성능상의 문제가 있을 때 여러분의 경험을 늘리기 위한 정보를 활용하십시요. 

ClearCase를 사용하시나요? FishEye & Crucible 얼리어댑터프로그램을 확인해 보십시요!



Jesse Gibbsfisheye에 대해 이야기합니다.

이제 FishEye 와 Crucible이 IBM Rational ClearCase를 지원하게 되었습니다. 현재 알파버전이며 정식버전 출시 전 테스트해 보고 싶으시다면, 저희 본사 Atlassian's early access program (EAP)을 통해 다운로드하여 테스트 해 보십시요. 이제 FishEye 가 ClearCase를 지원하게 됨으로써, ClearCase 에 있는 소스들에 대한 소스코드 리뷰도 Crucible을 통해 수행할 수 있게 되었습니다. 피드백 절대 환영!

저희 EAP 다운로드 페이지에서 알파버전을 받으시고 싶으시면 아래 링크를 참조하십시요.




또한, 자세한 ClearCase 지원에 대한 사항을 확인하시고 싶으시다면 릴리스 노트를 확인해 보십시요.

알파 버전에 대한 피드백은 아래 포럼을 통해 해주시면 감사하겠습니다.




우리 개발팀들이 여러분의 피드백을 확인하고 이슈로 생성할 것입니다. 한번 테스트해 보시겠습니까?!