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