개요 및 감상

가벼우면서도 재미있고, 감명 깊게 읽었다.

  • 저자인 산드로 만쿠소(Sandro Mancuso)는 런던 소프트웨어 장인 커뮤니티(LSCC; London Software Craftsmanship Community)를 설립한 사람.
  • 소프트웨어 장인을 정의하고, 장인이 나아갈 길, 장인을 채용하는 방법 등을 제시한다.

인용

이 코드가 얼마나 무례한지 알고 있습니까?

  • 저자 서문 중에서

1990년대에는 다른 사람이 알아볼 수 없는 난해한 코드를 짤 수 있는 사람이 실력있는 개발자로 통했다. "와우! 그는 똑똑한 개발자가 틀림없어. 그 사람 코드는 무엇을 하는 코드인지 전혀 감을 잡을 수가 없거든." 나 역시 내가 얼마나 똑똑한지 보이려고 난해한 코드들을 조금 집어 넣었다. 나무르는 순간, 그 코드가 무엇을 하는지 알아냈다. 나는 내 기분을 띄워줄 말을 기대했다. "이 코드가 얼마나 무례한지 알고 있습니까?" 그는 조용히 말했다. "많은 팀과 개발자들이 같은 코드 베이스에서 아주 큰 시스템을 만들고 있습니다. 모든 개발자들이 이런 식으로 으스대려고 난해한 코드를 만들면 코드를 이해하기가 얼마나 어려워질지 생각해봤나요? 수천 라인, 아니 수백만 라인의 코드가 이런 식이라고 상상해보세요"

매니페스토

  • 3장 소프트웨어 장인정신. 67쪽.

소프트웨어 장인을 열망하는 우리는, 스스로의 기술을 연마하고, 다른 사람들이 기술을 배울 수 있도록 도움으로써 프로페셔널 소프트웨어 개발의 수준을 높인다. 이러한 일을 하는 과정에서 우리는 다음과 같은 가치들을 추구한다.

동작하는 소프트웨어 뿐만 아니라, 정교하고 솜씨 있게 만들어진 작품을,
변화에 대응하는 것뿐만 아니라, 계속해서 가치를 더하는 것을,
개별적으로 협력하는 것뿐만 아니라, 프로페셔널 커뮤니티를 조성하는 것을,
고객과 협업하는 것뿐만 아니라, 생산적인 동반자 관계를,

이 왼쪽의 항목들을 추구하는 과정에서, 오른쪽 항목들이 꼭 필요함을 의미한다.

고객과 협업하는 것뿐만 아니라, 생산적인 동반자 관계를

  • 3장 소프트웨어 장인정신. 73쪽.

고객이 속한 산업의 본질이 소프트웨어 개발이 아닌 다른 것인 때가 많다. 이때는 소프트웨어 프로젝트가 성공하도록 돕는 것이 전적으로 우리들이 해야 할 일이다. 그것이 우리가 대가를 받는 이유다. 코드와 관련된 일이 아니면 나의 일이 아니라고 생각하는 개발자는 진정한 소프트웨어 장인이라고 할 수 없다.

전형적인 채용 공고의 문제점

  • 9장 인재 채용. 180쪽.

투자 은행들의 채용 공고는 틀에 박은 듯이 다들 비슷하다. 한 은행에서 시스템을 엉망으로 개발하고 떠난 개발자가 또 다른 은행에서 쉽게 일자리를 구할 수 있다는 이야기도 된다.
…
이 공고에서는 전산관련 학위, 보유 기술 목록(그 기술을 정말 잘 활용할 능력이 있는지는 알 수가 없다) 그리고 투자 은행에서의 업무 경력을 요구하고 있다. 이 목록에 합치만 되면 더 대우가 좋은 은행으로 얼마든지 옮겨 다닐 수 있다.
…
앞의 채용 공고 직무 요건들은 잠재적으로 실력있는 개발자 다수를 제외시킨다. 투자 은행에서 근무한 적이 있고, 전산학 학위가 있으면서 나열된 모든 기술들을 경험해본 사람으로 한정시키면 그 중에서 소프트웨어 개발자로서 유능한 사람의 숫자가 얼마 남지 않는다.
…
이 채용 공고의 요구 조건 목록은 엉뚱한 것에 집중하고 있고 회사의 가치와 후보자에게 기대되는 태도에 대해서는 아무것도 말하지 않는다. 회사에서 내보내고 싶은 사람과 같은 부류의 사람을 또 채용하게 될 수도 있다.

무서운 이야기

13장 배움의 문화. 242쪽.

고객사의 요구사항은 매우 명확했다. "그냥 테스트만 작성하면 됩니다. 목표는 테스트 커버리지를 전체 코드의 70%까지 달성하는 것입니다. 거기까지 완료하면 그 커버리지 아래로 떨어지지 않도록 테스트를 유지보수하기만 하면 됩니다." 테스트를 작성하면서 코드 베이스의 미묘한 동작들이 버그인지 원래 의도한 것인지 아리송한 상황이 꽤 많았다. 기존의 클래스와 메서드들이 전체적인 설계 관점에서 올바른지도 전혀 알 수 없었다. 우리는 그 코드를 작성한 고객사의 개발자들과 이야기를 해보려 했지만 그 부분은 계약 조건에서 배제되어 있었다. 고객사의 개발자들은 항상 바쁜 데다가 우리와 이야기하는 것에 흥미를 보이지도 않았다.
더 최악인 것은, 고객사의 개발자들은 코드 베이스를 변경할 때 테스트 코드를 업데이트하지도, 새로운 테스트를 작성하지도 않았다. 그래서 고객사의 최신 코드를 가져올 때마다 어김없이 테스트가 망가졌다.
원래 그게 맞는지 틀린지도 모른 채 맹목적으로 테스트를 끼워 맞추는 개발을 시작한지 몇 달 후 70%의 테스트 커버리지에 도달했다. 몇 주가 지나 그 고객사는 기뻐하며 계약을 종결했다.
그 프로젝트(프로젝트라고 부를 수 있는지 잘 모르겠다)가 끝나고 한참 후, 우리는 관리자에게 도대체 그 프로젝트의 정체가 무엇인지 물었다. 그 해에 고객사의 고위 기술 담당이 테스트 커버리지를 70%로 올리는 것을 당해년도 팀 업무 목표 중 하나로 설정했고 팀의 보너스가 그 목표를 달성했느냐 여부에 직접적으로 영향을 받았다. 그 목표 달성 부분을 그냥 아웃소싱했던 것이었다.

오렌지 주스 테스트

  • [[orange-juice-test]]{오렌지 주스 테스트} 참고.