2. 오늘의 목표와 일정
• 오늘 워크샵의 목표:
– 좋은 소스가 무엇인지를 알고,
멋진 소스를 만들 지속적 의지를 불사른다.
– 소스 리뷰의 중요성을 이해하고,
품질을 높이는 한가지 방법을 익힌다.
• Source Reading에 관한 Quick 복습 (20분)
• 예제 Source Reading 결과 설명 (15분)
• 조편성
• 실제 Source Reading (40분)
• 조별 발표 (25분)
• 기념 촬영
• 해산
3. 우리의 개발 방법론 ?
• FDD (Faith-Driven Development) ?
– By Twitter ID: @codinghorror
C Java PHP
4. 무엇이 문제인가 ?
• Source Code : 관리하기가 힘들다 !
• 아무도 있던 코드를 가지고 일하기를 원하지 않는다.
• 겨우 도는데, 자주 수정하다 보니 거의 걸레 수준이다.
• 이 코드를 작성한 엔지니어는 이제 다른 회사에 있다.
• 프로그래머마다 개성이 강하다.
5. 소스를 보면 (1)
• 어떤 함수는 1500 line 이상인 것도 있다.
• 한 소스 화일에서도 뭔가 일관성이 발견되지 않는다.
• 다음과 같은 global 변수 이름이 자주 발견된다.
– db, rp, ap, mt, …
– xx, ii, jj, i, j, …
– the (search가 안 된다. 워낙 “the”가 많기 때문에)
– ll (숫자 ‘1’과 문자 ‘l’은 소스에서 구분이 잘 안됨)
• 설명이 없는 magic 상수가 많이 발견된다.
– for (i = 0; i < 17; i++) …
• 표준 함수가 있는데, 같은 일을 하는 함수가 만들어져 있다.
– 특히 string 관련 함수, sort, search, …
• … 정말 그렇다 !
6. 소스를 보면 (2)
• 함수들이 간격 없이 선언되어 앞,뒤 구분이 어렵다.
• 함수 및 변수 이름에 일관성이 없다.
– 어떤 건 소문자, 어떤 건 대문자, 어떤 건 mix
– 부적절한 약어, 상징어 사용
• 편집에 일관성이 없다.
– Indentation, {, } 의 위치
• 변수, 함수, 코드를 설명하는 코멘트가 거의 없다.
• 가끔은 이런 코멘트도 발견된다.
– /* ooops !, what can I do ? */
• 모든 함수는 에러가 안 난다는 굳은 믿음이 있다.
• 설명 없이 comment-out된 코드가 있다.
• malloc-free, open-close, lock-unlock 짝이 안 맞는다.
• … 진짜 문제다 !
7. 코딩의 자세 .
• 최적화는 뒤로 미루자.
– 일단 예쁜 코드로 돌게 하는 것이 중요
– 설계 단계에서 구조적인 최적화를 고민하고
– 시험 후, 성능을 평가한 뒤 단계별로 최적화
• Profiling 후 가장 키가 큰 ‘한 놈’만 패자
• 읽기 어려운 코드는 Reuse도 하지 말자.
– 읽기 어려우면 신뢰도 안가고
– 디버깅도 어렵다.
• 있는 디버거를 꼭 사용하자.
– printf()는 기본적으로 모니터링 수단
• 모든 다른 가능성이 없을 때, 디버깅 용도로 사용
– Trial and Error로는 문제의 본질에 접근할 수 없다.
8. 코딩의 자세 ..
• Warning은 미래의 버그
– Compiler의 warning level을 최고로 !
– 모든 warning을 제거하자.
• 코딩의 생산성을 생각하자.
– 모드 디렉토리 구조, 파일, 변수 이름은 예측 가능하게
– Editor의 Search 기능 이용을 용이하게
• 함수, 변수, 키워드 이름 뒤에는 공백
– Build/Install/Run 과정의 생산성도 생각하자
• 5초를 줄일 수 있다면, 1시간 투자도 아깝지 않다.
• Hot-Key, 툴바, Batch, …
• 문법 상 되는 것도 오해의 소지가 있다면 쓰지 말자.
• 공짜로 제공되는 걸 쓰자.. Eclipse의 <Control-Shift-F>
9. 코딩의 자세 …
• 컴파일러는 똘똘하다는 확신을 가지자.
– 컴파일러는 “천재”들이 만든다.
– 예쁘게 짜면, 나머지(최적화)는 컴파일러가 한다.
– 컴파일러는 진짜로 거의 버그가 없다.
• 컴파일러 매뉴얼을 읽자.
– 같은 코드에 대한 컴파일 결과가 다를 수 있다.
• 그런 코드는 만들지 말자.
– 컴파일러 옵션 확인
• command line option
• #pragma
– 표준 (+ 특정 컴파일러) 라이브러리 매뉴얼 (man page)
– 사용하는 Framework, Platform에 따른 API 매뉴얼
11. 회사들은 ?
• Style Guide (coding convention)
– 어떤 회사는 대외비 ???
– https://code.google.com/p/google-styleguide/
• 각종 언어의 style guide, cpplint
– Linux: ./Documentation/CodingStyle
– http://en.wikipedia.org/wiki/Coding_conventions
– 표준 : MISRA C (자동차 업계), …
• Review tool
– Gerrit : git 과 함께 동작, review & comment
– http://en.wikipedia.org/wiki/List_of_tools_for_code_review
• Static Code Analysis Tools
– 모든 정적 분석 도구 – 역시 위키피디아..
http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
– 주요 무료 정적 분석 도구를 정리해놓은 사이트
http://cafe.daum.net/communhwa/C0Sv/19?docid=1NApSC0Sv192011
0302105229
12. 정리하면…
• 매뉴얼을 읽자.
– Compiler Manual (Compiler, Linker option)
– Reference Manual (API Manual)
– Coding Convention
• Source Reading !!!
– 소스와 문서를 종이에 출력하여 찬찬히 읽는다.
• Compiler
– Warning Message Level을 최고로 높인다.
– 모든 Warning Message를 없앤다.
• Tools 과 문서
– 설계를 도와주는 모델링 도구 그리고 설계 문서
– 소스를 잘 보여주는 도구
– Code Review를 지원하는 도구
– 소스의 세부적인 문제, 프로젝트 전체 소스를 정적 분석 (Static Analysis) 하는 도구
14. (함수 이름)
( perror() 사용 )
(변수 이름)
(! ==NULL, 띄어쓰기, 줄 바꿈)
(인자 이름, 함수 이름 )
(함수이름)
(이걸 함수로 만들 이유가 있을까 ?)
(comment 필요성?)
( return NULL; 사용 – caller에게 에러를 알림)
(띄어쓰기 ‘if(‘ ‘if (‘ )
(1st, 2nd, 3rd, nth line %d) (file 번호를 두 번?)
(MAX_BUF의 크기?)
(void ? 에러 나면 ?)
(띄어쓰기)
(줄 띄움)
띄어쓰기, 줄 바꿈, 줄 띄움은
<Ctrl-Shift-F>가 해결
15. 소스 리딩 진행
• 3인(4인) 1조로 합니다.
• 한 명이 진행을 합니다.
– 한 줄씩 차례로..
– 라인 번호를 call 하고 문제를 말하라고 합니다.
• 모든 조원이 해당 줄과 연관된 문제를 말합니다.
– 사소한 것부터 혹시 가능하면 중대한 것 까지
• 프로그램 스타일 (convention)도 보고
• 가능하면 로직도 보고, 프로그램 전체에 대한 것도 보고
– 다른 라인과 연계한 결과까지 말을 합니다.
• Comment도 봅니다. (코멘트의 문법, 철자 틀린 것 까지)
– 모든 내용을 Inspection sheet에 기록합니다.
• 편하게 적습니다. (줄 번호, 문제, 심각성)
• 한 명이 결과 발표를 합니다.
– 라인 번호와 문제점(, 어떻게 고쳐야 할 지)를 이야기합니다.
16. 문제의 위치
(사소한 것까지)
결함의 내용 심각성(H,M,L)
• 컴파일해서, 딱 한번 돌려보고 Reading
• 생산성 안오르는 월 오후, 금요일 늦게 피자 먹으면서 팀 리뷰
• 컴퓨터는 오직 리뷰 결과 기록용으로만 사용
(코드 리뷰하면서 수정하기 시작하면 망함)
• 반드시 전체 문제 개수를 적어서 기록
(얼마나 개선되고 있는지 Monitoring)
1 함수 이름 ‘opfl()’ 후짐 open_file() M
