[Book] 소프트웨어 장인 리뷰 및 기록

산드로 만쿠소 / 길벗 출판사 / 2015.09.25

 

이 책에는 평범한 개발자가 수십 년 동안 개발 현장을 누비면서 겪은 경험과 조언이 녹아있다. 핵심 키워드로 애자일과 소프트웨어 장인 정신을 언급하고 있어서 이번 기회에 애자일이 무엇인지와 XP, 스크럼 등에 관해서 좀 더 알게 되었다.

이 책을 읽으면서 내 마음속의 열정을 솟구치게 하는 느낌을 받았고, 그저 시키는 대로 따라 하는 것이 아닌, 내 스스로와 고객을 만족시키면서 자부심을 가질 만한 코드를 짜야겠다는 생각이 든다.

대장장이가 온 힘을 다해 공예품을 만들 듯이, 개발자도 부끄럽지 않은 소프트웨어를 만들어야 한다고 저자는 말한다. 유지보수가 어렵고 알아보기 힘든 쓰레기가 아닌, 장인의 작품으로 만드는 것이 우리의 사명이라고 한다.

장인은 일종의 삶의 철학이다.
우리의 삶 전체에 걸쳐서 최선을 다해 역량을 마스터할 과업으로
소프트웨어 개발을 선택한 것이다.

 

사실, 저자가 낙관적인 이야기만 한다는 생각이 들기도 했다. 저자는 책에서 '소프트웨어 장인은 애자일 방식과 XP의 실행 관례를 습관화한다'라고 언급했는데, 실제 개발 현장에서 고객과 애자일 방식으로 소통하거나 XP의 실행 관례를 따르기엔 현실적으로 어려운 부분이 많다.

'애자일이라 쓰고 무한 수정이라고 읽는다'고 말할 정도로 고객과의 피드백이 좀처럼 진척이 되지 않을 수도 있고, 테스트 코드를 먼저 작성하는 테스트 주도 개발(TDD)이나 팀원과 함께 코딩하는 페어 프로그래밍이 한국 정서나 상황에는 맞지 않을 수도 있다.

또한 본인이 이를 추구한다고 한들, 프로젝트 전반적인 분위기가 이를 적극적으로 수용하려는 사람이 없다면 더욱 힘들 수 있다.

때문에 장인 정신의 중요성은 잘 알고 동의를 하지만, 이를 적용하려면 어려운 변수가 많기 때문에 도입이 쉽지 않은 것이 현실이다.

그렇지만 현실이 이상과 다르고 도입이 어렵다고 해서 손 놓고 포기하는 것은 아니라고 본다. 저자 역시 이를 해결하기 위한 방법을 언급하였으며, 더 나은 개발자가 되기 위해서는 이러한 고민과 갈등은 반드시 따라오는 것이라고 생각한다.

보다 나은 코드, 개발 문화와 환경을 개선하기 위해 노력하는 것이 장인의 역할이 아닐까? 곁에 두고 읽고 싶은 책이다.

 

책 요약 : 1부

아래부터는 책에서 기억하고 싶은 내용을 기록하였습니다.
참고로 조인석 님의 애자일이 무엇인가요?를 먼저 읽어보면 아래의 내용이 좀 더 이해하기 쉬울 것입니다.

애자일 연합의 탄생

2001년, 소프트웨어 업계 모임에서 익스트림 프로그래밍, 스크럼, 동적 시스템 개발 모델, 적응형 소프트웨어 개발, 피처-드리븐 개발, 실용주의 프로그래밍과 같은 방법론과 테크닉들이 발표되었다. 긴 토론 끝에 애자일 매니페스토가 창안되었고 애자일 연합이 만들어졌다.

애자일은 서로 다른 여러 맥락에 따른 방법론과 테크닉의 조합이다. 애자일은 개발팀과 기업들이 변화에 적응할 수 있도록, 변화와 관련된 위험들을 줄여준다.

절차적인 관점에서 애자일 (올바른 목표를 향해 진행 중인지?)

• 회의 방식
• 구성원 각각의 역할
• 요구사항 파악 방법
• 작업의 진척 속도 파악 방법
• 점진적/반복적으로 일할 때 취하는 방식
• 진행 상황을 개발팀 밖의 관계자(고객, 영업 등)에게 전달하는 방식
• 비즈니스 피드백 방식 등

