the psychology of computer programming review - andstudy/forge GitHub Wiki

프로그래밍심리학을 읽고 내가 달라진 점을 공유하는 페이지입니다.

parkpd

매주 화요일마다 전체 프로젝트 코드리뷰 하기

• 코드 리뷰 하는 법
  • Arixis Merge 를 구매한다
  • 현재 코드의 snapshot 을 로컬에 저장한다
  • 저번 주에 저장한 코드 snapshot 을 현재 코드와 폴더 비교한다
  • 하나다 쭉 훑어보면서 이상한 게 있으면 담당자에게 물어본다

내성법으로 찾은 디버깅 Tip

• 서버에서 Crash 가 났을 때, 나는 못 찾은 버그를 다른 사람이 찾으면, 그 사람은 어떻게 그 버그를 찾았는지 물어본다
• 혹은 내가 가장 먼저 Crash 의 원인을 찾았을 때도, 어떻게 버그를 찾을 수 있었는가를 스스로에게 물어보고 이를 정리한다

내성법으로 찾은 디버깅

찾기

• 도저히 모르겠다고 생각될 때 1시간만 더 보자. 거의 다 왔을 수 있다.
• 내가 고친 코드를 먼저 의심하자.
• 잘 모르겠거든, 다른 사람에게 물어보자. 특히 내가 만든 코드는, 너무 익숙해서 뻔한 버그도 찾기 어렵다.
• 갑자기 이상해졌다면, 가장 최근에 고친 파일부터 차례대로 찾아보자
• 문제가 될만한 코드를 짰을 당시의 심리상태를 생각해보자.
  • 이직을 준비하던 사람이 짠 코드인가?
  • copy & paste 를 했다면, 원본 코드와 비교해서 다른 곳이 어디인지 검사해 보자(SmartPointer 버그 찾은 방법)

현상

• 현상은 원인이 있기 때문에 나타난다. 쉽게 재현 안 된다고 무시하지 말자.
• 이상현상이 생긴 시간대를 확인하고, 그 앞뒤의 에러로그를 전체적으로 확인해 보자. 생각외의 힌트를 얻을 수 있다.

재현

• 무조건 재현해 봐라. 재현이 불가능하면, 예상되는 재현이라도 해 봐라. 재현 할 때는 BP 걸어놓고 한 step 씩 이동하면서 코드를 확인해 보자
• 재현을 할 때는 문제가 되는 현상을 데이터 하나까지 똑같이 만들어 해보자. 뭔가를 찾을 수도 있다.
• 고친 게 하나도 없다고 해도, 환경이 바뀌면 버그가 생길 수 있다. 설정 파일이 바뀌었는지, 다른 쪽에서 접속이 들어왔는지 등을 확인해라.
• 뭐가 안 된다는 얘기가 나오면, 정말 그런지 직접 확인해라. 버그를 발견한 사람이 잘 못 얘기해 주거나, 이해를 못 하고 있을 수도 있고, 근처에서 다른 해결책을 발견할 수도 있다. (해외 지사에서 보낸 버그 리포트는 특히 이런 일이 더 심하다)
• 버그 report 를 그대로 믿지 마라. QA 도 잘 모르는 상태에서 아는 만큼만 써 놨을 수 있다. 직접 설정파일을 확인하고, 재현을 해 봐라.

버그를 만든 원인이 나였을 경우, 오히려 '미안, 그거 내가 만든거네.' 이라고 크게 얘기한다

• 버그를 만들지 않도록 주의해야 하지만, 어짜피 버그를 안 만드는 프로그래머는 (적어도 내 주위에는) 없다.
• 버그를 만든 사람을 죄인 취급하는 분위기가 생겨버리면 버그를 만들까봐 무서워서 기획자에게 무조건 '그거 할 수 없어요' 라고 얘기하거나, 코드를 copy & paste 할 수 있다.
• 정직할 수 있는 팀 분위기를 만들어, 내가 한 실수를 통해 다른 사람도 배울 수 있게 하고, 진취적인 팀을 만들고 싶다.

