case I:

public class Starter extends Thread {
    private int x = 2;
    public static void main(String[] args) throws Exception {
        new Starter().makeItSo();
    }
    public Starter(){
     System.out.println("start Starter()..");
        x = 5;
        System.out.println("start Starter()x="+x);
        start();
        System.out.println("start Starter().start().x="+x);
    }
    public void makeItSo() throws Exception {
     System.out.println("start makeItSo");
        join();
        System.out.println("start makeItSo().join().x="+x);
        x = x - 1;
        System.out.println(x);
    }
    public void run() {
        System.out.println("start run");
     x *= 2;
     System.out.println("start run.x="+x);
    }
}

결과:

start Starter()..
start Starter()x=5
start Starter().start().x=5
start makeItSo
start run
start run.x=10
start makeItSo().join().x=10
9

case II:

public class Starter extends Thread {
    private int x = 2;
    public static void main(String[] args) throws Exception {
        new Starter().makeItSo();
    }
    public Starter(){
     System.out.println("start Starter()..");
        x = 5;
        System.out.println("start Starter()x="+x);
        start();
        System.out.println("start Starter().start().x="+x);
    }
    public void makeItSo() throws Exception {
     System.out.println("start makeItSo");
        //join();
        System.out.println("start makeItSo().join().x="+x);
        x = x - 1;
        System.out.println(x);
    }
    public void run() {
        System.out.println("start run");
     x *= 2;
     System.out.println("start run.x="+x);
    }
}

결과:

start Starter()..
start Starter()x=5
start Starter().start().x=5
start makeItSo
start makeItSo().join().x=5
4
start run
start run.x=8

-- 20130311

-- 오라클 데이터 딕션어리 뷰

select *
from dict ;

dba_     : (dba권한) DB 모든 정보 조회 가능
-> grant select_catalog_role to DB계정명 (딕션어리정보만 볼수 있는 권한)
all_       : DB 내가 만든 것 + DB 내가 권한 받은 것
user_    : DB 내가 만든 것
x$        : DB 성능 및 통계정보
v$        : DB 성능 및 통계정보

EX)
select *
from dba_tables ;     all_table ;        user_tables ;

--PK
1. not  null + 중복제거
2. pk컬럼은 자동으로 인덱스 생성
3. 1개 테이블에 pk는 존재 o (pk 1개만 생성), 존재 x
4. 1개 테이블에 1개 또는 여러개의 컬럼으로 pk는 1개 만들 수 있다.

--FK
1. 데이터는 부모없는 자식은 없다.
2. 데이터는 자식없는 부모는 있다.
3. 데이터의 변경 및 삭제는 자식부터 한다.

-- 테이블 생성 스크립트
CREATE TABLE 테이블명  (
   FILE_ID              VARCHAR2(25)                     NOT NULL,
   FILE_ID_FORM         VARCHAR2(6),
   RECP_DT              VARCHAR2(8),
   WRK_TYPE_SEQ         VARCHAR2(6),
   RECV_DT              VARCHAR2(8),
   CONSTRAINT PK_테이블명 PRIMARY KEY (FILE_ID)
   using index
   tablespace 테이블스페이스명
   storage( initial 1M next 1M maxextents unlimited pctincrease 0
freelists 10 freelist groups 2 )
)
tablespace 테이블스페이스명
storage( initial 1M next 1M maxextents unlimited pctincrease 0
freelists 10 freelist groups 2 )
/

-- NOT NULL을 NULL로 바꾸기
ALTER TABLE 테이블명 MODIFY (컬럼명 데이터타입 NULL ) ;

-- NULL을 NOT NULL로 바꾸기
ALTER TABLE 테이블명 MODIFY (컬럼명 데이터타입 NOT NULL ) ;

-- 컬럼 변경
ALTER TABLE 테이블명 MODIFY (컬럼명 VARCHAR2( 20 ) ) ;

-- 컬럼 추가
alter table 테이블명
add        (컬럼명  데이터타입);

-- 컬럼 삭제
alter table 테이블명
drop        column 컬럼명  ;

-- 테이블명 변경
alter table 변경전 테이블명 rename to 변경 후 테이블명 ;

