1.png


1 장

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

2장

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

3장

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

프로그래밍심리학
Powered by MoniWiki / Designed by Fantics