기술적인 관점에서 애자일 (목표를 올바르게 실행하고 있는지?)

• TDD (테스트 주도 개발)
• 페어 프로그래밍
• 지속적인 통합
• 단순한 디자인 원칙 등

애자일을 따른다는 것은,

• 애자일은 피드백 루프 메커니즘을 제공해준다.
• 더 빨리, 더 짧게 피드백 루프를 만들수록 더 애자일 해진다.
• 애자일이 피드백 루프를 짧게 하고, 프로젝트의 상황을 투명하게 만드는 데는 긍정적이지만, 개발자들을 성장시키는 데는 도움이 되지 않는다.
• 애자일은 문제 자체를 해결해주지는 않는다. 애자일은 문제를 드러나게 한다.
• 프로젝트 시작 첫 주부터 '동작하는 소프트웨어'를 만든다.
• 소프트웨어 개발팀은 수평적인 계층구조로 바뀌고 있다.
• 코드를 잘 작성하는 것은 소프트웨어 프로페셔널이 가져야 할 최소한의 여건이다.
• 이밖에도 테스트, 분석, 비즈니스에 대한 이해, 커뮤니케이션 능력, 외향적인 성격이 요구된다.

애자일 매니페스토 (애자일이 추구하는 가치)

• 절차와 도구보다는 개성과 화합을
• 방대한 문서 작업보다는 동작하는 소프트웨어를
• 계약 조건에 대한 협상보다는 고객과의 협력을
• 계획을 따르는 것을 넘어서서 변화에 대처하는 것을 더 가치 있게 여긴다.

애자일 행오버

애자일 전환은 온통 절차와 도구로 끝나 버린다. 스크럼을 도입하고, 스탠딩 업 미팅을 하고, 백로그 관리 툴을 사용하는 것만으로 갑자기 소프트웨어의 품질이 더 좋아지거나 개발자들의 역량이 높아질 수는 없다. 기술적 탁월함의 개선 없이 절차만 개선하는 것은 무의미하다.

소프트웨어 장인정신, 애자일

소프트웨어 장인정신과 애자일은 서로 상호 보완적이다. 애자일 방법론들은 '올바른 일'을 하도록 돕는 것이다. 가치에 따라서 일을 이해하고, 우선순위를 정하고, 관료주의와 낭비를 줄이고, 사람들에게 권한 이양과 동기부여를 하고, 피드백 루프를 만들어준다. 그리고 소프트웨어 장인정신은 '일을 올바르게 수행'하도록 돕는 것이다. 기술적 실행 관례를 활용하고 정교하고 솜씨 있게 짠 코드의 중요성을 강조함과 동시에 코딩을 넘어서 고객의 더 많은 부분을 도울 것을 강조한다.

소프트웨어 장인정신 매니페스토

소프트웨어 장인을 열망하는 우리는, 스스로의 기술을 연마하고, 다른 사람들이 기술을 배울 수 있도록 도움으로써 프로페셔널 소프트웨어 개발의 수준을 높인다.

• 동작하는 소포트웨어뿐만 아니라, 정교하고 솜씨 있게 만들어진 작품을,
• 변화에 대응하는 것뿐만 아니라, 계속해서 가치를 더하는 것을,
• 개발적으로 협력하는 것뿐만 아니라, 프로페셔널 커뮤니티를 조성하는 것을,
• 고객과 협업하는 것뿐만 아니라, 생상적인 동반자 관계를,
• 이 왼쪽의 항목들을 추구하는 과정에서, 오른쪽 항목들이 꼭 필요함을 의미한다.

내 커리어의 주인은 누구인가

오래전에 작성했던 코드를 지금에 와서도 고칠 부분이 없어 보인다면, 그것은 그동안 배운 것이 없다는 뜻이다. 프로페셔널로 대우받기를 원한다면 프로처럼 행동해야 한다. 이는 스스로를 발전시키는 데 자신의 돈과 시간을 들여야 한다는 것이다. 언제, 무엇을 배울지를 스스로 결정해야 한다.

끊임없는 자기 계발

1. 독서, 많은 독서

• 기술 서적 : 자바, 하이버네이트, Node.js, 클로저
• 개념 서적 : TDD, 도메인 기반 개발, 객체 지향 설계, 함수형 프로그래밍, NoSQL DB 모델
• 행동양식 서적 : 애자일 방법론, 소프트웨어 장인정신, 린 소프트웨어 개발, 심리학, 철학, 경영
• 혁명적 서적 : 실용주의 프로그래머, The Mythical Man-Month, 디자인 패턴(Gof), 테스트 주도 개발, 익스트림 프로그래밍, 클린 코더, 소프트웨어 장인정신, 리팩터링