-- 컬럼명 변경
alter table 테이블명 rename column 기존컬럼명 to 새로사용할컬럼명 ;

-- 테이블 삭제
drop table 테이블명 ;

-- 스퀸스 삭제
drop sequence 유저명.시퀀스명 ;

-- 스퀸스 생성
create sequence 유저명.시퀀스명
       increment by 1   -- 증가값
       start with 701     -- 시작값
       MINVALUE 701   -- 최소값
       MAXVALUE 799  -- 최대값
       cache 20           -- 메모리
       cycle ;
             
-- 스퀸스 MAX값 변경      
ALTER SEQUENCE 유저명.시퀀스명 MAXVALUE 99999;    

-- FK 생성시 enable validate 로 변경할때
alter table 테이블명 enable validate constraint  FK명 ;

--FK 생성
ALTER TABLE 자식테이블명 ADD (
  CONSTRAINT  FK명  FOREIGN KEY (컬럼명)
    REFERENCES 부모테이블명 (컬럼명));

--FK 삭제
alter table 자식테이블명 DROP CONSTRAINTS  FK명 ;

--인덱스 추가
CREATE INDEX 인덱스명 ON 테이블명
 (컬럼명)
tablespace 테이블스페이스명
storage(initial 1M next 1M pctincrease 0 maxextents unlimited freelists 10 freelist groups 2);

-- 인덱스 삭제
drop index 인덱스명 ;

-- 인덱스명 변경
alter index 변경전인덱스명 rename TO 변경후인덱스명 ;

-- pk 리빌드
alter index  PK명  rebuild ;

-- PK 변경
select * from dba_segments where segment_name like '%PK명%';

alter table 테이블명 drop primary key;
drop index PK명 ;

alter table 테이블명  add
   CONSTRAINT PK명  PRIMARY KEY (컬럼명)
   using index
   tablespace 테이블스페이스명
   storage( initial 1M next 1M maxextents unlimited pctincrease 0 freelists 10 freelist groups 2 );

-- PK 생성
ALTER TABLE 테이블명  add
   CONSTRAINT  PK명  PRIMARY KEY (컬럼명)
      using index
   tablespace 테이블스페이스명
   storage( initial 1M next 1M maxextents unlimited pctincrease 0 freelists 10 freelist groups 2 )
;
-- 주석 보기
-- 테이블 주석
dba_tab_comments
-- 컬럼 주석
dba_col_comments

1. UNIX 1회성 작업 예약하기
$>at now + 1 minute 또는 minute[s], hour[s], day[s], week[s], month[s], year[s]
내용입력
Ctrl + d 로 입력 종료
$>

2. 예약된 작업 보기
$>atq

3.예약된 작업 취소하기
작업번호는 atq로 조회된 값을 복사.
$>at -r 작업번호

1.GPS 기능이 있는 경우만 보험료 할인이 되는 보험사가 있으므로 보험사 확인 필요

2.

이를 증명하기라도 하듯 현재 약 130여개 이상(업계 추산. 최대 300여개)의 차량용 블랙박스 제조사에서 약 300여개 이상의 제품을 출시해 치열한 시장경쟁을 펼치고 있다. 차량용 블랙박스의 경우, 사고시 사고 경위나 차량의 번호판 등을 잘 식별할 수 있도록 풀 HD(해상도 1920×1080)나 HD급(해상도 1280×720)의 화질을 대부분 구현하고 있다. 아울러 음성안내, GPS 연결 등 고객의 요구에 맞춘 다양한 기능을 지원하고 있다.

1280×720 HD급 고화질 해상도를 자랑하는 ‘아이나비 블랙 G100’은 200만 화소의 이미지 센서와 고사양 렌즈를 채용했고, 후방 카메라 연결이 가능한 2채널 기능을 지원한다. 전용 후방카메라를 AV-IN 포트에 연결하면 후방 영상을 동시에 녹화할 수 있어 전방과 후방의 상황을 생생하게 기록할 수 있다. 또한 전용 외장 GPS를 ‘아이나비 BLACK G100’에 연결하면 차량의 정확한 위치 및 속도 정보를 기록할 수 있어 전-후방 주행 영상과 함께 위치, 속도, 경로 등의 정보를 함께 확인할 수 있다.

