책이 저자가 겪은 얘기나 자신의 견해가 마음껏 드러난 책이라서 책에서 나온 것과 비슷한 경험을 듣고 싶은 분들이 많았다. 책에서 따끔한 충고도 있어서 그런 동기를 부여하는 얘기를 하고 싶은 분들도 있었다. 학생분들은 책에서 말한 실무에서 겪을뻔한 내용들을 공감하기 어려워서 다른 사람들의 의견을 듣고 싶어했다. 무엇을 배워야 할까에서 질문들에 대해 답변이 어려워서 나는 훌륭한 프로그래머인가에 대해 고민이 생긴 분도 있었다. 클린 코더에서 비슷한 말씀을 하셨었는데 우리의 지향점으로 삼는 게 좋다고 생각한다. 프로그래머의 마음가짐에 대해 얘기하신 분도 있었다. 원칙적으로는 중복된 코드를 만들면 안 되는데 시간이 쫓겨서 복붙을 하신 분도 있었다. 각주가 없어서 아쉬웠다고 하신 분도 있었다.
책이 따끔한 충고도 있고 생각해볼 만한 질문을 던져줘서 여러 가지 고민을 하게 만드는 책이었다.
조직 내에서 생산성 측정을 위해 고민이 많은 조직의 얘기를 듣게 됐다. 모든 직원들이 같은 일을 하면 생산성 측정을 할 수 있을 텐데 모두 다르다 보니까 측정이 굉장히 어렵다. 하지만 관리자들은 측정을 하고 싶어 한다. 현실적으로 불가능한 이유들이 있었다. 왜냐하면 품질에 대해서는 측정이 굉장히 어렵기 때문이다. 어떤 조직에서는 task를 완료하는 숫자로 측정하는 회사도 있었다. 작은 task들을 만들어서 완료해버리면 거짓말을 할 수 있어서 위험해 보였다. 또 다른 조직에서는 코드 리뷰나 커밋 등 활동들을 통해 측정을 하려는 시도를 하고 있는 조직도 있었다. 이 또한 품질을 평가하기 어렵고 어뷰징이 가능해서 어려워 보였다. 개발자의 생산성 측정은 아직은 먼 얘기처럼 보였다.
구현이 아닌 동작을 테스트하라는 주제도 같이 얘기했다. 전에 바이너리 트리를 만들 때 트리가 올바르게 만들어지는 테스트를 작성하다가 단순히 leaf 노드가 잘 생성되었는지를 테스트했었다. 그보다는 트리가 만들어졌다면 이 트리가 어떤 기능을 수행할 수 있는지 테스트를 작성하는 게 더 좋다고 했다. 예를 들면 바이너리 트리를 만들었다면 모든 트리의 합을 구하는 테스트를 작성할 수 있다. 혹은 가장 작은 값을 구하는 기능을 테스트할 수 있다. 이처럼 구현이 아닌 동작을 테스트하는게 테스트의 의도를 더 명확하게 드러낼 수 있어서 좋다.
아키텍처 설계에 어려움이 있어서 진행이 어려운 분들도 있었다. 나도 이런 경험이 있었다. TDD를 배우거나 클린 아키텍처를 배울 때 특히 그랬는데, 어설프게 알 때 이런 어려움을 겪었다. 기존의 방식대로 한다면 금방 할 수 있지만 더 좋은 방법이 있다는 것을 배워서 더 좋은 방법으로 하고 싶다. 하지만 그 방법을 제대로 알지 못해서 엉거주춤하게 된다. 방법은 좋은 방법을 온전히 습득하는 게 좋다. 사이드 프로젝트같이 작은 프로젝트에서 많이 연습을 해야 한다. 연습도 좋지만 지식을 쌓는 일도 균형 있게 해야 한다. TODO 앱처럼 쉽고 작은 프로젝트에 적용해보고 본 프로젝트에 적용하는 게 좋다. 현재 진행하는 것에 적용하는 게 어렵다면 아주 작은 프로젝트에 적용해보고 그대로 옮기는 것도 좋은 방법이다.
TDD를 각 잡고 하는 곳은 얼마나 되는지 궁금하신 분도 있었다. 많이 사용하는 회사도 있었고 부분적으로 사용하는 회사도 있었다. TDD 없이 개발하는게 얼마나 더 빠른지에 대해서도 얘기했다. 사실 가장 기본적인 기능을 만들 때는 테스트 없이 바로 만드는 게 빠르긴 하다. 하지만 그 기능이 점차 커지고 다양한 조건이 생길 때 테스트가 없으면 현저히 느려진다. 내가 개발하고 있는 사이드 프로젝트에서 위치 기반으로 데이터를 가져와야 하는데 테스트가 없으면 눈으로 전부 확인해야 한다.
디버깅을 할 때 추측이 아닌 관측을 해야한다라는 주제도 같이 얘기했다. 많은 개발자들이 나도 포함해서 디버깅을 할 때 추측을 많이 한다. 실제로 데이터가 어떠한지 봐야 하는데 빨리 해결하고자 추측을 해서 에러를 찾는다. 그러다 오히려 더 늦어진다. 실제 현상을 잘 관측해야 디버깅을 잘 할 수 있다.
중요한 것은 더 나아지려는 마음가짐이다. 현재에 만족하지 않고 더 좋은 방법이 있을 것이라는 믿음이 있어야 한다. 당장의 문제를 해결하거나 버그를 수정했더라도 더 이상 같은 버그를 만들지 않도록 하거나 더 좋은 방법으로 문제를 해결할 수 있다는 믿음을 가져야 한다.
Understanding Software - MAx Kanat-Alexander on simplicity, coding, and how to suck less as a programmer로 자신의 견해를 얘기한 것이었는데 나는 너무 설계에 대한 책인 줄 알고 봤다.
자바스크립트로 직접 만들면서 배우는 - 자료구조와 알고리즘 강의 바로 가기
실습으로 마스터하는 OAuth 2.0: 기본부터 보안 위험까지 - OAuth 2.0 강의 바로 가기
기계인간 이종립, 소프트웨어 개발의 지혜 - Git 강의 바로 가기
코드숨에서 매주 스터디를 진행하고 있습니다. 메일을 등록하시면 새로운 스터디가 시작될 때 알려드릴게요!