2. 블로그
3. 기술 웹사이트

끊임없는 훈련

훈련할 때는 작성 가능한 최선의 코드를 만드는 데 집중해야 한다. 테스트 하나를 만드는 데 몇 분이 걸리든 몇 시간이 걸리든 관계없다. 시간은 걱정하지 말고 변수, 메서드, 클래스들의 이름을 가장 이해하기 쉽고 의미를 포괄할 수 있도록 최선을 다해 네이밍 한다. 훈련할 때는 그 훈련이 완벽하도록 노력해야 한다.

1. 카타 : 이해는 쉽지만 해결하기에는 꽤 복잡한 문제들을 새로운 테크닉과 접근방법을 훈련하는데 활용할 수 있다. 같은 코딩 카타를 반복하더라도 매번 다른 테크닉, 다른 언어, 다른 기술, 다른 접근 방법을 사용해야 효과를 최대화할 수 있다. http://codekata.pragprog.com/

2. 펫 프로젝트 : 먼저 무엇을 배울지, 즉 어떤 실행 관례, 실행 원칙, 방법론, 기술을 배울지 정하고 그다음에 그것을 이용해서 해결할 문제를 찾는다. 매우 안전한 환경에서 시험하고, 발견하고, 배우고, 즐길 수 있는 기회를 만든다. 실제 프로젝트의 몇 가지 측면을 미리 경험할 수 있다는 점에서도 중요하다.

3. 오픈 소스 : 배우고 싶은 내용과 연관 있는 것을 찾는다. 그다음에 소스 코드를 내려받아, 실행해보고, 테스트 코드가 있다면 읽어본다. 디버깅해보고, 이용해 본다. 기여할 부분이 보인다면 작은 것부터 시작하자.

4. 페어 프로그래밍 : 페어 프로그래밍을 이용하면 새로운 내용을 빨리 배울 수 있다. 나 자신의 실제 역량을 파악하는 기회도 된다.

의도한 발견

소프트웨어 프로페셔널이 할 수 있는 최대의 실수는 자신이 모르는 것을 모른다고 받아들이지 않는 것이다. 아직 배울 내용이 많음을 인정하는 것은 성숙하다는 증거이고 마스터가 되기 위한 첫걸음이다.

보통 일의 예측했던 작업량보다, 실제로 소요된 작업량이 훨씬 많을 것이다. 이러한 문제의 영향을 최소화하는 한 가지 방법은 현재 처한 상황과 관련해 새로운 사실들을 계속 익히도록 스스로를 노출시키는 것이다. 특히 프로젝트 초반, 주요한 기능 모듈들이 아직 만들어지기 전 시점에 매우 중요하다. 생각 가능한 모든 측면에서 우리가 파악하지 못한 것을 찾아내기 위해 시간을 투자해야 한다.

모르는 것을 배우는 기회로 만들기 위해 항상 노력해야 한다. 무지에 대항하는 습관을 들이면 프로페셔널로 성장하는 데 큰 도움이 된다. 무지의 수준을 최대한 빨리 낮추면 낮출수록 업무 생산성과 효율이 매우 높아진다.

모르는 것을 배우는 기회로 만들기 위해 항상 노력해야 한다. 무엇을 모르는지를 모른다면, 최신 동향을 따라가기 위해 동료는 어떤 노력을 하고 있는지 물어보거나, 기술 커뮤니티에 참여하거나, 다른 사람에게 내가 작성한 코드를 보여주면서 피드백을 요청하자. 프로젝트에서 시도하지 않은 부분이 무엇인지 찾아보고 동료와 토론하거나 시험용 코드를 만들어보자.

'아니오'라고 말하는 방법 배우기

빠듯한 일정과 부딪혀야 하는 상황은 흔히 일어난다. 빡빡한 일정을 다루는 가장 좋은 방법은 필요한 모든 것을 분석하여 가능한 위험과 우려사항을 터놓고 관계자들과 소통하는 것이다.

