스택 오버플로우의 공동 창시자 조엘 스폴스키.
이 책은 그의 블로그인 조엘 온 소프트웨어의 다양한 글들을 모아 놓은 책입니다.
서문을 빌리자면, 이 책은 '소프트웨어 개발의 기본 철학을 즐겁고 흥미롭게 풀어낸 책'입니다.
그래서 관통하는 하나의 주제가 없다는 것이 이 책의 장점이자 단점입니다.
짧은 글을 엮어놓은 만큼, 가볍고 흥미롭게 읽어보기엔 좋더라구요.
하지만 글의 주제나 대상 독자가 너무 다양해서 일부 글은 이해하기 어려웠습니다. 😅
그래서인지 더욱 두고두고 읽어봐야 할 책이라 생각이 들었습니다.
조엘 테스트
조엘 테스트는 "우리 팀은 좋은 개발 문화를 갖추고 있는가"에 대한 간단한 테스트입니다.
2000년에 만들어진 이 테스트가 여전히 중요하게 적용된다는 사실이 새삼 놀랍네요.
역시.. 시대가 변해도 소프트웨어 철학만큼은 바뀌지 않다는 걸 몸소 느낍니다.
1. 소스코드 관리시스템을 사용하고 있습니까?
2. 한방에 빌드를 만들어낼 수 있습니까?
3. 일일 빌드를 하고 있습니까?
4. 버그 추적시스템을 운영하고 있습니까?
5. 코드를 새로 작성하기 전에 버그를 수정합니까?
6. 일정을 업데이트하고 있습니까?
7. 명세서를 작성하고 있습니까?
8. 조용한 작업 환경에서 일하고 있습니까?
9. 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?
10. 테스터를 별도로 두고 있습니까?
11. 프로그래머 채용 인터뷰 때 코딩 테스트를 합니까?
12. 무작위 사용편의성 테스트를 수행하고 있습니까?각 문항이 "예"일 때 1점씩 올립니다.
11점 이상은 우수한 성적이지만, 10점 이하는 심각한 문제가 있습니다.
이 테스트를 하면서 저는 테스터, 명세서, 일정 관리에 대해 다시금 생각해보게 되었습니다.
테스터
TDD에 관심 있던 저에게 조금은 혼란스러운 대목이었습니다.
저는 '테스트는 안전한 코드를 위한 개발자의 필수 역량'이라는 생각을 항상 하고 있습니다.
하지만 조엘은 다음과 같은 이유로 '독립적인 QA 부서'의 필요성을 강조합니다.
- 자신의 코드에서 버그를 찾기 힘들기 때문입니다. 대게 내 코드의 버그는 다른 사람이 더 쉽게 찾거든요.
- 다양한 관점에서의 테스트로 새로운 버그를 발견할 수 있습니다.
- 개발자의 직접적인 테스트보다 더 많은 TC로 더 많은 버그를 찾을 수 있을 겁니다.
- 개발자가 테스트를 담당하기엔 비용적인 문제가 있습니다.
저는 여전히 개발자에게 테스트가 중요하다고 생각합니다.
정확히 말하면 Testable한 코드를 설계하는 능력이죠.
또한 테스트를 맹신하지 말 것을 깨닫기도 했습니다.
등잔 밑이 어둡듯, 본인의 코드에서 버그를 찾는 것이 가장 어렵기 때문입니다.
명세서
명세 == 설계
개발자가 명세서 작업에서 얻을 수 있는 가장 큰 이점은 바로 프로그램 설계입니다.
프로그램이 세부적으로 어떻게 동작하는지 기술하다 보면 자연스럽게 프로그램을 설계하게 됩니다.
또한 명세서를 먼저 작성하면 변경 사항에 훨씬 빠르게 대응할 수 있습니다.
요구사항이 자주 변동되는 실무 환경을 생각하면, 더욱 명세서의 중요성을 느낄 수 있습니다.
명세 == 의사소통 도구
또한 명세서는 모두가 활용하는 의사소통 자료이기도 합니다.
- QA 팀은 명세서를 통해 프로그램을 파악하고 테스트 케이스를 만듭니다.
- 마케팅 팀은 명세서를 활용해 베이퍼웨어를 작성합니다.
- 사업 팀은 명세서를 통해 투자자에게 광고할 문서를 만듭니다.
- 테크니컬 라이터는 명세서를 통해 매뉴얼을 작성합니다.
- 고객, 관리자, 개발자도 모두 마찬가지로 명세서를 중심으로 제품을 파악합니다.
일정 관리
일정 관리는 개인과 팀 모두에게 중요한 역량입니다.
일정이 없다면 개발자는 유용하고 중요한 것이 아닌, 쉽고 재밌는 것부터 하려고 합니다.
뜨끔하네요 😅 일정이 있다면 일의 우선순위를 보다 객관적으로 정할 수 있죠.
또한 개발자로서의 일정 관리는 정확한 일정 계산 능력이 포함됩니다.
일정 계산 능력은 메타인지에 비롯된 자기 객관화 능력과도 관계가 있습니다.
일정 계산을 위한 몇 가지 팁을 정리해보겠습니다.
- 디버깅 시간까지 포함된 여유 기간을 계산합니다.
- 업무를 보다 구체적인 단계로 나눕니다,
- 구체적일수록 기능이 명확해지고, 불안 요인을 상당수 제거할 수 있게 됩니다.
- 수정할 버그가 남은 상태에서 새로운 코드를 작성해서는 안됩니다.
- 버그 수정이 가장 쉬울 때는 개발을 마친 직후이기 때문입니다.
장인정신
"1%의 마지막 코드가 전체 시간 90%를 소모한다."
결함 1%를 고치기 위해 500%의 노력이 더 필요한 경험이 있을 것입니다.
사소한 결함을 해결하기 위해선 시스템의 전반적인 구조를 변경해야 하는 상황 등이 있죠.
가령 명품을 생각해보면 장인정신은 가성비가 매우 좋지 않은 작업입니다.
만일 사내용 프로그램을 만드는 데에 장인정신을 발휘하는 것은 비효율적이죠.
이유는 간단합니다. 장인정신의 막대한 추가 비용을 감당할 충분한 사용자가 없기 때문입니다.
하지만 상품 서비스 회사에서는 장인정신이 의미 있을 수 있습니다.
사용자 경험을 극대화하고, 경쟁우위를 제공할 여지가 있기 때문입니다.
결국 장인정신은 필요에 따라 사용하는 것이 옳습니다.
면접 가이드
면접관 입장에서 수많은 이력서는 소거법으로 정리할 수밖에 없습니다.
그래서 꼼꼼하지 않은 이력서가 정리 대상 1순위가 되는 것이죠.
기준 미달자를 채용하는 것보다 훌륭한 지원자를 놓치는 것이 차라리 낫습니다.
기준 미달자는 팀에 큰 악영향을 끼칠뿐더러, 이들을 정리하는 일도 만만치 않습니다.
훌륭한 지원자는 한마디로 똑똑하면서도 업무를 성실하게 완수하는 사람입니다.
똑똑하기만 한다면 사소한 하나에 꽂혀서 며칠을 허비하는 사람일지도 모릅니다.
만약 바쁜 시기에 이런다면 팀의 사기에 엄청난 문제를 줄 수도 있습니다.
성과급의 문제
"열심히 일한 사람에게 더 큰 보상을 준다."
평가 제도는 어쩌면 굉장히 이상주의적인 제도일지도 모르겠습니다.
놀라웠던 건, 긍정이든 부정이든 상관없이 평가는 결과적으로 해가 된다는 점입니다.
개인적으로 저 또한 평가 시스템을 좋아하지 않습니다.
평가자의 관점에서 제가 그 사람을 판단하는 것이 어렵기 때문입니다.
(불가피하게 평가 제도를 따라야 한다면 스스로를 어필하는 능력이 중요하겠네요.)
그렇다면 성과를 잘 받은 사람은 왜 스트레스를 받을까요?
사람들은 스스로 일을 잘한다고 생각하는 경향이 있어, 대부분은 평가 결과에 실망할 수밖에 없습니다.
긍정적인 성과여도 본인이 기대한 수준에 미치지 못한다면, 부정적인 평가만큼이나 사기를 떨어뜨립니다.
그래서 평가 기간 뒤엔 반드시 팀의 사기 저하가 동반될 수밖에 없습니다.
침체된 사기는 트러블이나 이탈로 이어져 최악의 경우 팀은 신뢰를 잃고 파괴될 수 있습니다.
수많은 연구 결과에서도 보상을 바라는 사람은 그렇지 않은 사람에 비해 업무 성과가 떨어진다고 합니다.
만약 평가를 따라갈 수밖에 없다면 모두에게 최고 평가를 주는 것이 팀을 지키는 유일한 방법입니다.
개발자뿐 아니라 모든 직종은 품질과 서비스에 자긍심을 갖고 일하는 것이 가장 바람직하다고 생각합니다.
레거시 코드의 가치
코드 쓰기보다 코드 읽기가 더 어렵고 재미없는 것은 사실입니다.
저도 종종 왜 이렇게 코드를 짰을까.. 이해할 수 없고 불만이 생긴 적이 있었습니다.
하지만 이 책은 그런 관점을 고칠 수 있게 해 줍니다.
생각해봅시다. 기존 코드가 왜 비대해졌을까요?
어쩌면 당시의 버그 수정 때문에 점점 몸집이 커졌을 수도 있습니다.
그 과정에서 수많은 테스터와 개발자들의 노력이 있었겠죠?
이 말은 곧, 과거 코드들은 테스트를 마친 검증된 코드라는 의미이기도 합니다.
그래서 굳이 코드를 새로 짜는 것은 이전 코드에 있는 노하우를 다 버린다는 뜻입니다.
그러니 코드를 버리고 새로 시작하려는 습관은 꼭 고쳐야 합니다.
UI의 중요성
서비스 전체를 놓고 보면 UI는 실제 프로그래밍의 5-10% 정도밖에 차지하지 않습니다.
하지만 유저는 이러한 사실을 인지하지 못합니다.
유저의 눈에는 UI의 문제를 그대로 서비스의 문제로 생각하게 됩니다.
유저가 기능을 살펴볼 것이라고 생각하면 안 됩니다.
그들은 그저 아름다운 픽셀을 보길 원합니다.
그러니 무조건 아름답게 만들어 사용자 경험을 높이길 바랍니다.
(애플이 이런 부분에서 굉장히 잘하고 있죠.)
책이 조금 오래된 점과, 해외 사례가 많다는 점에서 가독성이 떨어지긴 했지만
개발자로써 두고두고 읽을만한 글들이 정말 많았습니다.👍
가볍게 추천하고 싶은 책이네요.