‘음성안내 기능’은 시스템 시작 및 종료, 녹화 시작 및 종료 등 기본 동작 안내는 물론 GPS연결, 메모리 상태, 에러 발생 등 다양한 상태에 대해 음성 안내가 제공된다. 대각 기준 최대 140도의 촬영 각도와 초당 최대 30프레임을 지원해 넓은 범위를 왜곡과 끊김없이 녹화할 수 있다. 영상 파일은 AVI형식으로 마이크로SD 메모리에 저장되기 때문에 편리하게 확인이 가능하다. 또한 AV-OUT 포트 지원으로 내비게이션 등 외부기기를 연결해 녹화중인 영상을 실시간으로 확인할 수 있다.

‘아이나비 BLACK G100’은 일반 충전 배터리보다 수명 및 안전성이 높은 슈퍼캡을 채용한 점이 특징이다. 슈퍼캡은 사고 등으로 전원이 차단될 경우, 녹화 중이던 영상을 안전하게 저장할 수 있도록 전력을 공급한다. 녹화 방식은 상시 녹화, 이벤트(충격) 녹화, 수동 녹화, 주차 녹화 등 사용자 환경에 맞춰 다양한 녹화 방식을 선택할 수 있다. 특히 자동 주차모드를 통해 차량이 주행을 마치면 별도의 버튼 조작없이 자동으로 주차 상태를 감지해 주차 녹화모드로 전환된다. 가격 8GB 메모리 28만9000원, 16GB 메모리 32만 9000원.

파인디지털 ‘CR-300HD’

‘CR-300HD’는 1초당 30프레임의 풀 HD(해상도 1920×1080) 녹화 모드를 제공한다. 이는 사고 발생시 중요한 요소인 교통 신호, 안내 표지판, 자동차 번호판 등을 선명하게 촬영해 정확한 식별을 가능케 한다. 또한 기존 사용자들의 다양한 의견을 수렴해 편의 기능을 보강했다. 조작버튼을 5개로 늘리면서 카메라 촬영, 긴급녹화, 주/정차 모드 전환, 음성녹음 On/Off 전환 등의 기능을 손쉽게 사용할 수 있도록 했다.

초당 녹화 프레임 수, 촬영 모드별 메모리 용량을 사용자가 원하는 대로 조정할 수 있도록 해 고해상도 녹화에서도 장시간 녹화도 가능하다. 리튬-폴리머 내장배터리를 채택해 사고발생시 차량 전원이 갑자기 차단되더라도, 녹화 중이던 영상을 안전하게 저장해 사고영상이 누락되는 것을 방지했다.
촬영화각은 대각 129도, 수직각 63도, 수평각 112도(KS표준규격)에 맞춰 측정한 결과이며, 왜곡이 최소화된 16:9 화면비율의 광각 영상으로 촬영되기 때문에 사고발생 상황을 더욱 정확하게 파악할 수 있다. 영상저장 장치인 메모리카드의 경우, 고품질의 16GB 마이크로 SD카드를 채택함으로써 보다 안정적인 저장을 구현했으며, PC에서 확인 시, 파인뷰 전용뷰어를 활용함으로써 영상의 확대, 보정이 가능해졌다. 파인뷰만의 차별화 포인트인 디자인의 경우 블랙&골드 색상으로 변경함으로써 보다 고급스러운 디자인으로 변신했다. 가격 29만 5000원.

큐알온텍 ‘LK-5100HD’

‘LK-5100HD’는 1280×720 HD 해상도, 초당 보여주는 화면 숫자는 24프레임이다. UV필터와 CPL필터의 결합으로 더욱 선명한 영상을 제공한다. UV 필터의 경우 빛에 대한 간섭을 최소화하고 렌즈를 보호하는 역할을 담당하며 옵션으로 제공하는 CPL필터의 경우 난반사를 줄여 번호판, 신호등 등 사건의 주요 증거가 난반사에 의해 가려지지 않도록 미연에 방지 할 수 있다.

