흔한 개발자 이야기

소프트웨어 개발을 잘 하기위한 실용적인 조언들과 "예광탄 개발"이라는 개발 방법론을 소개하고 있다.

저자들이 고안했다는 예광탄 개발 방법은 일종의 점진적 개발 방법이다. 소프트웨어를 한 사람, 혹은 한 팀이 일정기간 일할 수 있을 정도로 객체/계층으로 나누고 각 계층의 인터페이스를 정의한 다음에 Mock/Stub을 먼저 개발해 전체 동작을 확인할 수 있도록 만든 다음에 내용을 채우는 것으로 개발을 진행하는 방식이다. 점진적 개발 방식은 다 그렇겠지만, 개발 초기에 요구 사항을 재확인하고, 설계의 결함을 발견하기 좋은 개발 방식으로 보인다.

그리고 책 전체에 걸쳐서 다음과 같은 조언들을 담고 있다.

1. (의식적으로, 신중하게 좋은) 습관을 선택하세요.
2. 모래 상자 안에서 노세요.
3. (빌드를 위해서) 필요한 거라면 체크인(커밋) 하세요.
4. 첫날에 빌드를 스크립트화 하세요.
5. 어떤 컴퓨터에서라도 빌드가 되어야 합니다.
6. 지속적으로 빌드하세요.
7. 지속적으로 테스트하세요.
8. (이슈 추적 시스템 등을 사용해서) 모두가 잊어버리는 사태는 피해야 합니다.
9. 제품을 작동시켜보세요 - 테스트를 자동화하세요.
10. 유연하고 많은 사람이 사용하는 테스트 장비를 사용하세요.
11. 업무에 가장 적합한 도구를 사용하세요.
12. 공개된 포맷을 사용해서 여러 도구를 통합하세요.
13. (프로젝트 진행에 영향을 줄 수있는 SCM이나 빌드 스크립트 등의) 임계 경로 기술에 친숙해지세요.
14. 목록에 따라 일하세요.
15. 기술 리더가 알아서 하게 놔두세요.
16. 일일 회의를 해서 진행 방향을 수시로 바로 잡으세요.
17. (집중하고 있을때에는) "나중에"라고 말해도 됩니다.
18. 항상 모든 코드를 검토하세요.
19. 소프트웨어가 목표지, (업무 처리 기법에) 순응이 목표는 아닙니다.
20. 그룹 전체가 (전체 시스템을 개선할 수 있는) 아키텍트입니다.
21. (실제 환경의) 제품에서 사용하는 거라면, (개발 환경에서) 여러분도 사용해야 합니다.
22. (핵심 기능인) 가장 어려운 문제부터 해결하세요.
23. 캡슐화된 아키텍처야말로 확장성 있는 아키텍처입니다.
24. 보트가 움직이기 전엔 보트를 조정할 수가 없습니다.
25. 테스트하기 전에는 다른 사람이 물려준 코드를 변경하지 마세요.
26. 테스트 주도 리펙토링으로 테스트할 수 없는 코드를 깨끗이 정리하세요.
27. 가짜 클라이언트로 최소한의 노력으로 최대의 성과를 거둘 수 있습니다.
28. 변경되는 코드를 지속적으로 테스트하세요.
29. (버그를 수정하는 것은) 모두에게 통하는 방법이어야 합니다.
30. (CI 시스템을 사용하여) 자주 통합하고, 지속적으로 빌드하고 테스트하세요.
31. (고객에게) 동작하는 데모를 일찍 그리고 자주 전달하세요.
32. (불만스러워하는 관리자를 위해서) 여러분이 무엇을, 왜 하고 있는지 (목록을 만들어) 공개하세요.
33. 얼굴을 많이 마주칠수록 팀워크가 단단해집니다.
34. (새로운 실천방법 등의 도입보다는) 고쳐야 하는 것만 고치세요.
35. 파괴적인 '우수한 업무처리기법'은 진정한 의미의 업무처리기법이라 할 수 없습니다.
36. (새로운 실천방법의 도입은) 밑에서부터 혁신해야 합니다.
37. (새로운 실천방법은) 말만하지 말고 보여주세요.
38. (새로운 실천방법 도입에) 관리층의 지지를 이끌어내세요.
39. (현재 발견된) 버그가 있는 곳을 테스트하세요.
40. 목록은 살아있는 문서입니다. 변화가 목록의 생명입니다.
41. (관리자로서) 목록이 없다면, 그것은 프로젝트의 일부가 아닙니다.
42. (고객은) 항상 피드백을 빨리 해주세요.

위에서 괄호와 강조 표시는 내가 추가했다.

개발자도 아니고 관리자도 아닌 어정쩡한 위치라고 생각했던 기술 리더를 모든 개발자는 적어도 한번쯤 되기를 꿈꿔야한다고까지 이야기하는 것이 새로웠다. 기술 리더는 시간을 쪼개 기술 업무와 관리 업무를 한다고는 하지만, 책에서 다룬 아래와 같은 기술 리더의 체크리스트를 보면 개발자라기보다는 관리자에 가깝다는 생각이 들었다.

기술리더로서 여러분은 다음 질문에 긍정적인 대답을 내놓을 수 있어야 합니다.

• 팀 구성원 각자가 무슨 일을 하고 있는지 알고 있습니까?
• 5분 이내에 프로젝트의 현 상황에 대한 개요를 작성해낼 수 있습니까?
• 다음에 추가해야 할 기능이 무엇인지 5개 내지 10개 정도를 댈 수 있습니까?
• 우선순위가 가장 높은 결함을 서슴없이 열거할 수 있습니까?
• 팀 구성원을 위해 여러분이 해결한 가장 최근의 문제는 무엇이었습니까?
• 해결해야 할 중요한 이슈가 있을 때 팀 구성원이 여러분을 찾아옵니까?

기술리더가 비효율적이거나 과중한 업무를 맡고 있다는 신호입니다.

• 팀 구성원 각자가 업무 방향에 대해 큰 그림을 갖고 있지 않습니다.
• 기술 리더가 나타나면 일이 중단됩니다.
• 팀의 성과를 가로챕니다.
• 문제를 해결하는 데 실패합니다. 더 심한 경우에는 문제를 일으킵니다.
• 업무 일정을 부정확하게 예측합니다.
• 팀 구성원이 어떤 기술에 능숙한지 또는 팀 구성원이 배우길 원하는 기술이 무엇인지 알지 못합니다.
• 팀 구성원 간의 충돌을 감지하지 못합니다.
  

---

성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

저자

자레드 리차드슨, 윌 그월트니 주니어 지음

출판사

위키북스 | 2007-08-09 출간

카테고리

컴퓨터/IT

책소개

소프트웨어 개발에 관한 내용을 담은 가이드북. 이 책은 소프트웨...

---