불명확하거나 불편한 사실들, 걱정되는 사항들을 최대한 이른 시점에 문제 제기해야 한다. 가장 중요한 것은, 주어진 일정을 준수할 수 있을지에 대해 어느 정도 자신감을 가지고 있는지 꾸준히 표명해야 한다는 점이다.

개발자들이 일정이 너무 짧다고 이야기를 해도 관리자들이 그냥 흘려들을 때가 많다. 차드 파울러는 그저 실망시키지 않기 위해 말하는 '네'는 거짓말에 지나지 않는다고 했다. 개발자들은 협상 기술을 익혀야 한다. 다툼을 피하지 말고 부딪혀서 어려운 결정을 내릴 수 있어야 한다.

대안 제시

항상 '아니오'라고만 얘기하는 것은 프로다운 태도가 아니다. 모든 '아니오'에는 반드시 하나 이상의 대안들이 따라와야 한다. '아니오'라고 대답하기 전에 문제를 분석해서 대안이 있어야 한다. 실용적인 대안이 없을 경우, 최소한 브레인스토밍은 해보아야 한다.

어떤 때는 단지 문제를 어떻게 풀어야 할지 방법을 모를 수도 있다. 이때는 최대한 이른 시점에 그 사실을 정직하게 알려야 한다. 그리고 문제 해결을 위해서 최선의 노력을 다하고 있음을 보여주어야 한다. 진척 상황을 가능한 자주 공유하는 것이 할 수 있는 최선의 방법이다.

동작하는 소프트웨어

• 기능을 수정하거나 새로 추가할 때, 코드 베이스에 너무 많은 시간을 들여야 한다면, 개발자들이 기존 코드에 손을 대는 것을 두려워한다면 지체 없이 대응해야 한다. 
• 디버깅 스킬이 중요하기는 하지만, 자동화된 테스트를 만들고 활용하는 데 능숙한 개발자라면 코드 디버깅을 해야 하는 상황이 매우 드물다.
• 단위 테스트는 우리가 코드를 작성하는 방식에 이미 녹아있는 것이지 별도의 작업이 아니다. 테스트하지 않았다면 코드 작성을 완료했다고 할 수 없다.
• 레거시 코드를 다룰 때는 보이스카웃 규칙 '처음 발견했을 때보다 더 깨끗하게'를 지속적으로 적용해야 한다. 작은 부분씩 집중해서 한 번에 하나씩 이해해 나간다면 조금씩 개선 가능하다.
• 테스트 코드를 작성하고 메서드와 클래스를 정리하며 변수명을 적합하게 바꾸는 등 점차적으로 코드에 대한 이해도를 높이고 리팩터링을 해나간다.
• 레거시 코드를 다루는 것은 직소 퍼즐을 맞추는 것과 비슷하다.
• 무언가 마음에 들지 않는다면 바꾸어라. 그것을 바꿀 수 없다면, 그에 대한 당신의 생각을 바꾸어라. - 마리 엥겔브레이트

XP의 실행 관례

1) 자동화된 테스트 : 클릭 한 번으로 전체 시스템을 단 몇 분 만에 검증할 수 있게 해 준다.

2) 테스트 먼저 : 한 번에 하나씩만 집중할 수 있고 코드 작성 완료 후 강하게 확신할 수 있다. 테스트 코드가 준비되어 있으면 피드백 루프가 빨라지고, 오버 엔지니어링을 줄인다.

3) 테스트 주도 개발 : 가장 큰 오해가 TDD와 단위 테스트를 동일하게 생각하는 것이다. TDD는 테스트 단위가 어느 정도로 작아야 하는지 강제하지 않는다. TDD의 이름 자체에 테스트가 들어 있기는 하지만, 사실 TDD는 설계에 대한 실행 관례다. 테스트가 코딩 방향을 주도하면 복잡한 코드를 작성하는 것 자체가 어려워진다.

4) 지속 가능한 통합 : 지속적인 통합은 TDD와 함께 수행되어 피드백 루프를 단 몇 분으로 줄일 수 있다. 개발자가 코드를 올릴 때마다 전체 테스트 슈트가 실행되고 테스트가 실패하면 이메일이 모든 팀에 전달된다. 이러한 실행 관례는 '일단 멈추고 버그부터 수정한다'는 태도가 필요하다.

5) 페어 프로그래밍 : 페어 프로그래밍을 하면 코드가 작성되자마자 그 품질에 대해 피드백을 받을 수 있다. 같은 페어끼리 너무 오래 있으면 효과가 적다. 하루 이틀 단위로 주기적으로 페어를 바꾸는 것이 좋다.

