엔터프라이즈 2.0 - 개념에서 부터 전략까지 2009/10/12

Enterprise 2.0 Overview Terry.Cho (Principal consuntant/Oracle Korea) 제4의 물결 본격적인 현대의 기업 모델이 생성된 이.....

마이크로 블로그(트위터)의 기업 도입 전략-기업에서 마이크로 블로그 활용방안 및 구축 전략 2009/09/24

기업에서 마이크로 블로그의 도입 지금까지 마이크로 블로그에 대해서 알아보았다. 그러면 이 마이크로 블로그 시스템을 기업에 어떻게 적용할 수 있을까? 기업 내부 협업 플랫폼으로써.....

마이크로 블로그(트위터)의 기업 도입 전략 - 1.마이크로 블로깅 시스테 2009/09/22

Micro blogging strategy for Enterprise Terry.Cho (Principal Consultant/Oracle Korea) 마이크로 블로깅의 대명사.....

모차세대 시스템의 WAS 아키텍쳐 Blue Print 2009/07/30

OO 차세대 시스템 WAS Architecture Blue Print (DRAFT) 2009-06-28 Oracle Korea Consulting Principal Consul.....

EAI관점에서 본 SOA 2009/07/29

EAI관점에서 본 SOA<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> 2009-07-.....

EAI (Enterprise Application Integration) 추진 전략 2009/07/16