주차모드시 블랙박스에 내장된 시큐리티 LED가 밝게 불빛을 보여줘 블랙박스가 장착된 차량임을 암시해 주차테러 및 사고를 미연에 방지할 수 있다. 여름에는 덥고 겨울에는 추운 외부 환경에서 온도에 대한 내구성이 없다면 오동작을 일으킬 수 있지만 ‘LK-5100HD’의 경우 광범위한 온도에서 작동 가능하기 때문에 오작동 확률이 타 제품보다 낮다. 가격 11만 9000원.

현대모비스 ‘HDR-1700’

‘HDR-1700’ 제품은 1280×720 HD 전용 렌즈와 이미지 센서를 탑재해 고화질의 녹화영상을 제공한다. 또한 녹화된 영상은 차량용 내비게이션을 통해 직접 재생이 가능하다. 이 제품은 -30℃의 저온과 +75℃ 고온 환경에서도 정상 작동이 가능한 내구성은 물론 습도, 진동, 충격 등의 각종 신뢰성 테스트를 통과해 제품의 품질을 확보했다.

만약 카메라 기능이 정상 작동되지 않으면 경고해 주는 장치도 있다. 이는 소프트웨어 또는 기계에 에러가 발생해 영상이 저장되지 않거나 카메라 영상 신호에 에러가 발생해 촬영이 되지 않으면 운전자에게 경고해 주는 것이다. 또한 블랙박스 본체에 탑재된 핫키(HOT KEY) 기능을 사용해 간단한 버튼 동작으로 SD카드 메모리 포맷, MIC 온/오프, 스피커 온/오프 등의 주요 기능을 손쉽게 조작할 수 있다.

현대모비스는 콘덴서의 일종인 ‘슈퍼캡’이라는 부품을 사용해 고온의 환경에서의 위험성 방지와 차량으로부터의 전원이 완전히 차단돼도 약 15초간의 영상을 기록할 수 있는 안정성을 확보했다. 가격 23만원(8GB).

TG삼보 ‘TG드림샷’

‘TG드림샷’은 1920×1080 픽셀의 풀 HD화질을 지원해 주간은 물론 야간주행에서도 보다 선명한 영상을 기록할 수 있다. 초당 30프레임의 영상을 제공하는 ‘TG드림샷’은 빠른 속도로 운행하는 자동차의 특성에 맞는 최적의 프레임수로 끊김없는 부드러운 영상과 함께, 사고 발생 순간을 안전하게 저장할 수 있다.

또한 전용 뷰어를 통해 사용자 환경에 맞는 기능설정이 가능하며, 개인정보 보호를 위한 메모리카드 비밀번호 추가기능으로 타인에 의한 운행정보 노출을 사전에 방지할 수 있다. 전용뷰어 확대 기능으로 원거리에 위치한 번호판과 같은 디테일한 화면까지도 확대해 볼 수 있어 사고 당시 주변 상황을 정확히 살필 수 있다. 사고발생 시 영상 데이터가 자동 저장되고 이를 PC전용뷰어 썸네일 뷰 기능을 통해 정확한 분석을 하는데도 용이하다. 가격 8GB 19만 9000원, 16GB 27만 9000원, 32GB 33만 9000원.

코원시스템 ‘오토 캡슐'

‘오토 캡슐’은 동급 최대의 촬영 화각, HD 고화질 영상(1280×720) 녹화 기능이 특징이다. 200만 화소의 이미지 센서를 탑재해 초당 30프레임의 HD급 동영상을 촬영할 수 있으며, 150도의 넓은 시야각을 제공한다. 90도, 120도 등 촬영 각도 조절이 가능해 기존 제품으로 촬영이 어려웠던 측면 사고에도 만전을 기할 수 있다.

아울러 기본적인 상시 녹화, 수동 녹화 외에도 다양한 자동 녹화 기능을 지원하는 것도 장점이다. 고감도의 3축 가속도 센서를 탑재해 차량에 전해지는 미세한 충격까지 자동으로 저장하며 주차시에도 카메라가 차량 외부의 움직임을 인식, 해당 영상을 자동 녹화한다. 이 밖에 사고나 전원 이탈 등 비상시에 대비한 내장 배터리와 영상 출력 단자 등도 갖추고 있다. 기존 제품의 사각형을 탈피한 캡슐형태의 감각적인 디자인도 차별화되는 부분이다. 가격 8GB 18만 9000원, 16GB 22만 9000원.