kukuman

프로그램읽기

• 신입사원이 매번 이렇게 물어본다. -> 왜이렇게 짰는지 모르겠어요 코드가 눈에 안들어와요~-_-;
• 다음과 같이 맨토링=> 이게 다 이유가 있는 코드들이다. 잘 보고 왜그랬는지 파악해봐라. 일단 이해해보는 것도 의미가 있다.
• 예전과 같으면 미친거아냐 그랬음 :) (농담반 진단반)

좋은 프로그램

• 효율적인 프로그램의 정의가 어렵다.. -> 일단 가독성과 추후 유지보수 오류가 적은 방향으로 코드 작성
• -> 변수를 길게하고 복잡한 개념을 넣지 않음

코드리뷰, 패어프로그램의 의심

• 비자아적 프로그램이라는 개념 획득 :
• 이 개념덕분에 코드리뷰나 페어 프로그램등의 행위의 긍국의 목적을 이해할 수 있었슴.
• 팀내에서 작성된 코드를 부분별로 나눠서 작성 하는등의 (중간정도 진행된 코드의 테스트케이스를 다른사람에게 작성시킴)
• 과정을 통해서 팀에 비자아적 프로그래밍 개념 도입노력
• 하지만 쉽지는 않음 T_T

신입개발자의 트래이닝방법

• 소스코드 수정하지말고 코드리뷰만 하면서 결과를 작성해보자(박일님방법)
• -> 신입사원에게 도입하면서 시험중 , 산출물 잘나온다면 도움이 될 수 있을것 같음

팀내에서 업무 분할

• 파트내에서 특정분야에 능력을 보여주는 사람에게 일을 분배해줌.
• 경험적으로 좋아하는걸 배당하면 효과가 더 좋음

개인의 성격변화의 인식

• 최근에 유지보수성 업무만 진행하다보니 현상 유지만 되고 새로운것에 대한 갈망이 죽어가는것을 느낌
• 이것은 프로그램과정을 통해서도 성격이 변할 수 있다는 것으로 인식대고 의도적로 새로운 기술에 대해서 도입검토민
• 자료 조사를 많이 시도함

송정석

지인들과 성격 테스트

• 친하게 지내던 분들과 MBTI 혹은 애니어그램 성격 테스트 해 봄.
  • 내 성격은 예전이랑 별로 변함이 없다.
  • 알고 지내던 분들중 성격이 변하신 분들도 많았다.
  • 오랜만에 보았는데 성격 테스트가 다르게 나오신 분들은 내가 알고 있던 때와 달라지신 점등을 생각해보게 됨. (무의식중에 예전의 이미지가 내 속에 자리잡아 있는듯)
  • 그냥 재미로도 좋고 좋은 이야기 거리도 되는듯 ㅋㅋ

코드 리딩

• 외부 컴포넌트 라이브러리를 보면서 코드를 좀더 유의깊게 보고자 시도
  • 아직은 목적한 기능만 집중해서 봐서 충분한 효과는 못 봄.
  • 내 영어는 여전히 왜 이 모양이냥 -_- (코딩에 사용하는 영어는 여전히 옛날 습관이 많이 남아있고 외국인이 적은 코드랑 표현법이 많이 차이남. 컼) => 심지어 스스로 읽어봐도 이게 어디서 온 문법인가 싶은 무의식속 영어작명법.
  • 이거 유료 예제 코드인데 막 코딩된게 좀 있다 ㅋㅋ (grid1 같은.., 애네도 예제 만들기는 귀찮은듯.)

팀원 칭찬하기

• 거의 못했다.
  • 팀원과 나랑 서로 다른데로 출장이 크로스로 발생. 서로 자리에 잘 없는 사태가..
  • 칭찬은 고래도 춤추게 한다는데 생각보다 잘 안하고 안된다. (한국식 교육의 효과인가-_-;; 스파르타식이 너무 몸에 배인듯..)