Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

소스리딩워크샵 - NHN NEXT

1,408 views

Published on

Published in: Technology

소스리딩워크샵 - NHN NEXT

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

×