6) 리팩터링 : 실용주의적인 관념 없이 리팩터링 하는 것은 대단히 위험하다. 몇 년 동안 바뀐 적이 없는 부분을 리팩터링 하는 것은 의미가 없다. 리팩터링은 더 자주 변경되는 부분을 대상으로 시작해야 한다. 보이스카웃 규칙은 모든 것이 아니라, 해당 부분을 이해하여 변경할 필요가 있을 때 적용해야 한다.

실용주의

무언가를 절대적인 진리로 바라보는 것은 바람직하지 않다. 항상 우리가 무엇을 하고 있고 그것을 왜 하고 있는지 질문해야 한다. 지금 하는 방법보다 더 나은 다른 방법이 없는가? 우리가 선택한 실행 관례가 우리 프로젝트에 적합한가? 그 실행 관례의 가치는 무엇인가? 무언가 다른 것을 시도해볼 시점인가?

어떤 실행 관례가 다른 실행 관례보다 더 나은지 알아보는 가장 좋은 방법은 프로젝트에 어떤 가치를 주는지, 피드백 루프가 얼마나 긴지 비교해보는 것이다. 기억해야 할 것은 꼭 이렇게 해야만 한다라는 법은 없다는 점이다. 특정 실행 관례가 더 이상 우리에게 가치를 주지 못한다면 그 실행 관례를 버려야 한다. 소프트웨어 장인으로서, 우리의 일에 항상 최선의 기술, 도구, 절차, 방법론 그리고 실행 관례를 선택할 수 있도록 개방적인 사고방식을 가져야 한다.

결단과 집중

• 익숙하고 편한 것에서 벗어나 새로운 것을 공부하고 기술적 지식을 확장한다. 예를 들어 새로운 프로그래밍 언어나 기술들을 배운다.
• 지역 커뮤니티에 정기적으로 출석하거나 행사에 참여한다.
• 다른 개발자, 비즈니스맨들과 교류한다.
• 새롭게 배운 것, 지금 하고 있는 것들에 대해 블로깅한다.
• 오픈 소스 프로젝트에 참여한다.
• 프로젝트를 만들고 공개한다.
• 콘퍼런스에 참석한다.
• 콘퍼런스에서 연사로 나선다.

책 요약 : 2부

인재 채용 : 효과적인 선별 조건의 정의

• Github 계정
• 블로그
• 오픈 소스 활동
• 기술 커뮤니티나 사용자 그룹 활동 내역
• 펫 프로젝트 내용
• 트위터 계정
• 좋아하는 기술서적 목록
• 참석했거나 발표했던 콘퍼런스

생산적인 파트너십을 알아보는 방법

1) 회사 입장에서의 관점

• 항상 질문을 많이 하는 지원자를 우선시하는 것이 좋다.
  • 어떤 식으로 일하는지, 무엇을 성취하길 원하는지, 당면한 문제가 무엇인지 등에 대해 면접 때조차 아무런 질문도 하지 않은 사람이, 실제 업무 현장에서 갑자기 적극적으로 질문을 하리라고 기대할 수 있을까?
• 과거 수행한 프로젝트나 업무, 기술, 또는 스스로 성취한 사항들을 이야기할 때 얼마나 열정적이고 애착을 보이는가?
• 실패 사례에 대해서 어떻게 표현하는가?
• 실패에 대해서 책임감을 느끼는가 아니면 남 탓을 하는가?
• 잘못된 상황을 정상으로 되돌리기 위해 무엇이든 노력해본 적이 있는가?
• 이전 업무에서 불평불만 대신 그 상황을 개선하기 위해 스스로 노력한 적이 있는가?
• 어떤 종류의 업무 환경을 찾고 있는가?
• 회사에서 그러한 환경을 제공해줄 수 있는가?

2) 지원자 입장에서의 관점

• 면접관은 누구인가? (프로젝트 관리자? 개발자? 팀 리더? 아키텍트?)
• 얼마나 많은 지원자들을 면접보고 있나?
• 원샷 면접인가 다단계 면접인가?
• 지원자에게 어떤 질문이 주어지고 있나?
• 특정된 질문인가 개방형 질문인가?
• 면접관이 기술적 질문에 대해 yes/no 단답형을 좋아하는가, 좀 더 상세하게 지원자의 생각을 파보려 하는가?