차바이오앤디오스텍 ‘카이드록스 CD-3000’

‘카이드록스 CD-3000’은 전방 142.5도의 시원한 화각과 130만 화소의 고화질 영상으로 사각지대를 최소화해 운행 시 선명한 영상을 폭넓게 저장한다. 후방카메라에 소니 CCD센서를 채택해 어두운 환경에서도 또렷한 영상을 제공하며, 후방 130도의 화각을 포함해 전·후방 총 272.5도의 넓은 화각을 자랑한다. 여기에 내비게이션과의 연동성을 강화해 사고영상과 설정을 손쉽게 조작 할 수 있으며, 저장된 영상은 전용 PC뷰어 프로그램을 통해 정확한 정보를 제공 받을 수 있다.

내장 GPS로 구글 어스와 맵을 연동한 3차원 운행 경로뿐 아니라 AV 단자가 있는 내비게이션·TV와 연동해 영상 실시간 확인, 저장 영상 확인, 사용자 환경 설정 기능을 제공한다. 특히 분리형 외장 카메라를 연결해 후방 또는 실내 촬영까지 가능하다. 가격 4GB 22만 9000원, 8GB 24만 9000원, 16GB 29만 9000원.

하니웰 ‘HBB-200HD'

HD블랙박스 ‘HBB-200HD’는 산업용 CMOS 센서(1/3.2인치)를 장착해 동영상 노이즈가 적고 HD 해상도(1280×720)에서 30프레임을 지원한다. 또한 렌즈가 좌우로 180도 움직여 필요시 특정 부분 또는 차량 내부를 녹화할 수 있다. 운전 중 사고순간, 급제동, 급가속, 급회전 등 차량에 과도한 충격이 가해지는 경우 내장된 3축 가속도센서가 이를 감지해 해당 영상을 자동으로 이벤트 영상으로 별도 기록, 일정기간 보존한다. 내장 스피커를 통해 동작, 설정 상태를 음성으로 안내해 주기 때문에 초보자도 손쉽게 사용할 수 있다.

상시 전원 케이블을 사용할 경우, 주차 중 녹화 모드를 지원해 운행 중이 아닐 때도 차량을 안전하게 보호할 수 있다. 옵션으로 제공하는 GPS 모듈은 화면상으로 확인이 불가능 한 위치, 속도, 운행 방향 등을 뷰어에서 확인할 수 있다. 과열방지 기능을 내장해 내부 온도가 80℃를 넘으면 자동으로 작동이 중지되는 기능도 갖췄다. 가격 23만원.

이효정 기자 hyo@

출처-이코노미리뷰 원본링크

===============================================================

아래 이미지는 모델명만 보고 가격은 직접 확인하세요.

===============================================================

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

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

코드 인스펙션

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

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

인스펙션의 시기는 시스템이 개발되어 있는 시점인 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%에 육박할 경우도 있음) 리뷰어에 대한 스케쥴 배려가 필요하다.

요약

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

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

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

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

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

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

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

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

http://bcho.tistory.com/276

코드 리뷰 - 1. 코드 리뷰 기법들에 대한 소개

ALM/Task Management

들어가기에 앞서서.

소프트웨어의 품질을 보장하기 위한 활동은 테스팅, 일일 빌드, 프레임웍의 사용, 개발 패턴들 수 없이 많은 방법들이 있다. 그중에서 개인적으로 생각하건데,코드리뷰 만큼 적은 투자로 큰 효과를 얻을 수 있는 기법은 없는 것 같다. 이 문서에서는 코드리뷰에 대한 몇가지 기법에 대한 정리와 함께 적용 방법에 대해서 간단하게 소개해보고자 한다.

코드 리뷰의 시초는 Fagan에 의해서 소개된 코드 인스펙션에서 기인한다. 소프트웨어의 개발이 끝난후에, 전문 인스펙션팀이 정해진 프로세스와 패턴에 따라서 코드를 검증하고 Defect를 찾는 프로스를 코드 인스펙션이라고 한다.

