스택오버플로우의 공동 창업자인 제프 앳우드의 글 모음. http://www.codinghorror.com/ 에 연재된 글을 정리한 것도 있고, 새로운 내용도 있다.
인상깊었던 부분을 몇 가지 추려보자면:
회사의 관점에서 스택 오버플로우를 운영하는 것에 대해
커티스 암스트롱의 조언(?)을 이용
저 길로 가, 총알같이 빠르게. 눈앞에 뭐가 나타나면 방향을 틀어 Go that way, really fast. If something gets in your way, turn.
그리고 팀 오라일리가 래리 페이지를 인용한 것을 재인용한 부분:
래리 페이지는 이렇게 말했다. “속도와 좋은 결정 사이에 존재하는 관련성… 빠르고 좋은 결정은 있지만, 느리고 좋은 결정은 없다.” (오후 3:40 — 2011년 9월 27일)
프로그래머 권리 장전
이건 코딩호러 블로그에 나온 것 그대로임 (http://www.codinghorror.com/2006/08/the-programmers-bill-of-rights.html )
모든 프로그래머는
- 두 대의 모니터를 가져야 한다
- 빠른 PC를 가져야 한다
- 마우스와 키보드를 자기가 원하는 것으로 선택할 권리가 있다
- 편안한 의자를 가져야 한다
- 인터넷에 연결할 수 있어야 한다
- 조용한 작업 환경을 가져야 한다
이건 내가 일했던 곳들에 대입해서 생각하니 참 뭐랄까 (하략)
배경 조명
LED 조명 + 양면 테이프로 값 싼 배경 조명 (background light)을 구축할 수 있겠다고 함. 이건 다음 일하게 되면 해봐야지 (…)
UI를 우선시하는 소프트웨어 개발
단 한줄의 코드를 작성하기 전에 나는 사용자 인터페이스가 어떤 모습이어야 할지에 대해 완전히 명확한 아이디어를 갖길 원한다.
종이를 이용한 프로토타입 만들기 등을 다루는데 이건 좀 해보고 싶다.
고객의 고통을 공유하기
개발자가 자신의 코드와 함께 살아가는 사람들인 고객의 마음과 밀착하는 것은 대단히 중요하다.
소프트웨어 개발자가 코드를 실제로 사용하는 시간보다, 이걸 사용하는 사람들이 코드를 사용하는 시간이 훨씬 길다. 그래서 개밥 먹기 등으로 고객의 고통을 분담해야 한다. 멋진 일은 아니지만 소프트웨어 완성에는 중요하다.
코드 리뷰: 그냥 하라
코드 컴플리트에 나온 내용 원용; 이걸 전에 어디서 봤느지 궁금했었는데 (NDC 발표 자료 만들면서) 출처를 찾은 듯;
평균적으로 버그를 잡아내는 비율:
- 단위 테스트: 25%
- 기능 테스트: 35%
- 통합 테스트: 45%
- 설계와 코드에 대한 리뷰: 55% ~ 65%
책의 다른 절에서 유닛 테스트 / 베타 테스트를 비교하는 부분도 있었다.
그리고,
코드 리뷰에서 유일한 장애물은 당신이 존중할 만한 동료 개발자를 찾고, 함께 코드 리뷰를 수행할 만한 시간을 할애하는 것이다.
현재 팀에선 코드 리뷰를 하는데, 코드에 대한 부분은 어느 정도 이상 잘 되는 것 같다. 다만 설계에 대해서 잘 했는지는 좀 반성할 필요가 있는 듯해서 여운이 좀.
그 외에
이 이후에 나온 내용은 제프 앳우드가 추천한 책 “Rocket Surgery Made Easy” (사용성 테스트 관련) 과 겹치는 내용이 꽤 많다. 그리고 마지막 부분들은 좀 재미 없었다.
전반적인 평: 꼭 보시오.