EAI 프로젝트 추진 전략 2009-07-16 Oracle Korea / Principal Consultant Byungwook Cho. (byungwook.cho@oracle.....

Domain Driven Design - Modeling 2009/07/07

직업이 직업인 만큼 요즘 Domain Driven Design 에 대해서 심도깊게 보고 있습니다. 아키텍쳐 분석 설계와 프로젝트 진행에 있어서 가장 중요한 것중의 하나가 "고객.....

REST 연재-2회 Advanced REST 2009/06/23

2회 - Advanced REST (DRAFT) 자바스터디 조대협 (http://bcho.tistory.com) 전의 글에서는 기본적인 REST의 개념에 대해서 설명하였다. 그.....

REST 연재-1회 REST 아키텍쳐의 기본 2009/05/27

1회 – REST 아키텍쳐에 대한 기본(DRAFT) 자바스터디 조대협 http://bcho.tistory.com REST 아키텍쳐 REST는 웹의 창시자(HTTP) 중의 한.....

자바 기술 트렌드 분석 - 2. OR Mapping 2009/04/30

두번째 기술 트렌드 분석은 DB2JAVA 즉 OR Mapping Framework 입니다. IBatis와 Hibernate를 봤는데, 1. IBatis 2. Hibernate.....

자바 기술 트렌드 분석 - 1. MVC 2009/04/30

백기선님 블로그에서 재미있는 글을 하나 봤습니다. 구글 검색엔진에, http://www.google.com/trends 을 보면 검색어별로 검색 비중에 대한 트렌드를 보여줍니다.....

Software Testing Proces 2009/04/09

Testing process View more presentations from Byungwook....

ALM Overview PPT 2009/03/16

그간 정리해왔던 ALM에 대해서 전체 그림을 다시 한번 정리하였습니다. 컨버팅 과정에서 폰트가 깨져서 좀 보기가 어려울 수 있습니다. 별도로 자료가 필요하신분들은 요청하시면 보.....

코드리뷰 2.- 언제 어떤 리뷰 기법을 사용할것인가? 2009/03/12

언제 어떤 코드 리뷰 기법을 사용해야 하는가? 그러면 이런 많은 코드 리뷰 기법 중에서 어떤 기법을 사용해야할까? 코드 인스펙션 코드 인스펙션의 전제는 전문성을 가지고 있는.....

코드 리뷰 - 1. 코드 리뷰 기법들에 대한 소개 2009/03/11

들어가기에 앞서서. 소프트웨어의 품질을 보장하기 위한 활동은 테스팅, 일일 빌드, 프레임웍의 사용, 개발 패턴들 수 없이 많은 방법들이 있다. 그중에서 개인적으로 생각하건데,.....

실용주의 ALM (Application Lifecycle Management) Overview - PDF 2009/02/18

PDF 버전입니다....

실용주의 ALM (Application Lifecycle Management) Overview 2009/02/18

Practical Application Life cycle Management (ALM) Overview ALM의 정의를 wikipedia에서 찾아보면 다음과 같다. Appl.....

ALM / Task Management Process (Scrum 기반 프로젝트 관리 방법론 - PDF) 2009/02/17

PDF 버전입니다....

ALM / Task management process (Scrum 기반의 프로젝트 관리 방법) 2009/02/17

Overview 프로젝트에서 중요한 포인트중의 하나는 팀의 운영과 관리이다. 프로젝트에 Unified Process나 Waterfall model과 같은 기존의 방법론을 사용하.....

엑셀 기반의 Task management (스케쥴 관리) 2009/01/14

ALM 프레임웍중에서, JIRA와 같은 이슈 추적 시스템을 이용하여 스케쥴 관리와 작업 추적을 할 수 있지만, 프로젝트에 따라서는 이슈 추적 시스템의 도입이 어렵거나, 별도의.....

ALM-Project Management 2008/12/24

ALM의 이슈트랙킹 시스템을 통한 프로젝트 관리 방법입니다. 아래 그림이 구현하고자 하는 내용의 모두라고 볼 수 있습니다. PM : 요구 사항을 시스템에 등록하고 각 요구 사항.....

ALM Concept 2008/12/24

제 블로그에 자주 오시는 분들이나 혹은 강연이나 기고를 보신분들은 아시겠지만 2008년 한해는 ALM (Application Lifecycle Management)쪽에 많은 시.....

개발환경 자동화 환경에 대한 추천 조합 2008/03/13

몇가지 개발환경 자동화에 대한 테스트 조합을 해본결과에 대해서 추천을 드리겠습니다. 1. 이슈 관리 시스템 Mantis,Trac,Bugzilla,JIRA를 운용해봤습니다 결과는.....

JVM 튜닝 2008/03/12

진짜 오래전 문서인데.. JVM 튜닝 문서 링크 == JVM GC와 메모리 튜닝 자바스터디 네트워크 [www.javastudy.co.kr] 조대협 [bcho_N_O_SPAM@j.....

단위테스트 3회 - 커버러지 분석과 단위 성능 테스트 2008/03/12

테스트 코드 커버러지와 단위 부하 테스트<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />.....

단위 테스트 2회 - 확장된 단위 테스트 도구 (Cactus,JUnitEE) 2008/02/19

확장된 단위 테스트 도구<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> (Cactus.....

단위 테스트 1회 (JUnit) 2007/11/23

단위 테스트 (Unit Test)<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> 200.....

What is SOA? How to SOA? 2007/09/04

컴퓨터 시스템이 사용되면서부터, 각 시대의 기업 전략에 맞는 소프트웨어 아키텍쳐 존재하여 왔다. 초기 시대의 메인프레임에서는 기업의 업무를 전산화 하는데 목적이 맞춰졌고, 소프.....

EAI 도입 전략 2007/08/21

한국 소프트웨어 진흥원 부탁으로 써줬던 기고인데, EAI의 도입 전략에 대해서 설명했던 글이다. == Introduction strategy of EAI<?xml:namespa.....

About SOA 2007/08/20

2007년 7월 6일 포스팅 글 == 이번에도 SOA기고를 하나 하긴 했는데. 맨날 했던 말이 그말인것같다. 한번 더 고민 한점이 있다면 한국에서만 유달리 SOA가 전파되지 않.....

SOA에 대한 기술적 접근 2007/08/20

월간 마이크로소프트웨어 2007년 7월호 기고 내용 == “ SOA는 무엇이고, SOA를 준비하기 위해서 무엇을 해야 할까? 그리고 SOA 시스템을 구축하기 위해서는 어떤 기술.....

코드리뷰 2.- 언제 어떤 리뷰 기법을 사용할것인가?

ALM/Task Management

2009/03/12 14:35

언제 어떤 코드 리뷰 기법을 사용해야 하는가?

그러면 이런 많은 코드 리뷰 기법 중에서 어떤 기법을 사용해야할까?

코드 인스펙션

코드 인스펙션의 전제는 전문성을 가지고 있는 인스펙션 팀이 일정한 프로세스와 패턴에 따라서 개선안을 찾는 작업이다.

즉, 고도로 훈련됨 팀과 기간이 필요하고, 어느정도 개발이 완료되어 있는 인스펙션 대상(시스템)이 있는 것을 전제로 한다.

인스펙션의 시기는 시스템이 개발되어 있는 시점인 Release이 유용하다.

필자는 두번의 Inspection을 권장하는데, 개발 초기에 비기능적인 구현을 끝낸 경우 1차 Inspection을 그리고, 개발이 끝난 후 시스템 테스트 (성능,확장성,안정성등)가 그것이다.

1차 Release는 주로 비기능적이고 Risk가 높은 부분을 구현하는 단계인데, 이 구현체는 전체 시스템 아키텍쳐의 큰 틀이 되며, 추후 개발에도 이 아키텍쳐는 크게 변경되지 않는다. (1차 Release 다음에 변경하려면 후반으로 갈수록 많은 리소스가 소요된다.) 그래서 1차 Release후에 정밀 Inspection을 해서 아키텍쳐의 안정성을 검증할 필요가 있다.

개발 후반의 시스템 테스트는 주로 비기능적인 요건 (성능,안정성등..)에 대한 성능 테스트가 이루어지는 단계이기 때문에, 테스트 시나리오가 미리 잡혀져 있고 테스터와 테스트 시나리오가 명확하게 정의되어 있기 때문에, 인스펙션을 수행하기 용이하며 최종 점검이라는 관점에서 매우 유용하다.

인스펙션을 수행하는 주체는 전문 SI 社 Task Force를 운영하여 프로젝트를 돌아다니면서 인스펙션을 수행할 수 있고, 여러 개의 솔루션을 인하우스 개발하는 업체 (네이X)와 같은 업체는 QA 조직내에 자체적으로 인스펙션팀을 운영하는 것을 권장한다. 그외의 일반 업체 (갑)나 기업의 경우 인스펙션팀을 운영하기 보다는 인스펙션 프로세스를 전체 개발 프로세스와 프로젝트 비용 산정에 포함하고 SI나 벤더 컨설팅을 활용하는 것을 권장한다.

인스펙션의 결정 주체는 주로 PMO(Project Management Office)와 AA (Application Architect) 되는 것이 바람직하다, 대체로 개발 주체 조직 외부에서 인력을 데리고 오고, 여러팀이 함께 인스펙션에 참여해야 하며 일정에 대한 조정과 인스펙션 결과에 대한 반영이 필요하기 때문에 프로젝트 관리 조직 측면에서 접근하는 것이 바람직하다.

팀리뷰

팀 리뷰는 각 개발 유닛에서 활용하기 좋은 기법이다. PL (Project Leader)의 역량아래 수행할 수 있으며, 팀원이 리뷰어가 되기 때문에 팀 단위에서 활용하기가 매우 좋다.

일주일에 한번정도, 한시간 정도 리뷰를 정기적으로 수행하도록 하며, 시니어 개발자나 PL이 리뷰 대상 모듈을 선정하고 개발자에게 리뷰를 준비하도록 한다.

리뷰는 발표자가 리드를 하도록 하고, 리뷰에서 나온 의견을 Action Item으로 잡아서 PL이 발표자의 스케쥴로 조정을 해주는 작업이 필수적으로 따라야 한다.

팀 리뷰에서 권장하고 싶은 사항은 위에서도 잠깐 언급했지만 위키와 같은 문서 공유 시스템을 이용하여 반드시 리뷰의 결과를 남기도록 하고, 리뷰의 결과는 Task Management의 Task로 연결이 되어야 한다.

리뷰되고 반영된 내용은 그냥 넘어가지 않도록 하고, 재 테스트를 통해서 반영 내용을 반드시 검증하도록 한다.

웍쓰루 (WalkThrough)

일종의 아이디어 회의 정도로 보면 되며, 비정기적으로 언제나 개최할 수 있다.

팀리뷰처럼 PL이나 시니어 개발자가 중재를 하지 않기 때문에 구성원들의 의욕이 낮을 경우 효과가 매우 낮다. 개발팀보다는 QA나 운영팀에서 장애 사례나 버그 수정 사례 등의 정보 교환 목적으로 사용하는 것이 좋다.

Peer Review

신입 개발자 교육이나, 해당 제품이나 기술에 전문적인 지식이 없는 경우에 Knowledge Transfer(지식공유)와 품질 유지를 위해서 유용하다.. 대신 리뷰어의 Task 부담이 가중되기 때문에 (예상하는 것 보다 많이. 심하게는 50%에 육박할 경우도 있음) 리뷰어에 대한 스케쥴 배려가 필요하다.

요약

	시기	효과	변경에 대한 비용	수행 비용	주체
인스펙션	1차 Release, 시스템 테스트	매우높음	매우 높음	높음	PMO,QA,AA
팀리뷰 ★	매주	높음	보통	보통	PL
웍쓰루	비정기적	낮음	보통	낮음	원하는 개발자
Peer Review	필요한 경우	경우에 따라 높음	낮음	보통	시니어 개발자

본인의 경험상 팀리뷰가 가장 효과가 높다. Peer Review는 팀원간의 실력 편차가 클 때 탄력적으로 운영하였고, Enterprise System과 같이 난이도가 높은 시스템의 경우 인스펙션의 효과가 비교적 크다. 비록 비용이 소요되지만 잘못된 아키텍쳐로 인해서 전체 품질이 떨어져서 비즈니스에서 손해를 보거나 쓸떼 없이 하드웨어 증설을 통한 비용을 생각하면 훨씬 낮은 금액이 아닌가 싶다.

효과적인 코드 리뷰를 막는 요인들

코드 리뷰에서 가장 힘든 점은 한마디로 “내가 만든 코드를 남이 잘못되었다고 이야기 한다.” 입니다.

리뷰의 주요 목적은 결함의 발견과 개선 방안입니다. 흔히 농담 삼아서 “창던지기”라고 이야기 하는데, 발표자는 리뷰어로부터 많은 질문과 공격을 당하게 됩니다. 그래서 실제로 인스펙션을 해보게 되면 개발자는 인터뷰를 당하는 것에 대해 취조 당하는 느낌을 가지게 될 수 도 있고 방어적으로 행동할 수 도 있게 됩니다.

팀리뷰의 경우 감정싸움까지 가는 경우가 허다하지요.

팀리뷰나 인스펙션의 경우 리뷰를 중재하는 사람이 있기 때문에, 리뷰어가 아이디어나 결함에 대한 의견을 자유롭게 개진할 수 있도록 해야 하며, 반대로 발표자가 인신 공격을 받지 않도록 중재하는 기능도 필요합니다. 이건 어떤 프로세스나 시스템으로 될 수 있는 일이 아니라 “사람 사이의 관계”에서 발생되는 일이기 때문에 “문화”의 변화가 필수적입니다.

또한 위에 언급한 대부분의 리뷰 기법들은 리뷰와 그에 대한 후속 처리가 시간과 사람이 필요한 일이기 때문에 프로젝트 운영 관점에서 시간과 리소스에 대한 배려가 이루어져야 합니다.

경험상으로 팀리뷰가 팀에 자리잡기 위해서는 좋은 리더가 있다하더라도 최소한 1달정도의 (통상 2달) 기간이 필요합니다. 급하게 할일은 아니라는 겁니다.