바람직한 면접 방법

좋은 면접은 자유 토론과도 같아야 한다. 소프트웨어 개발과 관련하여 지식과 정보를 교환하고, 기술/도구/방법론들에 대해서도 의견을 나누어야 한다. 이런 종류의 면접은 지원자 입장에서 미리 준비할 수 있는 성격의 것이 아니다. 그래서 지원자의 실제 경험을 알아낼 수 있다.

1) 올바른 집중

• 우리의 핵심 가치는 무엇인가?
• 우리에게 필요한 주요 기술은 무엇인가?
• 더 잘하고 싶은, 더 나아지고 싶은 것들은 무엇인가? 등
• 새로운 사람을 채용하기 전에 이러한 질문들에 스스로 대답을 준비해야 한다. 회사의 입장에서 더 중요하고 가치 있는 것에 집중해야 한다.

2) 마인드 맵핑 대화

• 잘 작성된 소프트웨어란 어떤 것이라고 생각합니까? 프로젝트에서 가장 어려운 부분은 무엇이라고 생각합니까? 와 같은 개방형 질문에는 유지보수, 테스트, 가독성, 성능, 요구사항 등과 관련된 답변이 뒤따른다.
• 각 항목은 마인드 맵의 노드가 되어 지원자와 면접관이 대화를 나눌 수 있다.

3) 페어 프로그래밍 면접

• 어떤 테스트를 자성할지 얼마나 빨리 결정하는가? (경험 수준)
• 개발 도구(IDE, 언어, 테스팅/목업 프레임워크, 단축키 등)에 얼마나 익숙한가?
• 클래스, 메서드, 변수 네이밍을 얼마나 적합하게 하는가?
• 코드를 얼마나 깨끗하고 명료하게 작성하는가?
• 면접관이 제안이나 조언을 할 때 어떻게 반응하는가?
• 지원자가 어떤 방식으로 생각을 전개하는가?
• 문제 해결만이 아니라 문제 해결을 위한 방법과 과정에도 얼마나 주의를 기울이는가?

4) 개인 컴퓨터를 지참한 면접

• 지원자가 좋아하는 도구가 무엇인지 알 수 있고 소중한 면접 시간을 아낄 수도 있다.
• 한 가지 재미있는 방법은 지원자에게 Github 프로젝트를 클론 하고 작업하게 하는 것이다.
• Git에 익숙한지? Git이 이미 설치되어 있는지? 컴퓨터 설정이 어떻게 되어 있는지? 어떤 도구를 선호하는지? 프로젝트를 금방 시작할 수 있는지? 테스팅/목업 프레임워크를 이미 모두 가지고 있고 사용할 수 있게 설정되어 있는지?

배움의 문화 만들기

• 북 클럽에 가입하기
• 테크 런치 진행하기
• 그룹 토론회에 참여하기
• 업무 교환하기
• 얼마 동안만 업무 교환하기
• 그룹 코드 리뷰하기
• 코딩 실습하기
• 사용할 기술은 가능한 자유롭게 선택하기
• 내부 학습모임 만들기
• 회사에서의 펫 프로젝트 시간을 허용하기
• 외부 기술 커뮤니티와 교류하기

아무도 참여하려 하지 않는다면

• 모범을 보여라
• 관심을 보이는 사람들에게 집중하라
• 강제하지 마라
• 모두를 변화시키려 들지 말라
• 모임에 대한 약속을 제때 하라
• 허락을 구하지 마라
• 투덜대지 마라
• 리듬을 만들라

기술적 변화의 실행 준비

• 단순함을 추구해야 한다.
• 상대방의 언어로 말해야 한다.
• 말할 내용에 대해 스스로 제대로 이해하고 있어야 한다.
• 상대방을 존중해야 한다.
• 경청하는 법을 배운다.

기술적 변화를 시작하는 방법

• 신뢰를 쌓으라
• 전문성을 확보하라
• 모범을 보여 사람들을 이끌라
• 신중하게 싸울 곳을 정하라
• 점진적으로 반복, 관찰, 수용하라

당신의 주변을 바꾸고 싶다면, 두려움을 버려야 한다. 준비하고, 연습하고, 독서하고, 공부해서 스스로 도달할 수 있는 최고의 개발자로 거듭나야 한다.

