1 장 #

• code review 하는 프로세스가 있는가?
  
  • 개발 프로세스 자체에 온라인 코드 리뷰가 전사적으로 들어감
    
    • 처음에는 어색 -> 익숙해지니 효과 만점(원추)
      
    • 신입 : 선배들이 내 코드를 봐 주니 든든하다
      
    • 팀 : 코드의 공동 소유, 전체를 보는 능력 생김
      
    • 좋은 도구도 많다
      
• 버그가 생기면 고고학자처럼 왜 이런 버그가 생겼는지 원인을 찾게 되었다
  
  • debug == 히스토리 추적
    
  • 모든 버그는 변경에서 나온다
    
• 코드 리뷰를 하긴 하는데, 담당자인 상급자는 시간도, 의지도, 능력도 없다
  
  • 다른 사람(예전 상급자) 의 코드를 깔보게 되는 경우가 50 % 이상이었다.
    
• 누군가 자신의 코드에 대해 지적할 때 대처하는 자세
  
  • 신입 개발자 혹은 고참 개발자의 코드가 맘에 안 들때 어떻게 설득할까?
    
  • 누가 지적해 주면 고마워하는 분위기를 만들자.
    
  • 내가 지적에 화를 내면 다시는 나를 도와주지 않을 것이다
    
    

2장 #

• 좋은 프로그램이란?
  
  • 의사 3형제 이야기. (첫째 : 예방, 둘째 : 내과, 셋째 : 외과)
    
    • 관련된 내용 - 내가 명의로 소문이 나게 된 이유는 여기에 있다
      
  • 다른 사람의 버그도 막아주는 개발자(예방), 눈에 잘 안 보이는 버그를 잘 고치는 개발자(내과) vs 눈에 보이는 버그를 잘 고치는 개발자(외과)
    
  • 하지만 세상 사람들은 셋째 의사만 최고라고 생각한다
    
• 요수사항이 충족되나 10 초가 걸리는 프로그램 vs 요구사항이 충족되지 않으나 1초가 걸리는 프로그램
  
  • 가끔 후자를 원하는 고객도 있다. 고객이 진짜로 원하는 걸 알자
    
• 개발자의 포상기준은?
  
  • 어떤 기준을 만들어도 거기에 최적화 되어 버린다
    
  • 팀 단위로 포상해야 하고, 관리자는 누가 어떻게 일을 하는지 알고 있어야 한다
    
• 세상에 완벽한 프로그램은 없다
  
• 피셔의 기본 정리 법칙
  
  • 특정 환경에 적응되면 될 수록 다른 새로운 환경에 적응하기 힘들다
    
  • 하지만 새로운 환경에 적응하기 쉽다면, 특정 환경에 적응하기 어려울 수도 있다
    
  • 범용 개발자 vs 특수 개발자
    
• 범용성 vs 최적화
  
  • 자바 VM 의 성공과, 머신의 성능 향상으로 이미 범용성이 승리를 거뒀다.
    
  • 이제 C++ 이나 자바로 개발하는게 최적화라고 생각되고, 모델링 툴로 프로그래밍 하는 게 범용성으로 생각되는 다음 단계로 진행될 것이다
    
• 개발로그, 프로젝트 진행 로그를 남기는가
  
  • 시간당 LOC(line of code) 를 남기게 했더니 3시간 동안 한 줄 작업하는 경우도 있다.
    
    • 그렇다고 놀았다고 판단할 것인가? 감시받는 느낌이 든다
      
  • 귀찮은 점도 있지만 결과적으로 팀에 도움이 된다고 생각된다
    
• 모든 것을 수련하자 (틱낫한스님의 마인드풀니스, 평화로운 전사)
  
• 수정을 어렵게 만드는 요인
  
  • 일정의 압박, 여러 프로젝트의 동시 진행
    
  • 급할때는 테스트는 나중에 하라고 해 놓고는 나중에 문제 생기니까 문책 받았다.
    
• 일정 준수의 문제
  
  • 목소리 큰 고객, 혹은 귀한 고객의 문제부터 먼저 해결하게 된다
    
  • 합리적으로 일정을 만들 방법은? 스크럼의 sprint 를 소개
    
• 효용성을 위해 한 일은?
  
• 기존 리소스를 최대한 활용 vs 새로운 것을 창조
  
  • 기획자의 입장에서는 새로운 것을 창조해 나의 능력을 보여주고 싶어한다. (사실 프로그래머도 비슷한 사람들이 있다)
    
    

3장 #

• 이번 버그를 왜 못 찾았을까 / 왜 만들었을까를 내성법(나 자신의 생각, 사고 과정을 연구) 으로 고민해 보고 있다