코드 리뷰란, “코드를 실행하지 않고 사람이 검토하는 과정을 통하여 코드상에 숨어있는 잠재적인 결함(Defect)를 찾아내고 이를 개선하는 일련의 과정”을 정의한다. 테스팅의 범주에서는 정적인 분석에 속한다. Formal한 코드리뷰 기법일 수 록, Defect의 발견에 집중하고, 소프트웨어 개발 주기의 후반에 위치하지만, Lightweight한 코드 리뷰 기법은 Defect의 발견뿐만이 아니라, 같은 로직을 여러 관점에서 생각하는 아이디어 회의나, 주니어 개발자에게로의 지식 전달등의 부가적인 목적들도 함께 가지고 있다.

코드 리뷰 스펙트럼

코드 리뷰의 기법을 나누는 방법은 크게, 얼마나 정석적이고 프로세스적(정형성)이냐에 따라서 Formal/Lightweight 방법으로 나눌 수 있고, Offline에서 직접 커뮤니케이션을 하느냐? 또는 메신져,Email 이나 기타 자동화된 코드리뷰 도구를 사용하느냐에 따라 온라인 리뷰와 오프라인 리뷰로 나눌 수 있다.

먼저 정형성에 따라서 대표적인 리뷰 방법을 나열해보면 다음과 같다.

주) 코드리뷰 기법중에는Pair Programming이 종종 언급되고는 하지만, 본인의 사견상 엔터프라이즈 애플리케이션 개발에서 Pair Programming을 실제로 적용한다는 것은 매우 어렵다고 판단하기 때문에, 코드 리뷰 스펙트럼에서는 제외한다.

코드 인스펙션

코드리뷰 기법중에서 가장 정형화된 패턴의 기법이다.전문화된 코드리뷰팀이 시스템이 어느정도 구현된 단계에서 일정한 패턴을 가지고 코드를 분석한다.인스펙션팀은 크게 4가지 역할을 가지고 구성이 된다.

1. Moderator

는 인스펙션팀의 실제적인 메니져로 생각하면 된다. 인스펙션팀과 그 대상이 되는 코드를 작성한 개발팀간의 인터페이스를 담당하고 필요한 리소스와 인프라를 확보하는 작업을 한다.

또한 인스펙션에 대한 프로세스 정의와 산출물의 정리를 담당한다.

예를 들면, 인스펙션팀이 계정 업무를 인스펙션을 하다가 업무에 대한 지식이나 코드가 왜 이렇게 짜여져 있는지에 대한 자료가 필요하다면 Moderator가 요청하여 담당 개발자를 섭외하거나 소프트웨어 설계 문서등을 받아다가 인스펙션팀에 전달한다.

또는 인스펙션된 결과에 대해서 테스트가 필요할 때, 테스팅 환경을 확보하고 인원 (DBA나 벤더 엔지니어)을 섭외하는 것도 Moderator의 역할이다. 필요하다면 고객이나 개발자와 함께 인스펙션 미팅을 주선하고 주최하는 역할도 갖는다.

가장 중요한 역할중의 하나는 인스펙션이 언제 끝날 것인지 (Exit Criteria)를 정의하는 역할을 갖는다.

2. Reader

Reader는 각종 산출물들을 읽고, 인터뷰등을 통해서 전체 시스템을 이해하여 인스펙션팀이 어떤 흐름으로 인스펙션을 진행할지에 대한 방향을 지시하며, 시스템에 대해서 팀내에서 가장 많은 도메인 지식을 갖는 사람이다.

Reader는 시스템의 큰 흐름과 구조를 잘 이해하고 있어야 하고, 상황에 따라서 문제가 발생할 수 있는 지점을 미리 예측해낼 수 있어야 한다. 실제 인스펙션은 이 Reader의 방향성에 따라서 인스펙션을 진행하게 된다.

3. Designer/Coder

Designer나 Coder는 Reader가 지시한 방향에 따라서 코드를 검증하고 잠재적인 Defect의 발견 및 권장 수정 방안을 만들어 낸다.

4. Tester

Tester는 인스펙션이 진행중인 모듈에 대해서 테스트를 수행하고 Defect를 찾아내는 역할을 수행하며, 이외에 Designer나 Coder가 권장한 수정 코드안에 대한 검증과, 실제 업무 개발자가 수정해온 코드에 대한 검증 작업을 수행한다.

4가지 역할을 가지고 인스펙션은 다음 6단계로 진행된다.

