Successfully reported this slideshow.
Your SlideShare is downloading. ×

DebugIt/chapter1~4

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 89 Ad
Advertisement

More Related Content

Slideshows for you (20)

Advertisement

DebugIt/chapter1~4

  1. 1. Debug It!<br />실용주의 디버깅<br />아꿈사<br />우정권<br />
  2. 2. 문제의 핵심<br />구조적 접근<br />재현<br />진단<br />수정<br />반영<br />
  3. 3. 문제의 핵심<br />구조적 접근<br />재현<br />진단<br />수정<br />반영<br />반복 검증된 디버깅 방법을 보자<br />은탄환은 아니지만<br />효과적으로 핵심에<br />다가설 수 있다<br />
  4. 4. 구조적 접근<br />디버깅<br />경험주의 접근법<br />핵심 디버깅 과정<br />중요한 일부터<br />실천하기<br />
  5. 5. 구조적 접근<br />디버깅<br />경험주의 접근법<br />핵심 디버깅 과정<br />중요한 일부터<br />실천하기<br />디버깅은<br />버그를 없애는 것<br />그 이상이다!<br />
  6. 6. 효과적인 디버깅 단계<br />이상 작동 원인 분석<br />문제 수정<br />회귀 방지<br />품질 유지, 향상<br />재발 방지<br />문제를 없애는 것은 디버깅의 여러 목표 중 하나일 뿐!<br />
  7. 7. 근본 원인 찾아내기<br />무엇보다 중요<br />이해 하는 게 전부<br />근본 원인의 진단 없이 수정<br />회귀 발생<br />해결 되지 않은 문제를 숨긴다<br />흑마술 프로그래밍<br />우연에 맡기는 프로그래밍<br />
  8. 8. 구조적 접근<br />디버깅<br />경험주의 접근법<br />핵심 디버깅 과정<br />중요한 일부터<br />실천하기<br />
  9. 9. 경험주의 접근법<br />이론, 논리 보다 관찰, 경험에 기반<br /> - 실험 과정 작성<br /> -> 작동 관찰<br /> -> 결과 확인<br />문제를 찾는데 효율적<br />디버깅 중인 소프트웨어야 말로 어떻게 돌아가고 있는지를 보여줄 가장 강력한 도구<br />
  10. 10. 소프트웨어의 결정적 성질<br />현재 상태에 따라 다음 상태가 완전하게 결정<br />자동차 엔진을 순간적으로 멈추고 살펴 볼 수 있는 것과 다를 바 없다<br />그래서경험주의 접근법이 디버깅에 강력한 것이다.<br />소프트웨어는 굉장하다<br />
  11. 11. 구조적 접근<br />디버깅<br />경험주의 접근법<br />핵심 디버깅 과정<br />중요한 일부터<br />실천하기<br />
  12. 12. 핵심 디버깅 과정<br />재현<br />문제를 재현하는 쉽고 신뢰 있는 방법<br />진단<br />버그 발생 원인을 찾을 때까지 가설 & 실험으로<br />테스트<br />수정<br />코드 수정에 대한 설계 및 구현<br />회귀 방지 및 품질 유지, 향상<br />반영<br />버그에서 교훈 얻기, 재발 방지<br />
  13. 13. 디버깅 과정에 대한 다른 관점<br />TRAFFIC<br />Track – 문제점 추적<br />Reproduce – 재현<br />Automate – 자동화, 단순화<br />Find – 감염원 찾기<br />Focus – 감염원에 집중<br />Isolate – 감염 사슬을 격리<br />Correct – 결함을 정정<br />
  14. 14. 비교<br />아까 반복 검증된 디버깅 방법을 본다 그랬음<br />
  15. 15. 디버깅은 반복 과정!<br />재현<br />진단<br />수정<br />반영<br />새로 알게 된 정보를 바탕으로 이전 단계를 더 편하게 만들 수 있다<br />
  16. 16. 구조적 접근<br />디버깅<br />경험주의 접근법<br />핵심 디버깅 과정<br />중요한 일부터<br />실천하기<br />
  17. 17. 먼저 할 일이 있다!<br />무엇을 찾으려는지 알고 있나?<br />어떤 일이 발생하고 있는가<br />어떤 일이 벌어져야 하는가<br />버그리포트도 틀릴 수 있다 (버그가 아닌 명세)<br />명확하지 않다면 아무런 변경도 하지 마라<br />제대로 돌아가던 것을 틀리게 수정하기<br />맞는걸 틀리게 수정한 예)<br />한번에 한 문제만<br />간단한 것부터 살펴보기<br />제대로 돌아가던 거라면 날로 먹은 기분!<br />
  18. 18. 먼저 할 일이 있다!<br />무엇을 찾으려는지 알고 있나?<br />한번에 한 문제만<br />유혹에 넘어가지 말자<br />다른 버그에 영향을 줄 수 없게<br />간단한 것부터 살펴보기<br />흙탕물을 만들지 않더라도 디버깅은 이미 충분히어렵다<br />
  19. 19. 먼저 할 일이 있다!<br />무엇을 찾으려는지 알고 있나?<br />한번에 한 문제만<br />간단한 것부터 살펴보기<br /> Not Invented Here (이건 내가 만든게 아니야) 증후군<br />일단 한번 물어보자<br />저비용 고 효율<br />안 물어봐서 삽질 한 예)<br />
  20. 20. 구조적 접근<br />디버깅<br />경험주의 접근법<br />핵심 디버깅 과정<br />중요한 일부터<br />실천하기<br />
  21. 21. 실천하기<br />SW의 이상 작동 원인 알기<br />문제 고치기<br />다른 부분 깨뜨리지 않기<br />품질 유지,향상 시키기<br />재발을 막기<br />한번에 한 문제만 해결하기<br />무엇을 찾고 있는지 정확하게 알기<br />간단한 것부터 먼저 살피기<br />
  22. 22. 문제의 핵심<br />구조적 접근<br />재현<br />진단<br />수정<br />반영<br />재현을 잘하기 위해 필요한 것들을 알아보자<br />
  23. 23. 재현<br />재현<br />소프트웨어 제어<br />환경제어<br />입력제어<br />재현 방법 다듬기<br />정말로 재현할 수 없다면?<br />실천<br />고민하기 전에 재현부터!<br />
  24. 24. No 재현, No 진도<br />SW가 실행되는 모습을 살펴볼 수 없다<br /> (경험주의 적용할 수 없다)<br />이론을 증명 할 수 없다<br />문제가 수정됐는지 확인할 수 없다<br />
  25. 25. 분명한 것부터<br />버그리포트부터 따라 해보자<br />정보 부족으로 돌려 보내지 말고 일단 따라 해본다<br />간단하다면<br />복잡하다면<br />관련 자료를 모두<br /> 모을 필요가 있다 <br />버그 보고는 정확한 과학이 못 된다<br />우리는 우연한 것들을 디버깅하느라 시간을 소비할 여유가 없다<br />잘되면 정보를 더 <br />요청할 필요가 없다<br />안되면? 뭐 그렇게 <br />시간낭비 한 것도 아니다<br />So Chic<br />So Cool<br />
  26. 26. 재현<br />재현<br />소프트웨어 제어<br />환경제어<br />입력제어<br />재현 방법 다듬기<br />정말로 재현할 수 없다면?<br />실천<br />성공적인 재현은 제어에 달려 있다<br />
  27. 27. 소프트웨어 제어<br />사용자가 실행한 버전을 만들자<br />컴파일러 설정, 라이브러리, 서드파티 코드, 빌드 순서<br />환경 제어<br />실행 환경을 비슷하게<br />OS, 브라우저,하드웨어,etc=>가상머신<br />소프트웨어의 작동에 영향을 미칠 수 있는 것이라면 무엇이든 환경!<br />
  28. 28. 입력 제어<br />어떤 입력을 받았는지 파악한 후 재생<br />버그리포트에 적혀 있다면 lucky<br />정보가 부족하다면<br />추론<br />기록<br />
  29. 29. 입력 추론하기<br />거꾸로 찾아가기<br />탐색하기<br />경계 값 분석(+/- , 10,11 …)<br />분기 커버리지<br />다른 코드 분기를 실행 할 입력 값<br />에러 상태 만들기<br />임의성 도입하기<br />퍼지 프로그램?<br />
  30. 30. 퍼징?<br />출처 : http://twtpoll.com/r/mwilg5<br />
  31. 31. Fuzzy[fʌ́zi]<br />4. 유연성 있는, 경계가 모호한<br />퍼지 테스팅<br />임의의 데이터를 프로그램에 입력<br />퍼지 생성기<br />위 과정을 자동화<br />생성한 입력은 얼마든지 다시 생성 가능<br />문제가 발생 했을 때 원하는 대로 재현<br />
  32. 32. 입력 기록하기<br />printf를 전략적으로 호출<br />내부로그<br />로그 프레임웍<br />손쉬운 on/off<br />로그 수준, 양 조절<br />추가 정보<br />분석 툴<br />
  33. 33. Import java.util.loggin.Logger<br />private static final Logger log=<br />Logger.getLogger(Dispatcher.class.getName());<br />Public static void dispatchLoop(){<br /> while(true){<br /> try{<br /> long start = System.currentTimeMillis();<br />log.fine(“Processing item:”+item);<br />item.process();<br /> long timeInMillis =<br />System.currentTimeMillis() – start;<br />log.info(“Processing”+item+”took”+<br />timeInMillis + “ms”);<br /> }catch(Exception e){<br />log.severe(“Unhandled exception: “+e);<br />}}}}}<br />
  34. 34. 코드에 (디버깅에 필요한)로그 남기기<br />장점<br />문제가 생겼을 때 빠르게 찾을 수 있다<br />단점<br />애매한 코드<br />최신 코드를 반영하지 않는 문제<br />실용주의적으로 접근<br />정말 도움이 된다면 남기자<br />항상최신 코드를 반영하도록 한다<br />AOP 도 있다<br />
  35. 35. 외부 로그<br />네트워크 뿐 아니라 API 도 가능<br />클라이언트<br />서버<br />로깅프락시<br />클라이언트<br />서버<br />로그 파일<br />
  36. 36. 부하와 스트레스<br />특정 환경에서만 발생한다면<br />동시요청<br />대규모데이터<br />네트워크 트래픽<br />메모리 제한<br />환경 만들기<br />로그 재생 방법<br />부하 테스트 도구<br />클라우드 컴퓨팅 플랫폼<br />
  37. 37. 재현<br />재현<br />소프트웨어 제어<br />환경제어<br />입력제어<br />재현 방법 다듬기<br />정말로 재현할 수 없다면?<br />실천<br />재현 방법을 신뢰할 수 있게,편리하게<br />
  38. 38. 피드백 루프 최소화<br />실험 주기를 빠르게<br />수정-컴파일-실행-재현 주기<br />많은 실험을 빠르게 => 철저한 이해<br />주기가 짧을 수록 적절한 피드백<br />(TDD 동영상 참조)<br />주기가 길수록 여러 가지를 동시에 손대고 싶은 유혹이 온다<br />흙탕물을 만들지 않더라도 디버깅은 이미 충분히어렵다<br />
  39. 39. 단순하게<br />불필요한 부분을 제거한다<br />직감으로 찾기<br />비직관적인 방법<br />이진 검색<br />자동화 실제로 본적은 없지만 멋있어!<br />재현 방법 다듬기는 진단 과정 내내 고민할 문제! 한번 하고 말일이 아니다<br />
  40. 40. 비결정적인 버그를 결정적으로<br />소프트웨어의 멋진 점 : 결정적<br />시작 상태가 같다면 결과도 같다<br />그런대 비결정성이 생겨요<br />내부 상태를 초기화 하지 않음<br />외부 시스템과 상호작용<br />일부러 넣은 임의성<br />다중 스레드<br />
  41. 41. 초기화 없이 사용<br />최신 OS 나 언어 에서는 자동 초기화<br /> C/C++ 프로그래머는 주의하세요<br />초기화로 인한 비결정성이 생긴다면<br />디버깅용 메모리 할당기<br />메모리 검증기<br /> VS 의 /GZ 옵션<br />
  42. 42. 외부 시스템과 상호작용<br />제어할 수 있는 것으로 교체하자<br />테스트 대역<br />임의성<br />의사 난수의시드 값 을 제어한다<br />
  43. 43. 다중 스레드<br />어렵다<br />문맥전환을 제어할 방법을 찾는다<br />sleep()<br />어렵다<br />재현이나 진단에는 좋다<br />어렵다<br />버그 수정 방법으로는 좋지 않다<br />어렵다<br />
  44. 44. 비결정적 버그의 문제<br />버그 상황을 확인하기 어렵다<br />수정 확인이 어렵다<br />추론이 힘들다<br />잘못된 결론에 도달하기 쉽다<br />다 떠나서 이런 버그는 그냥 골치 아프다<br />
  45. 45. 자동화<br />빠른 재현, 실수 감소<br />테스트 자동화<br />테스트 프레임웍이 가장 좋은 방법<br />로그파일 재생<br />반복<br />획득한 정보를 통해 재현을 다듬기<br />어떻게 하면 좀 더 편하게 살 수 있을까를 계속 고민하는 것이 디버깅을 잘하는 요령<br />
  46. 46. 재현<br />재현<br />소프트웨어 제어<br />환경제어<br />입력제어<br />재현 방법 다듬기<br />정말로 재현할 수 없다면?<br />실천<br />
  47. 47. 정말로 재현이 안되요<br />버그가 정말로 존재하는가?<br />모든 가능성을 다 따져 봤는지 확인<br />추가 정보는 없는지 확인<br />같은 영역 다른 문제부터 해결<br />해당 영역의 코드를 정리한다<br />원래 문제를 더 명확하게 볼 수 있다<br />안되면?뭐 다른 버그 수정했으니 손해 본 건 없다<br />
  48. 48. 정말로 재현이 안돼요<br />다른 사람 끌어 들이기<br />다른 시각으로 문제를 따져 본다<br />버그를 알려준 사람을 데려온다<br />IBM 한국 developer Works : 창의성의 아이러니 (김창준 님)<br />1. 다른 사람을 활용하라 참조<br />
  49. 49. 정말로 재현이 안돼요<br />데드레커닝<br />SW의 이상원인을 순전히 논리만으로 증명한다<br />참고<br />게임에서 일반 적인 데드레커닝 용어<br />대게 네트워크 게임에서 부하를 줄이기 위해 움직임을 예측해서 미리 시뮬레이션 하는 과정<br />SW의 동작 방식을 예측해서 시뮬레이션<br />
  50. 50. 재현<br />재현<br />소프트웨어 제어<br />환경제어<br />입력제어<br />재현 방법 다듬기<br />정말로 재현할 수 없다면?<br />실천<br />
  51. 51. 실천<br />무엇보다도 먼저 재현 방법을 찾는다<br />버그가 발견된 버전의 SW 실행하기<br />재현 환경을 똑같이 만들기<br />재현에 필요한 입력을 찾기<br />추론<br />기록<br />재현 방법 다듬기<br />비결정성 제거<br />자동화<br />
  52. 52. 문제의 핵심<br />구조적 접근<br />재현<br />진단<br />수정<br />반영<br />
  53. 53. 진단<br />과학<br />계략<br />디버거<br />실수<br />심리전<br />확인<br />실천하기<br />지금부터는 과학을 할 겁니다<br />
  54. 54. 진단은 머리로 하는 것<br />체계적<br />열린 마음<br />창의적<br />철저<br />모순된 요구 사이에서의 균형<br />
  55. 55. 디버깅 방법<br />가설을 세운 뒤 검증할 실험으로 확인<br />시작<br />가설 만들기<br />실험 설계<br />yes<br />실패?<br />yes<br />no<br />다른 증거 필요<br />종료<br />no<br />
  56. 56. 실험<br />가설의 특징을 보고 방법을 선택한다<br />내부 상태 검사<br />작동 변경 검사<br />로직 변경 검사<br />실험에는 목표가 있어야 한다<br />실험 목표를 자문<br />데블스애드버킷(보고 싶은 것만 본다)<br />
  57. 57. 한번에 하나만 고치기<br />무슨 이유에서인지 사람들이 이 원칙을 너무 자주 까먹는다<br />
  58. 58. 시도를 기록해 두기<br />오랜 진단<br />이전에 했던 것을 놓칠 위험<br />실험과 결과를 기록해 두자<br />뭘 했는지 까먹지 않을 정도만<br />일일노트, 개인위키<br />가설 써놓기 (허점을 찾기 좋다)<br />아이디어 목록 써놓기<br />낙서하기 (머리를 식히자)<br />
  59. 59. 아무것도 무시하지 않기<br />예상 못한 일이 발생<br />가정 중 틀린 곳이 있다<br />하던 일을 멈추고 고치는 게 최선<br />뭐든지 이해하지 못하는 부분은 잠재적인 버그다<br />
  60. 60. 진단<br />과학<br />계략<br />디버거<br />실수<br />심리전<br />확인<br />실천하기<br />반복적으로 도움이 되어 온 기법, 방법<br />
  61. 61. 진단 코드<br />진단은 정보가 전부다<br /> SW 에 진단 코드를 추가<br />로그를 활용<br />하이젠 버그에 주의한다<br />소스코드를 최대한 원형에 가깝게<br />
  62. 62. 분할 정복<br />여러 후보들을 빠르게 추리자<br /> Log2N<br />소스 관리 시스템 활용<br />체크인 설명 확인<br />리비전으로 이진 검색<br />Git의 bisect<br /> Mercurial 에도 있어요<br />
  63. 63. 널리 쓰이는 기술 이라면<br />다른 사람이 먼저 겪었을걸<br />포럼, 블로그를 검색해보자<br />오캄의 면도날<br />다른 모든게 같다면 가장 쉬운 설명이 좋다<br />가장 간단한 것부터 확인 해 보자<br />
  64. 64. 진단<br />과학<br />계략<br />디버거<br />실수<br />심리전<br />확인<br />실천하기<br />이제서야 디버거에 대한 이야기를 하는 이유<br />
  65. 65. 디버거<br />가장 강력한 디버깅 방법<br />디버거를 사용 하는 이유<br />의도대로 실행 되는지 코드를 단계별로 확인<br />코드 실행에 대한 이론 증명/반증<br />이상하게 실행되는 코드 검사<br />
  66. 66. TDD 를 대입해 본다면?<br />
  67. 67. 테스트 우선개발<br />의도한 코드 실행 확인을 위해<br />작동을 보여줄 테스트를 작성한다<br />버그 발생에대한 이론이 있다면<br />증명할 테스트를 작성한다<br />디버거로 확인하는 것은 순간,<br />테스트 결과는 계속 남는다<br />이론 증명 뿐 아니라 수정도 검증<br />디버거는 검사용<br />
  68. 68. 진단<br />과학<br />계략<br />디버거<br />실수<br />심리전<br />확인<br />실천하기<br />실전에서 배운 교훈들을 살펴보자<br />
  69. 69. 고쳤을 때 효과가 없다면 원했던 부분이 아니다<br />맞는 걸 고치고 있는지 확인<br />헷갈리기 쉬운 흔한 함정<br />다른 바이너리 실행<br />다른 서버에 접속<br />코드 비활성화<br />함정에 빠진걸 쉽게 알려면<br />명확한 실패 코드를 추가한다<br />가정을 비판적으로 검토한다<br />실험 결과가 달라진다면<br />정확하게 무엇이 변경 됐는지를 찾아 제어한다<br />
  70. 70. 문제가 정말 복잡할 때<br />원인이 여러 개는 아닌지 의심해 본다<br />원인이 여러 개라면<br />문제를 격리<br />하나의 원인에만 의존하는 버그 재현방법 찾아보기<br />같은 영역의 다른 버그를 확인<br />다 통하지 않는다면<br />심호흡을 한다<br />누구도 디버깅이 쉽다고 하지 않았다<br />
  71. 71. 진단<br />과학<br />계략<br />디버거<br />실수<br />심리전<br />확인<br />실천하기<br />더 이상 뭘 해야 할지 모르겠다고 상처받지 말자<br />장애물에 가로막혔을 때 도움되는 기법을 보자<br />
  72. 72. 또! 다른 사람에게 도움을 요청<br />역할극<br />피규어 디버깅<br />생각을 정리<br />가정을 나열<br />기본 원리로 부터 논거를 구성<br />문제를 설명하는 것만으로도 영감<br />못 찾았으면?뭐 딱히 잃은 것도 없다<br />
  73. 73. 다양한 디버깅 툴들<br />
  74. 74. 문제 묵혀두기<br />진전이 없어 자책 중? 휴식이 필요<br />잠재의식을 활용한다<br />갑자기 머릿속에 해답이<br />안 떠오르면? 충전된 상태로 문제를 본다<br />남용은 금물<br />계속 압박해야 찾을 수 있는 버그도 있다<br />복잡한 버그를 찾으려면 여러 다른 것들을 기억하고 있어야 한다<br />
  75. 75. 셜록홈즈 법칙<br />‘불가능한 것들을 전부 제거하고 나면 아무리 불가능해 보이는 것이라도 남아 있는 것이 진실이다’<br />너무 아닐 것 같다는 이유만으로 설명을 기각하지 말자<br />인내<br />사실 진단할 수 없는 버그는 없다<br />쉽진 않지만 시간, 노력, 각오 만 있다면 언젠가는 해답을 찾을 수 있다<br />
  76. 76. 진단<br />과학<br />계략<br />디버거<br />실수<br />심리전<br />확인<br />실천하기<br />
  77. 77. 견제와 균형<br />진단 내용을 다른 사람에게 설명<br />깨끗한 소스코드로 유효한지 검증<br />생각한 대로 돌아가는지 확인<br />데블스애드버킷<br />
  78. 78. 진단<br />과학<br />계략<br />디버거<br />실수<br />심리전<br />확인<br />실천하기<br />
  79. 79. 가설을 세우고 실험으로 확인<br />실험 목표 분명히<br />한 번에 하나만<br />시도들을 기록<br />아무것도 무시하지 않는다<br />제대로 안되면<br />가정 확인<br />원인이 여러 개인지 확인<br />진단을 확인<br />
  80. 80. 문제의 핵심<br />구조적 접근<br />재현<br />진단<br />수정<br />반영<br />이미 문제를 알고 있기 때문에 수정하기는 식은 죽 먹기<br />
  81. 81. 수정<br />지금부터는 형사가 아닌 SW 엔지니어로 돌아 오세요<br />단순히 SW가 올바르게 작동하게 만드는 것보다 더 좋게 수정할 방법<br />문제 수정<br />회귀 방지<br />품질 유지, 향상<br />
  82. 82. 깨끗한 상태에서 시작한다<br />시작 지점을 신뢰 할 수 있다<br />증상이 아닌 근본 원인을 고친다<br />잘 설명할 수 있는지 확인<br /> ‘이유는 모르겠지만’,<br /> ‘ 확실치않지만’…<br />정직하라<br />원인을 확신 할 수 있는 수준이 아니라면 버그 수정을 신뢰할 수 없음을 인정하는 용기가 필요<br />
  83. 83. 테스트 주도 개발 중이라면<br />기존 테스트가 통과 되는지 확인<br />새로운 테스트를 실패 시킨다<br />테스트 추가, 수정<br />버그를 수정한다<br />새로운 테스트가 통과되는지 확인<br />회귀를 확인<br />기존의 테스트도 통과<br />
  84. 84. 아니라면<br />수동으로 테스트<br />그래도 테스트는 중요<br />회귀가 들어갈 가능성이 높다<br />회귀가 생기지 않게 굉장히 조심한다<br />
  85. 85. 리팩토링<br />광범위한 테스트 스위트가안전망 역할을 해줄 때 안전하게 수정 할 수 있다<br />작동 변경과 리팩토링을 동시에 하면 안 된다<br />버그가 있는 코드는 개선할 여지가 있을 가능성이 높음을 의미<br />버그 수정 만큼이나 중요하다 (품질 향상)<br />리팩토링-> 버그 수정<br />버그 수정 -> 리팩토링<br />사이를 반복<br />
  86. 86. 체크인<br />디비겅 관점에서 소스 관리 시스템의 가치는 감사 추적 기능<br />로직을 하나 바꿀 때마다 체크인 한다<br />체크인 설명을 최대한 의미 있게 구체적으로 작성한다<br />체크인 하기 전에 어떤 것을 체크인 하려는지 검사한다<br />
  87. 87. 코드리뷰 받기<br />분명하지 않거나 위험하다고 생각되는 부분 에서<br />익숙하지 않은 분야의 작업이라면<br />작업에 익숙한 누군가에게<br />이미 잘 알고 있는 코드라면<br />모르는 사람의 신선한 시각으로<br />
  88. 88. 실천하기<br />버그 수정의 3가지 목표<br />문제 수정<br />회귀 방지<br />품질 유지, 향상<br />깨끗한 소스에서 시작한다<br />테스트를 확인한다<br />증상이 아닌 원인을 고친다<br />리팩토링 한다<br />로직을 바꿀 때마다 체크인 한다<br />
  89. 89. 끝<br />Reference<br />Debug It! 실용주의 디버깅<br />프로그램은 왜 실패하는가<br />실용주의 프로그래머<br />적당한 스터디 발표자료 만들기 : http://www.slideshare.net/ohyecloudy/ss-4722063?from=ss_embed<br />Kuler : http://kuler.adobe.com/#themes/search?term=corporate%20flair<br />IBM 한국 developer Works : http://www.ibm.com/developerworks/kr/library/dwclm/20100630/<br />TDD 동영상 : http://xper.org/LineReaderTdd/<br />Twtpoll : http://twtpoll.com/r/mwilg5<br />데드레커닝: http://www.g-matrix.pe.kr/feature/multi/deadreckoning.htm<br />Git : http://namhyung.springnote.com/pages/3132772<br />Mecrurial : http://mercurial-korean-doc.googlecode.com/hg/hg.1.kor<br />

×