실용주의 장인정신 : 단순한 설계를 위한 4가지 법칙

1. 모든 테스트의 통과 : 모든 테스트를 통과해야 한다.
2. 명료성의 최대화 : 명료하고, 충분히 표현되고, 일관되어야 한다.
3. 중복의 최소화 : 동작이나 설정에 중복이 있어서는 안 된다.
4. 구성요소의 최소화 : 메서드, 클래스, 모듈의 수는 가능한 적어야 한다.

디자인 패턴

디자인 패턴은 분명 우리가 활용해야 할 도구 중 하나다. 무조건 사용해야 할 도구는 아니다. 레이어를 추가하거나 추상화를 위해 코드를 리팩터링 할 때 한걸음 더 나아가서 해당 문제에 흔하게 적용되는 패턴을 찾아서 적용할 수도 있다. 하지만 패턴이 먼저가 아니다. 내가 좋아하는 패턴에 문제를 끼워 맞추기 전에, 문제에 적합한 리팩터링을 단순한 설계와 SOLID 원칙을 따라서 먼저 시도해야 한다. 그다음에 리팩터링으로 만들어진 솔루션이 특정 디자인 패턴과 거의 동일하다면 그 패턴을 지향하도록 리팩터링 할 수도 있다.

범용 코드는 확장성이 더 좋을지는 몰라도 특정된 코드보다 더 복잡하다. 무조건적으로 범용 코드를 추구해서는 안 된다. 대신 주어진 문제에만 특정된 코드로 먼저 솔루션을 찾은 후 나중에 필요한 상황이 생겼을 때 범용화하는 것이 좋다.

장인의 길 : 열정

• 소프트웨어 장인은 소프트웨어 개발과 자신의 직무에 열정적이다.
• 문제를 단순한 방법으로 푸는 데 열정적이다.
• 배우고 가르치고 공유하는 데에도 열정적이다.
• 소프트웨어 산업이 진화하도록 돕는 데도 열정적이다.
• 그들의 코드를 공유하고, 초보 개발자들을 멘토링 하고, 블로그/책/동영상/대화 등을 통해 그들의 경험을 공유하는 데도 열심이다.
• 기술 커뮤니티 활동에도 열정적이다.
• 뿐만 아니라 소프트웨어 장인은 겸손하다. 항상 더 나은 개발자에게 무언가를 배울 자세가 되어 있고, 경험이 적은 개발자들을 돕기를 주저하지 않는다.

단순히 좋은 코드를 작성하고 비즈니스 가치를 전달하는 것만으로는 좋은 개발자는 될 수 있지만 장인은 될 수 없다. 장인은 일종의 삶의 철학이다. 우리의 삶 전체에 걸쳐서 최선을 다해 역량을 마스터할 과업으로 소프트웨어 개발을 선택한 것이다.

장인이 된다는 것은 새로운 것에 대해 호기심을 가지고 실험한다는 것과 같은 의미다. 장인은 특정 도구, 개발 언어, 프레임워크에 독단적인 고집을 부리지 않는다 항상 주어진 문제에 가장 적합한 도구를 찾고 단순한 해결책을 추구한다.

진정한 소프트웨어 장인은 가장 먼저, 코드 작성이 아니라 문제 해결에 집중한다. 코드를 짤 때는 높은 품질의 코드를 작성하는 데 집중한다. 테스트 가능하고 쉽게 이해할 수 있으며 수월하게 유지 보수할 수 있는 코드를 작성하는 데 집중한다. 장인은 자신이 떠나고 난 후 스스로 부끄러운 일로 떠올리는 상황을 만들지 않는다.

여정과 이정표

• 나의 커리어로부터 나는 무엇을 원하는가?
• 그것을 성취하기 위한 다음 단계는 무엇인가?
• 이 일은 나의 커리어 방향과 합치하는가?
• 내가 이 회사에 줄 수 있는 가치의 양은 얼마나 되는가?
• 그러한 투자에 대한 이익은 무엇인가?
• 그러한 투자는 대략적으로 얼마 동안 지속되어야 하는가?
• 내가 되고자 하는 프로페셔널에 이르는 데 이 일은 어떻게 도움이 되는가?
• 이 일에서 나는 자율성, 통달, 목적의식을 가질 수 있나?
• 나의 고용주와 생산적인 동반자 관계를 맺을 수 있나? 양측 모두 가치 얻고 행복할 수 있나?