1. Planning

전체 코드 인스펙션에 대한 계획을 수립한다. 기간, 대상, 종료 조건 (금액 기준, 목표 TPS를 성취하는지, 시간에 따른 종료 조건, 등등). 그리고 인스펙션 팀이 이때 SET UP이 된다.

2. Overview

이 단계에서는 인스펙션 팀에 시스템과 구성 제품등에 대한 교육이 이루어지고, 팀원간의 역할이 정의된다.

3. Preparation

Inspection을 하기 위한 사전 준비 단계로 각자의 역할별로 필요한 문서를 습득해서 이해하고 필요하다면 인터뷰도 진행한다. 또 이 단계에서는 필요에 따라서 Tool (테스팅 툴이나, profiler, Application Performance Monitoring 도구..)과 환경(독립된 테스트가 요구되는 경우 테스트 환경을 구축한다.)

4. Meeting (Inspection)

각자의 역할에 따라서 Inspection을 수행한다.Inspection을 통해서 결함을 발견하고, 모든 결함은 기록된다. 기록된 결함은 실업무 개발자에게 전달되어 FIX되도록 하고, 필요에 따라서는 권장 수정안을 전달하기도 한다.

5. Rework

보고된 Defect를 수정한다.

6. Follow-up

보고된 모든 Defect가 수정되었는지 확인한다.

팀리뷰

팀리뷰는 코드 인스펙션보다 좀 덜 정형화 되었지만 그래도 일정한 계획과 프로세스를 따른다.

코드 인스펙션 프로세스의 단계 (Planning ,Overview ,Preparation등의 사전 준비 단계는 생략된다.) 역할은 중복되거나 생략될 수 있는데, 발표자(Author)와 Moderator는 필수적으로 구성된다.

리뷰시간에는 발표자(코드를 만든 사람)가 코드에 대한 설명을 하고, 팀원은 결함이나 개선안을 찾는다.

Moderator는 리뷰의 주제를 선정하여 리뷰를 진행하고, 리뷰에서 나온 의견을 정리해서 Action Item으로 기록한다. 이 Action Item들은 프로젝트 관리자가 실제 프로젝트 Task로 관리해야 한다. (일정에 반영되어야 한다.)

Moderator는 프로젝트 관리자 (PM이나 PL)이 될 수도 있으나, 팀내에서 기술적인 실력이 가장 좋은 Senior 개발자가 그 역할을 맏는 것을 권장한다.

일주일에 한번정도 팀리뷰를 수행하는 것이 좋으며, 특정 모듈이나 기능이 완료되는 시점(Short Release) 시점에 수행을 하거나, 테스트 결과를 가지고 리뷰를 하는것도 좋은 방법이 된다.

필자의 경우 프로젝트를 수행할 때, 일주일에 한번 정도 팀리뷰를 진행하였으며, Short Release에 의해 완성된 부분이나 Risk가 비교적 큰 부분이라고 판단하는 부분에 대해서 팀리뷰를 진행하도록 개발자에게 지시 하였다.

리뷰 과정에서 나온 의견은 팀 Wiki 페이지에 “코드 리뷰 결과” 라는 분류를 따로 만들어서 관리하였고, 각 의견은 TASK로 생성되어 스케쥴에 포함되었다.

<그림. 팀리뷰 리포트>

웍쓰루 (Walkthrough)

웍쓰루는 단체로 하는 코드 리뷰 기법중에서 가장 비정형적인 방법중에 하나이다. 발표자가 리뷰의 주제와 시간을 정해서 발표를 하고 동료들로부터 의견이나 아이디어를 듣는 시간을 갖는다.

주로 사례에 대한 정보 공유나, 아이디어 수집을 위해서 사용될 수 있다.

개발을 위한 프로세스에서 보다는 “Bug 사례에 대한 회의”와 같은 정보 공유성격에 유리하다.

유일하게 발표자만이 리뷰를 주관하고 발표하는 역할을 가지며, 다른 참여인원들은 아무런 책임이나 역할을 가지지 않고 자유롭게 의견을 개진한다.

웍쓰루는 정기적으로 (주일에 한번) 진행할 수 도 있으며, 또는 정보공유나 아이디어 수집이 필요할 경우 비정기적으로도 진행할 수 있다. (정기적으로 진행하는 것이 참여율이나 집중도가 더 높다.)

Peer Review or Over the shoulder review

피어리뷰나 Over the shoulder Review는 2~3명 (주로 2명)이 진행하는 코드 리뷰의 형태이다.

코드의 작성자가 모니터를 보면서 코드를 설명하고 다른 한사람이 설명을 들으면서 아이디어를 제안하거나 Defect를 발견하는 방법이다.

사전 준비등이 거의 필요없고, 필요할때 마다 자주 사용할 수 있는 리뷰 방법이다.

주로 Senior 개발자(사수)가 Junior 개발자를 멘토링할 때 사용할 수 있으며, Junior 개발자에 대한 교육과 함께, Junior 개발자가 양산한 코드에 대한 품질을 관리할 수 있다.

그러나 이 기법은 Senior 개발자의 리뷰 역량에 따라서 결과물의 품질이 달라질 수 있고, Senior개발자의 시간 투여량이 많은 만큼. Senior 개발자의 참여도가 떨어질 수 있다. (형식적으로 될 수 있다. )그래서 프로젝트 관리 관점에서 Peer Review 에 대해서도 프로젝트 스케쥴상의 Task로 잡아주고, 하나의 독립된 업무로서 시간과 노력을 투자할 수 있도록 해야 한다.

실제로 예전 프로젝트에서 신입 사원에게 비교적 난이도가 높은 모듈의 개발을 시켜야할 상황이 있었고, 그때 이 Peer Review를 진행하도록 하였다. 결과적으로 만족할만한 품질을 얻었지만, Senior 개발자에게 Review에 대해서 Task를 지정하고 스케쥴링을 하였음에도 불구하고, Senior 개발자에게는 결코 적지 않은 워크로드가 되었던 경험이 있기 때문에, 팀원간의 실력 편차와 난이도에 따른 시간 배분과 함께, 경험적 (3~4일 해보면 실제 작업량에 대한 예측이 좀 더 정교해진다. )인 작업량 측정이 필요하다.

Passaround

코드리뷰 스펙트럼에는 포함시키지 않았지만 사용되는 경우가 있어서 소개한다.

Passaround는 번역하자면 돌려보기이다. 온라인 보다는 오프라인 위주로 진행되는 리뷰인데, 작성자가 리뷰를 할 부분을 메일이나 시스템을 통해서 등록하면, 참석자들이 메일을 통해서 각자의 의견을 개진하는 방식이다. 특정 장소에 모여서 같은 시간에 진행해야 하는 기존의 리뷰 방식과는 달리 시간과 장소에 구애를 받지 않는 방식으로, 리모트에서 작업하는 팀의 경우 유리한 리뷰 방식이지만 반대로 Ownership이 애매하여 원하는 결과가 나오지 않는 경우가 많다. 또한 실시간이 아닌 비동기적인 커뮤니케이션으로 인해서 커뮤니케이션 속도가 매우 느리다는 단점도 가지고 있다.

이를 방지하기 위해서는 참석자들의 업무 역할에 코드 리뷰라는 역할이 명시적으로 지정되어야 한다.

필자가 일했던 글로벌 회사의 경우에는 버그 수정이나 제품의 기능 개선의 경우 개발팀에서 버그 수정과 개선만을 맏는 개발자가 개발팀에 속해 있었기 때문에 원할한 Passaround 리뷰가 가능했고, 이슈(버그) 트랙킹 시스템 (Atlassian社 JIRA와 같은)과 소스 코드 Viewing system (Atlassian社 의 Fisheye)이 많은 도움이 되었다.

지금까지 간단하게나마 코드 리뷰의 기법에 대해서 살펴보았다. Formal한 리뷰 (코드 인스펙션..)등에 대한 설명이 많은 것은, 꼭 Formal한 리뷰가 좋아서라기 보다는 정형화 되어 있기 때문에 그만큼 프로세스에 대한 설명이 많이 필요하기 때문이다.

회사의 성격 (SI,게임,임베디드,인하우스개발, 오픈소스 등)이나 팀의 구조나 성숙도에 따라서 리뷰의 기법은 변형되어 적용되어야 한다.