소프트웨어 장인

소프트웨어 장인 책을 요약한 내용입니다.

Intro

겸손해져야 한다. 일을 끝내는 것 자체로는 부족하다. 그 일을 어떻게 하느냐가 더 중요하다. 자신이 하는 일 자체에 주의를 기울이자.

일을 어떻게 했느냐는 일을 해낸것만큼이나 중요하다.

LSCC, London Software Craftsmanship Community

애자일

"'애자일을 따른다는 것은' 새로운 환경에 성공적으로 적응하고 있다는 의미다."

• 애자일은 개발팀과 기업들이 변화에 적응할 수 있도록 변화와 관련도니 위험들을 줄여준다.

• 더 빨리, 더 짧게 피드백 루프를 만들수록 더 애자일해진다.

애자일 매니페스토의 원칙들

절차적인 관점

팀에 정말로 중요한 것, 비즈니스에 가치가 있는 것에 집중하여 올바른 목표를 향해 진행 중인지 확인

• 회의 방식

• 구성원 각각의 역할

• 요구사항 파악 방법

• 작업 진척 속도 파악 방법

• 점진적/반복적으로 일할 때 취하는 방식

• 진행 상황을 개발팀 밖의 관계자(고객, 영업 등)에게 전달하는 방식

• 비즈니스 피드백 방식

기술적인 관점

소프트웨어의 품질에 집중하여 팀이 결과물을 올바르게 만들어 가는지, 목표한 것을 올바르게 실행하고 있는지 안심할 수 있게 돕는다.

• 개발, 확장, 유지보수, 출시.. 에서 겪는 어려움들에 대해 특정한 기술적 관례나 기술 자체를 매우 구체적으로 가이드

  • TDD

  • 페어프로그래밍

  • 지속적인 통합

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

기술적 탁월함의 개선 없이 절차만 개선하는 것은 무의미하다.

• 애자일은 기업의 반응속도를 높이고 기민하게 하며, 기업이 올바른 일을 하도록 돕는다.

• 소프트웨어 장인정신은 개발자와 기업들이 일을 올바르게 수행하도록 돕는다.

소프트웨어 장인정신

• 자신이 하는 일에 주인의식을 가지고 프로페셔널하게 행동하고, 고객이 원하는 것이 무엇이든 달성할 수 있도록 돕는 것

• 다른 개발자들에게 배우고 자신의 지식을 나누며, 경험이 부족한 개발자들을 멘토링하는 것

• 시켜야만 일하는 역량 미달의 노동자가 아니라 소프트웨어 프로페셔널의 수준을 높여, 프로의 모습으로 일하는 소프트웨어 개발자를 지향

  매니페스토

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

  동작하는 소프트웨어뿐만 아니라, 정교하고 솜씨 있게 만들어진 작품을.

  • 좋은 소프트웨어라면 개발자가 쉽게 이해할 수 있어야 한다.

  • 높은 커버리지에 신뢰할 수 있는 테스트가 가능해야 하고, 명료하고 단순한 디자인과 비즈니스 용어로 잘 기술된 코드여야 한다.

  • 소스 코드는 예측가능하고 유지보수될 수 있는 상태여야 한다.

  • 개발자들이 애플리케이션을 수정하는 일을 부담스러워해서는 안 된다.

  변화에 대응하는 것뿐만 아니라, 계속해서 가치를 더하는 것을.

  • 신규 기능을 추가하거나 버그 수정만을 뜻하지 않음

  • 코드를 깔끔하게 정리하고 구조를 개선하며 확장성을 높이고, 테스트 가능하게 하고, 쉽게 유지보수할 수 있게 하는 것을 포함

  • 소프트웨어가 오래될수록 고통과 비용이 아닌 그 가치가 커져야 한다.

  • 코드를 처음 발견했을 때보다 더 깨끗하게 관리하자.

  개별적으로 협력하는 것뿐만 아니라, 프로페셔널 커뮤니티를 조성하는 것을.

  • 소프트웨어 장인은 항상 열정적으로 자기발전을 추구하고, 다음 세대의 장인을 준비시킬 책임이 있다.

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

  • 생산적인 동반자 관계는 어떤 순간이든 고객에게 가치를 제공하는 것을 의미한다.

  • 코드와 관련된 일이 아니면 나의 일이 아니라고 생각하는 개발자는 진정한 소프트웨어 장인이라고 할 수 없다.

소프트웨어 장인의 태도

• 오래 전에 작성했던 코드를 지금에 와서도 고칠 부분이 없어 보인다면, 그것은 그동안 배운 것이 없다는 뜻이다.

• 고객을 만족시키기 위한 투자는 스스로 해야 한다.

• 변화에 적응하고 계속해서 역량을 증진시키는 것은 소프트웨어 장인으로서 성공적인 커리어를 갖기 위한 열쇠다.

끊임없는 자기계발

독서, 많은 독서

특정 주제나 기술을 깊이 이해해야 할 때는 책만한 것이 없다.

• 특정 기술에 대한 서적

  • Java, Hibernate, Node.js, Clojure ..

• 특정 개념에 대한 서적

  • TDD, DDD, 객체 지향 설계, 함수형 프로그래밍, NoSQL 데이터베이스 모델 ..

• 행동양식에 대한 서적

  • 애자일 방법론, 소프트웨어 장인정신, 린 소프트웨어 개발, 심리학, 철학, 경영 ..

• 혁명적(or 고전) 서적

  • 실용주의 프로그래머, The Mythical Man-Month, 디자인 패턴, 테스트 주도 개발, 익스트림 프로그래밍, 클린 코더, 소프트웨어 장인정신, 리펙토링 ..

블로그

블로그를 이용하면 항상 최신 정보를 습득할 수 있다.

• 인스타페이퍼, 애버노트 ..

기술 웹사이트

기술 관련 웹사이트들도 시장의 최신 동향을 알아보기에 좋은 수단이다.

팔로우할 리더 찾기

그 기술을 진보시키고 더 나은 사용 방법들을 개발하고 있는지, 관련 업계를 어떤 사람이 움직이고 있는지 알아 두는 것이 좋다.

소셜미디어

트위터는 정보를 모으는 데 매우 유용하다.

끊임없는 훈련

훈련을 할 때는 그 문제를 '어떻게' 해결하는지가 중요하다.

• 더 많이 훈련할수록 더 편안해지고 별도의 주의 집중과 의식적인 노력이 없어도 자연스럽게 할 수 있게 된다.

• 훈련할 때는 그 훈련이 완벽하도록 노력해야 한다.

카타

• 소프트웨어 카타는 작은 훈련용 코딩들을 의미

• 훈련을 통해 우리가 익숙하지 못한 새로운 테크닉이나 기술에 능숙해질 수 있다.

• 같은 코딩 카타를 반복하더라도 매번 다른 테크닉, 다른 언어, 다른 기술, 다른 접근 방법을 사용해야 효과를 최대화할 수 있다.

펫 프로젝트

• 취미생활과도 비슷한 나만의 소프트웨어 프로젝트

• 어떤 실행 관례, 실행 원칙, 방법론, 기술을 배울지 정하고 그 다음에 그것을 이용해서 해결할 문제를 찾는다.

• 실제 프로젝트의 어떤 측면이든 배울 수 있다.

오픈소스

• 소스 코드를 내려받아, 실행해보고, 테스트 코드가 있다면 읽어본다. 디버깅해보기, 이용해보기, 기여할 부분이 보이면 작은 것부터 시작하자.

• 훌륭한 개발자들이 어떻게 일하는지 체험할 수 있다.

페어 프로그래밍

• 팀의 정신적 에너지가 높아지고 개발자들이 서로 좀더 친밀해질 수 있다.

• 새로운 내용을 빨리 배울 수 있다.

• 나 자신의 실제 역량을 파악하는 기회가 된다.

사회 활동: 다른 개발자들과 어울리기

사회적으로 교류할 수 있는 인적 네트워크를 형성하는 것은 성공적인 커리어를 위해 상당히 중요하다.

• 지역 사용자 그룹이나 기술 커뮤니티에 가입하고 행사들에 참여하면 인적 네트워크를 쉽게 만들 수 있다.

• 무언가를 배우고 아이디어를 나누기에 더할 나위 없이 좋은 방법이다.

의도한 발견

아직 배울 내용이 많음을 인정하는 것은 성숙하다는 증거이고 마스터가 되기 위한 첫걸음이다.

• 현재 처한 상황과 관련해 새로운 사실들을 계속 익히도록 스스로를 노출시키자.

• 모르는 것을 배우는 기회를 만들기 위해 항상 노력해야 한다.

• '무지'라는 장애요소를 제거하는 것은 우선순위에서 높이 두어야 한다.

• 무지에 대항하는 습관을 들이면 프로페셔널로 성장하는 데 큰 도움이 된다.

일과 삶의 균형

커리어를 위해 업무 외 시간에 학습과 훈련을 게을리하지 않는 것이 중요하다.

• 한 주에 하루 정도는 출근 전에 카페에서 한 두 시간 동안 자기계발을 해보자.

• 사용자 그룹이나 기술 커뮤니티가 근처에 있다면 참여해보자.

• 혼자서 학습해서 배울 수 있는 것에는 한계가 있다.

• 침대에서 평소보다 30분 정도 일찍 들어서 잠들기 전에 독서를 하거나, 블로그를 보거나, 기술 관련 스크린 캐스트들을 보자.

집중 - 뽀모도로 기법

• 시간을 쓰기 전에 그 시간을 어디에 쓸지 미리 정해두는 것이 좋다.

• 뽀모도로 기법을 적용하면 효과적이다.

  • 어떤 일을 할지 정하자.

  • 뽀모도로(타이머)를 25분에 맞추자.

  • 타이머가 끝날 때까지 그 일을 하자.

  • 짧게 쉬자(보통 5분정도)

  • 매 4회의 '뽀모도로'마다 길게 쉬자.(15~30분)

균형

• 무엇을 하든지 페이스를 유지하는 것이 중요하다.

• 좋은 인적 네트워크를 가지고 시장이 요구하는 기술을 습득하고 있다면, 프로페셔널로서의 삶에 대해서 크게 걱정하지 않아도 된다.

성공적인 커리어를 가지려면 결단력과 열정이 필요하다.

배움과 훈련이 멈추는 순간 우리의 커리어도 멈춰버린다.

우리는 모두 정확히 같은 만큼의 시간이 주어진다. 차이점은 우리가 그 시간을 어떻게 쓰느냐일 뿐이다.

영웅, 선의 그리고 프로페셔널리즘

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

• 이미 불가능하다고 알고 있는 것에 대해 '해보겠다'라고 말하지 말아야 한다.

프로답게 행동하기

• 빡빡한 일정으르 다루는 가장 좋은 방법은 필요한 모든 것을 분석하여 가능한 위험과 우려사항을 터놓고 관계자들과 소통하는 것이다.

• 불명확하거나 불편한 사실들, 걱정되는 사항들을 최대한 이른 시점에 문제제기해야 한다.

• 그저 실망시키지 않기 위해 말하는 '네'는 거짓말에 지나지 않는다.

• 프로페셔널리즘은 나 자신과 팀 동료들 그리고 관리자들과 고객들에게 정직함을 의미한다.

• 다툼을 피하지 말고 부딪혀서 어려운 결정을 내릴 수 있어야 한다.

대안 제시

항상 '아니오'라고만 얘기하는 것은 프로다운 태도가 아니다.

• 모든 '아니오'에는 반드시 하나 이상의 대안들이 따라와야 한다.

• 우리가 '아니오'라고 대답해야 하는 상황에서도 항상 '네'라고 말할 방안을 탐색해야 한다.

• 문제를 어떻게 풀어야 할지 방법을 모른다면, 진척 상황을 가능한 자주 공유하는 것이 할 수 있는 최선의 방법이다.

깨어있는 관리자

• 훌륭한 관리자들은 자신이 개발팀의 일부이며 개발자들과 함께 공동의 목표를 위해 일한다는 것을 이해한다.

• 문제를 숨기지 않고 드러내는 태도는 모두가 하나의 팀으로서 공동의 목표를 위해 일하고 있다는 징표다.

• 좋은 관리자는 외부의 압력으로부터 개발자를 보호하고 팀이 가진 장애요소들을 제거한다.

• 팀원들이 편안한 마음으로 자신감을 갖고 일할 수 있도록 해준다.

• 팀을 건강하고 행복하고 단결되게 하는 것은 관리자의 직무다.

동작하는 소프트웨어

동작하는 소프트웨어만으로는 부족하다

정원 돌보기

프로그래밍은 집을 짓는다기보다는 정원을 돌보는 것에 더 가깝다 - 실용주의 프로그래머

• 코드는 정원처럼 지속적인 유지보수가 필요하다.

• 기본적이고 정기적인 유지보수만으로도 정원을 훌륭하게 가꿀 수 있다.

보이지 않는 위협

• 비즈니스의 기민함과 투자 효율을 높이기 위해서는 다른 무엇보다도 코드의 품질이 가장 중요하다.

• 장인은 꾸준히 코드 베이스를 돌보고 두려움 없이 빠르게 리펙토링한다.

• 전체 애플리케이션을 몇 분만에 테스트할 수 있는 자동화 테스트를 구축하고 활용할 줄 안다.

• 코드의 품질이 프로젝트의 성공을 보증하지는 못하더라도 실패의 핵심 요인이 될 수 있다.

시간에 대한 잘못된 인식

• 단위 테스트는 우리가 코드를 작성하는 방식에 이미 녹아있는 것이지 별도의 작업이 아니다.

• 우리가 공식적인 작업 일정표에 무언가를 올려 놓는다는 것은 제품 오너가 그중 중요하지 않다고 생각하는 것을 삭제할 수 있는 권리를 준다는 것과 같다.

• 항상 프로젝트에 다른 사람들도 있다는 사실을 인식하고 전체 프로젝트에 미치는 영향을 감안하여 책임있게 행동해야 한다.

효율적인 시간 활용

• 언제, 어떤 코드든 쉽게 테스트하고 통합할 수 있도록 주변을 잘 정리해야만 한다.

• 수동 테스트, 디버깅, 오래 걸리는 빌드, 까다로운 애플리케이션 배포, 복잡한 프로젝트 개발 환경 설정같은 것에 시간을 덜 빼앗길수록 애플리케이션의 품질에 더 신경을 쓸 수 있고 고객을 행복하게 할 수 있다.

레거시 코드

태도는 큰 차이를 가져올 수 있는 작은 요소다 - Winston Churchill

태도의 변화

무언가가 마음에 들지 않는다면 바꾸어라.

그것을 바꿀 수 없다면, 그에 대한 당신의 생각을 바꾸어라. - Mary Engelbreit

• 무언가 나아지길 원한다면 그에 맞는 행동을 취해야 한다.

• 레거시 코드를 재미있고 도전적인 문제로 바라보자.

• 일을 즐길 수 있느냐 없느냐는 우리의 태도에 달려 있다.

기술적 실행 관례

올바른 일 vs 올바른 실행

• 애자일 방법론은 빠르고 짦은 피드백 루프를 제공하여 우리가 '올바른 일(Right Things)`을 실행하고 있는지 점검하도록 도와준다.

상황 논리

• XP 실행 관례에는 테스트 주도 개발, 페어 프로그래밍, 리펙토링, 단순한 디자인, 지속적인 통합 등..

• 일하는 방식을 바꾸기 전에 우리가 어떤 상황에 놓여 있는지 파악하는 것은 중요

실행 관례와 가치

• XP 실행 관계들은 소프트웨어의 품질, 즉 일을 올바르게 수행하는 관점에서 피드백 루프를 단축시킬 수 있는 여러 방법을 제공

• 실행 관례의 도입 자체를 관리자나 팀 구성원들에게 설득하려 하지 말고 현재 일하는 방식과 비교해서 그것이 가져올 이익에 집중해야 한다.

• 빠른 피드백 루프, 요구사항과 비용에 대한 더 나은 이해, 지식 공유, 줄어드는 버그, 전체적으로 자동화되고 릴리즈가 빨라지는 일들이 기술적 실행 관례를 도입함으로써 얻을 수 있는 가치들

XP 실행 관례의 일부를 살펴보자.

• 자동화된 테스트

  • 클릭 한 번으로 전체 시스템을 단 몇 분만에 검증

  • 실제 측정 가능한 비즈니스적 가치를 가져다 준다

• 테스트 먼저

  • 테스트 코드를 먼저 작성하기

  • 아이디어를 생각해내는 데도 도움이 되고 한 번에 하나씩만 집중이 가능

• 테스트 주도 개발

  • 설계에 대한 실행 관례

  • 정확히 요구사항만큼만 만족시키므로 테스트로 규정된 부분만 작성

  • 코드가 복잡하고 방대하면 테스트 자체가 어렵기 때문에 설계를 재검토하고 단순하게 리펙토링하는 긍정적인 원인을 제공

  • 코드의 설계, 단순성, 유지보수 용이성에 대해 피드백이 빠르고, 코드에 대한 살아 움직이는 문서 역할

• 지속가능한 통합

  • 지속적인 통합은 TDD와 함께 수행되어 오랜 시간의 피드백 루프를 단 몇 분으로 줄일 수 있음

  • 일단 멈추고 버그부터 수정한다는 태도가 필요

• 페어 프로그래밍

  • 코드가 작성되자마자 그 품질에 대한 피드백을 받을 수 있음

  • 주기적인 페어의 변경은 전체 시스템에 대한 이해도나 개발자의 스킬이 팀 차원에서 누적되어 올라간다

• 리펙토링

  • 엉망인 코드가 많을수록 엉망인 코드가 늘어나는 속도도 빨라진다

  • 지속적으로 코드를 리펙토링하면 이러한 위험이 줄어든다

  • 더 자주 변경되는 부분을 대상으로 시작하고, 해당 부분을 이해하여 변경할 필요가 있을 때 적용하자

  • 유지보수가 쉬운 깨끗한 코드는 개발 속도를 높이고 버그가 만들어질 가능성을 낮춘다

실용주의

실용주의는 소트웨어 장인이 가져야 하는 최선의 역량 중 하나

• 어떤 실행 관례가 더 나은지 알아보는 가장 좋은 방법은 프로젝트에 어떤 가치를 주는지, 피드백 루프가 얼마나 긴지를 비교해 보는 것

• 소프트웨어 장인으로서 우리의 일에 항상 최선의 기술, 도구, 절차, 방법론 그리고 실행 관례를 선택할 수 있도록 개방적인 사고 방식을 가지자

• 실행 관례에 대한 도입을 이갸기하기 전에 먼저 우리가 이루려는 것이 무엇인지 논의해보자

길고 긴 여정

편안하고 익숙한 상태에서 벗어나 나를 발전시키고 배울 수 있는 기회를 지속적으로 찾아보자

결단과 집중

어디로 가고 있는지 모르고 있다면, 결국 가고 싶지 않은 곳으로 간다. - Yogi Berra

• 어디로 가기를 원하는지 커리어의 방향을 정하는 것이 중요하다.

어디로 가고 싶은지 커리어의 방향을 확신할 수 없다면 기회를 만들어 내기 위해 할 수 있는 모든 문들을 열어보길 시작하자.

• 익숙하고 편한 것에서 벗어나 새로운 것(새로운 프로그래밍 언어나 기술)을 공부하고 기술적 지식 확장하기.

• 지역 커뮤니티에 정기적으로 출석하거나 행사에 참여하기

• 다른 개발자, 비즈니스맨들과 교류하기

• 새롭게 배운 것, 지금 하고 있는 것들에 대해 블로깅하기

• 오픈 소스 프로젝트에 참여하기

• 프로젝트를 만들고 공개하기

• 콘퍼런스 참석하기

• 콘퍼런스 연사로 나가기

투자로서의 일터

거쳐가는 모든 직장, 프로젝트들 하나 하나를 투자로 인식하는 것이 가장 중요

• 우리가 기대하는 보상이 어떠한 것인지 명확히 하기

• 스스로를 낯선 환경에 노출시켜서 새로운 것을 배우고, 일을 수행하는 다른 방법들을 알아가기

• 지식은 일에서 얻을 수 있는 가장 흔한 투자 이익이다.

• 항상 배우고 더 나은 소프트웨어 장인이 되는 것에 집중한다면, 단순히 돈만 쫓을 때보다 좋은 직장을 얻기가 오히려 더 수월하다.

자율성, 통달, 목적의식

• 자율성 : 우리가 무엇을, 어떻게, 언제할지 통제할 수 있는 상태

  • 제대로 된 애자일 개발 환경이라면 이러한 것들이 보장되어야 함

• 통달 : 더 나은 프로페셔널, 더 나은 인간이 되기 위해 계속 배우고 진화하는 것

• 목적의식 : 지금 하고 있는 일이 중요하고, 무언가를 더 나아지게 하고 있다고 느끼는 것

  • 아무런 이해없이 시키는 대로 일하는 것의 반대 개념

회사 안에서의 커리어

• 어떤 계단을 밟느냐는 새로운 직장을 얻기 전에 숙제를 얼마나 잘 해놓았느냐에 달려 있다.

• 소프트웨어 장인은 그를의 커리어가 긴 여정이며, 어떤 종착지에 도달하는 것보다 그 여정 자체가 훨씬 더 중요함을 안다.

일을 할 때는 자율성, 통잘, 목적의식을 쫒자.

성공적인 커리어는 꽁짜로 오지 않는다. 스스로 만들어 나가야 한다.

일을 신중히 선택하고 고객들을 만족시켜 나가면, 소프트웨어 장인으로서 매우 성공적이고 즐거운 커리어를 만들 수 있다.

인재 채용

훌륭한 개발자를 유인하려면 먼저 채용 공고의 직무 요건을 바로잡아야 한다.

• 어떤 조직의 문화와 정체성은 회사의 구성원이 결정한다.

• 훌륭한 개발자들에게 일은 그냥 일이 아니다. 일은 취미이자 열정이다.

• 미래의 성공 가능성을 높이기 위해서는 열정적인 개발자를 찾아야 한다.

인터뷰 시간에 대한 변명

• 면접에 투자할 시간이 없다는 것은 훌륭한 팀을 구성하는 것을 소홀히 한다는 것과 같다.

틀에 박힌 직무 요건

• 채용 공고에 직무 요건 목록을 기술하는 방식은 피해야 할 관례다.

  • 절대적인 숫자: 몇 년간 ~ 경력

  • 키워드 매칭: 특정 기술이나 플랫폼

  • 기술 목록의 나열

  • 잘못된 기업 문화 설명

  • 잘못된 요구 항목: 기술, 경력 년수, 일한 산업군, 학벌

  • 잘못된 선별 조건

  • 승진 요건과 불일치

추천 채용

• 추천 채용 시스템에 금전 보상이 더해지면 채용 절차 전체를 무효화할만한 잘못된 동기가 생길 수 있다.

• 좋은 개발자들은 좋은 개발자들과 일하고 싶어하는 동기 하나만이 의미가 있다.

커뮤니티 활용

• 재능있는 개발자들을 채용하기 위한 최선의 방법은 여러 개발자 커뮤니티와 접촉하는 것이다.

• 사용자 그룹과 기술 커뮤니티들은 정기적으로 모임을 갖기 떄문에 개발자들과 회사들 모두 쉽게 함께할 기회를 찾을 수 있다.

소프트웨어 장인 면접하기

비즈니스 협상

• 면접을 볼 때, 일자리를 구걸하는 입장이 아니라는 것을 기억하자. 비즈니스 협상을 하는 것이다.

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

회사 입장에서의 관점

• 우리가 하는 일에 대해서 여러 관심의 질문들을 던지고, 일하는 방식을 개선하여 목표를 성공적으로 달성하는데 기여하기를 원함

• "어떤 식으로 일하는지, 무엇을 성취하길 원하는지, 당면한 문제가 무엇인지 등에 대해 면접 때조차 아무런 질문도 하지 않은 사람이, 실제 업무 현장에서 갑자기 적극적으로 질문을 하리라고 기대할 수 있을까?"

• 지원자가 일과 회사에 대해 아무런 질문도 하지 않는다면 단지 '아무 일자리'나 찾고 있을 뿐이라는 신호가 될 수 있음

• 그 반대라면, 최소한 지원자 스스로 즐겁게 일할 수 있는 곳을 찾고 있다는 증거가 될 수 있음

  • 과거 수행한 프로젝트나 업무, 기술 또는 스스로 성취한 사항들을 이야기할 때 열정적이고 애착이 보이는가

  • 실패 사례에 대해서 어떻게 표현하는가

  • 실패에 대해서 책임감을 느끼는가. 혹은 남탓을 하는가

  • 잘못된 상황을 정상으로 되돌리기 위해 무엇이든 노력을 해보았는가

  • 이전 업무에서 불평 불만 대신 그 상황을 개선하기 위해 스스로 노력했는가

  • 어떤 종류의 업무 환경을 찾고 있는가

  • 회사에서 그러한 환경을 제공해줄 수 있는가

  • ...

• 지원자에게 회사와 프로젝트에 관해 설명할 때는 좋은 점은 물론 나쁜 점, 껄끄러운 부분까지 가급적 모두 말해야 한다

• 지원자가 채용되고 일을 시작할 때 그가 사전에 기대한 것에서 크게 어긋나지 않도록 해야 한다

지원자 입장에서의 관점

• 그 회사와 같이 일하게 될 회사의 사람들에 대해 알 수 있는 대단히 중요한 기회

• 면접에서 관심을 두어야 할 사항들.

  • 면접관(프로젝트 관리자, 개발자, 림 리터, 아키텍트)은 누구인가

  • 얼마나 많은 지원자들을 면접보고 있는가

  • 원샷 면접인가 다단계 면접인가

  • 지원자에게 어떤 종류의 질문들이 주어지고 있는가

  • 특정된 질문인가 개방형 질문인가

  • 면접관이 기술적 질문에 대해 단답형을 좋아하는가 상세한 생각을 파보려 하는가

• 관리층이 개발자들을 신뢰하는지 확인해보자

• 면접관의 질문들을 분석하면 중요한 정보들을 얻을 수 있을 뿐만 아니라 지원자에게 교육적일 수 있다

• 현실 세계의 문제나 아주 구체적인 상황에 대해서 개방적인 대화를 해보자

바람직한 면접 방법

좋은 면접은 자유 토론과도 같아야 한다. 소프트웨어 개발과 관련하여 지식과 정보를 교환하고, 기술/도구/방법론들에 대해서도 의견을 나누어야 한다.

올바른 집중

• 무언가 개선하고 싶고, 도입하고 싶은 것들이 있다면 새로 채용될 개발자는 그런 것을 성취하기 위한 지원군이 되어야 한다.

마인드 맵핑 대화

• 면접이 끝나면 모든 대화가 마인드 맵으로 종이에 남아 각 지원자와 나누었던 대화들을 다시 기억해내는 데 효과적으로 이용된다.

페어 프로그래밍 면접

• 그 어떤 기술 면접도 지원자와의 페어 프로그래밍만큼 좋을 수 없다.

  • 어떤 테스트를 작성할지 얼마나 빨리 결정하는가 / 경험 수준

  • 개발 도구(IDE, 언어, 테스팅/목업 프레임워크, 단축키 등)에 얼마나 익숙한가

  • 클래스, 메서드, 변수 네이밍을 얼마나 적합하게 하는가

  • 코드르 ㄹ얼마나 깨끗하고 명료하게 작성하는가

  • 면접관이 제안이나 조언을 할 때 어떻게 반응하는가

  • 지원자가 어떤 방식으로 생각을 전개하는가

  • 문제 해결만이 아니라 문제 해결을 위한 방법과 과정에도 얼마나 주의를 기울이는가

• 카트는 지원자의 TDD 역량을 시험하거나 일반적인 클린 코드 원칙을 얼마나 지키는지 알아보는 데 좋다.

개인 컴퓨터를 지참한 면접

• 지원자가 좋아하는 도구는 무엇인지 알 수 있고, 소중한 면접 시간을 아낄 수 있다.

맞춤형 면접

• 스스로에게 다음과 같은 질문을 던져보어야 한다.

  • 우리가 소중히 하는 가치는 무엇인가

  • 동료들로부터 어떤 종류의 태도를 기대하는가

  • 채용하려는 직무의 핵심 스킬은 무엇인가

번트 홈런

• 면접을 할 때 특정 기술에 대한 지식이 아니라 지원자의 재능, 태도, 열정 그리고 잠재성을 보아야만 한다.

기존 팀을 위한 채용, 새로운 팀을 위한 채용

기존 팀을 위한 채용

• 우리가 일하는 방식과 핵심 가치에 대한 열정과 긍정적인 태도, TDD, 클린 코드, 설계 등에 대한 탄탄한 소프트웨어 개발 기초 역량이 중요

새로운 프로젝트 초기 개발자 채용

• 열정과 소프트웨어 개발 기초 역량 외에도 프로젝트를 제 궤도로 유지하고 성공적으로 이끌어낸 과거 경험, 많은 프로젝트들을 최종 인수 서명 단계까지 고통 속에서 이끌어 본 노련함이 필요

사전 면접용 코딩 시험

• 지원자에게 면접 전에 코드를 제출하게 하는 것도 사전 선별을 위한 좋은 방법

지원자와 회사 모두 면접을 어떻게 하는지 알아야 한다

• 강한 팀은 각 개발자들 모두 면접을 진행할 수 있어야 한다.

• 모든 개발자들이 팀이 기대하는 인재를 발굴해 낼 수 있어야 한다.

개발자 채용 면접은 개발자가 보아야 한다

• 회사는 개발자 채용 면접을 할 때 반드시 개발자로 하여금 면접관 역할을 하도록 해야 한다.

면접 과정을 지켜보기만 해도 그 회사와 그 안의 개발팀, 개발자들에 대해 많은 것을 알 수 있다.

소프트웨어 장인은 상산적인 파트너십과 아침에 일어날 때마다 일하러 가는 것이 행복한 그러한 직장을 찾는다.

잘못된 면접 방식

회사의 채용 절차를 하나하나 상세하게 뜯어보면 그 회사가 추구하는 가치와 문화를 엿볼 수 있다.

잘못된 방식

• 똑똑한 척하는 면접관을 세운다

• 수수께끼식 질문을 던진다

• 답을 모르는 질문을 한다

• 지원자를 바보로 만든다

• 인터넷 접속을 막는다

• 종이에 코드를 작성하게 한다

• 알고리즘 문제를 낸다 : 실제 문제에 가까운 과제를 제시해야 한다.

• 전화 면접을 한다

개발자들은 회사를 면접하여 평가하고 나쁜 회사들을 걸러낸다.

낮은 사기의 대가

개발자들의 낮은 사기는 소프트웨어 프로젝트 실패의 주된 이유 중 하나다.

• 애자일 행오버

• 그저 출퇴근만 하는 개발자들

• 낮은 수준의 동기가 만드는 제약

개발자들에게 열정 불어넣기

• 외부로부터 소프트웨어 장인을 수혈받자

  • 장인은 자신을 둘러싼 사람들에게 영감을 불어 넣기 위해 모든 노력을 아끼지 않는다

  • 항상 다른 여러 개발자들의 멘토로서 행동하는 데 주의를 기울인다

  • 자신의 자기계발 활동을 다른 사람들과 공유하려 한다

직원들의 사기가 낮으면 회사가 파괴되기 쉽다.

개발자에게 동기를 부여할 수 있는 최선의 사람은 바로 동료 (실력있는, 본받고 싶고 영갑을 일으키는)개발자이다.

배움의 문화

구성원들이 동기가 부여되어 있지 않거나 자신의 일 자체에 별 관심이 없으면 그 어떤 변화도 효과적으로 일으킬 수 없다

배움 문화 만들기

배움의 문화를 만들면 회사에 효율적으로 열정을 주입할 수 있다.

• 북 클럽에 가입하기: 책을 하나 선택해서 동료들에게 그 책을 읽기 시작할 거라고 공표하자.

• 테크 런치 진행하기: 팀원들에게 주 1회 정도 점심 시간에 기술 관련 난상 토론회를 갖는 것을 제안해보자.

• 그룹 토론회 참여하기: 약 5분 동안 주제를 발표하고, 2분의 질답으로 이루어진다. 이후 그룹 토론 주제로 넘어간다.

• 업무 교환하기: 프로젝트의 한 업무 주기 동안 팀끼리 개발자를 서로 바꾸면 새로운 것을 볼 기회가 생긴다.

  • 기존 결정들에 대한 재검증

  • 지식의 공유

  • 개선

  • 공동 학습

• 얼마 동안만 업무 교환하기: 몇 시간 내지는 며칠만 팀 간 개발자 교환을 할 수도 있다.

• 그룹 코드 리뷰하기: 특정 코드 부분이 개선의 여지가 많은지, 모범사례로 공표할 만큼 훌륭한지 동료들간 논쟁하기

  • 주석은 주관적, 개인적으로 표현되어서는 안 된다. 객관적이고 생산적이어야 한다.

  • 누가 코드를 작성하느냐는 중요치 않다.

  • 큰 진전을 이룰 것이라 기대하지 않는다.

• 코딩 실습하기: 최선의 코드를 작성하는 법 훈련

• 내부 학습 모임 만들기: 두 사람만 있으면 내부든 외부든 커뮤니티를 시작할 수 있다.

• 회사에서의 펫 프로젝트 시간 허용하기

• 외부 기술 커뮤니티와 교류하기: 외부 커뮤니티를 통해 열정적이고 재능있는 수많은 개발자들과 함께 하면 나 자신에게 커다란 도전이 된다.

배움의 문화를 조성하도록 복돋우기 위한 조언

• 스스로 모범을 보여라

• 관심을 보이는 사람들에게 집중하라

• 강제하지 마라: 애초의 동기를 꾸준히 유지해야 한다.

• 모두를 변화시키려 들지 말라

• 모임에 대한 약속을 제때하라

• 상사의 허락을 구하지 마라

• 환경과 상황을 투덜대지 마라

• 리듬을 만들라

기술적 변화의 실행

당신을 둘러싼 것들을 바꾸고 싶다면, 가장 중요한 것은 용기다.

• 동료 개발자, 관리자, 기술 리더와 언성이 높아지는 논쟁을 두려워해서는 안 된다.

  • 단순함을 구추하자.

  • 상대방의 언어로 말하자.

  • 말할 내용에 대해 스스로 제대로 이해하자.

  • 상대방을 존중하자.

  • 경청하는 법을 배우자.

• 주변을 바꾸고 싶다면 두려움을 버리고, 인격적으로 못되먹은 사람이 되지 말자.

• 상사를 설득하고 싶다면, 상세사항을 많이 노출하지 말자. 노출할 수록 더 세세한 업무 지시가 돌아올 것이다.

• 지식을 공유하며 신뢰를 쌓고, 롤모델이 되어 누군가가 따르고 싶어하고, 조언을 듣고 싶어하는 사람이 되자.

• 권한을 갖고 싶다면, 책임질 수 있는 준비를 해야 한다.

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

• 지속적으로 품질 좋은 소프트웨어를 딜리버리하며 신뢰 쌓기

• 새로운 기술을 제안하기 전에 본인 스스로 충분히 이해하고 전문성 확보하기

• 나 스스로 그것을 할 수 있는지 확인해보고 모범을 보여 사람들 이끌기

• 의미 있는 곳에 노력을 집중하고, 더 빨리 가치를 얻을 수 있도록 신중하게 싸울 곳 정하기

• 큰 충돌을 피하기 위해 점진적으로 반복, 관찰 수용하기

실용주의 장인정신

품질은 선택사항이 아니다

좋은 품질은 비싸고 시간이 오래 걸린다는말은 잘못된 사실이다

리펙토링

• 레거시 코드를 대상으로 작업할 때는 최소한 수정한 부분만큼은 원래 보다 꺠끗하게 만들어 놓아야 한다.

• 확장에는 열려있고 변경에는 닫힌 OCP 원칙을 준수할 수 있도록 코드를 리펙토링한 후 신규 기능을 추가해보자.

소프트웨어 개발 방법의 한 가지 예

• 많이 사용되는 실행 관례들이 절대 불변의 진라라고 믿어서는 안 된다.

• 실행 관례와 절차들은 그보다 더 나은 실행 관례와 절차가 나타나기 전까지만 가치가 있다.

• 여러가지 훌륭한 도구들을 포용하면서 맡은 일의 맥락에 가장 적합한 것을 꺼내어 적용할 수 있어야 한다.

비즈니스 돕기

• 개발자들이 비즈니스 담당들과 직접 대화하면서 질문하고 솔루션을 제안할 것을 권장한다.

소프트웨어 프로젝트는 우리를 위한 것이 아니다

• 프로젝트를 수행한 사람들이 떠나간 후 그것을 유지보수할 사람들을 고려해야 한다.

비범함과 평범함

• 비범한 개발자는 요구사항을 충족하는 가장 단순한 코드를 만들어, 경험이 적은 개발자가 이해하는 데 아무런 문제가 없도록 한다.

  • 단순하고 짧은 솔루션 이상의 것을 추구

  • 가장 훌륭한 코드는 작성할 필요가 없는 코드

  • 잘 작성된 코드는 단순하고, 작고, 테스트 가능하며 이해하기 쉽다.

단순한 설계를 위한 네 가지 원칙

Kent Back / J.B Rainsberger

• 모든 테스트를 통과해야 한다. -> 모든 테스트의 통과

• 명료하고, 충분히 표현되고, 일관되어야 한다. -> 중복의 최소화

• 동작이나 설정에 중복이 있어서는 안 된다. -> 명료성의 최대화

• 메서드, 클래스, 모듈의 수는 가능한 적어야 한다. -> 구성요소의 최소화

.

단순한 설계를 위한 가이드 라인

1. (좋은 네이밍, 비즈니스 컨셉을 잘 투영한)추상화에 집중하기

2. 중복을 제거하며 코드의 응집성과 독립성 높이기

3. 새로운 구조가 떠오르면 다시 명료성 높이기

4. 다시 중복 없애기

5. ... (짧은 반복 주기로 작업 완료까지 계속)

패턴을 위한 리펙토링

• 새로운 기능을 추가하기 전에 기존 코드를 수정해서 추상화하기

• 당장의 합당한 이유 없이 단지 '미래를 대비해야 한다'는 모호한 전제로 초기부터 추상화를 하면 애플리케이션이 엉망이 된다.

• 실용적인 접근 방법은 실제 필요한 상황이 생겼을 때만 추상화를 도입하는 것.

• 좋아하는 패턴에 문제를 끼워 맞추기 전에, 문제에 적합한 리펙토링을 단순한 설계와 SOLID 원칙을 따라 먼저 시도해보자. 이후 나중에 필요한 상황이 생겼을 때 범용화해보자.

장인정신과 실용주의

• 깨끗하고 잘 작성된 코드는 비즈니스의 요구에 맞추어 빠르고 안전하게 변경할 수 있는 기반이 된다.

• 요구사항의 변화에 맞추어 코드를 빠르게 바꿀 수 있는 것이 비즈니스를 돕는 최선의 방법이다.

이슈가 되지 않을 정도까지 품질 비용을 낮추기 위해 좋은 실행 관례뜰을 마스터하고 실용주의적인 입장을 취하자.

소프트웨어 장인으로서의 커리어

소프트웨어 개발자들은 우리가 살고 있는 세상이 진화해 나가는 데 꼭 필요한 존재다.

장인의 길

• 소프트웨어 장인은 소프트웨어 개발과 자신의 직무에 열정적이다.

• 다음 세대의 장인을 키우는 데 사회적 윤리적 의무감을 느껴야 한다.

• 항상 최고의 코드를 만들도록 다른 것들을 희생해서라도 계속해서 배우고 남을 도우리라는 각오를 한다.

• 아름다운 코드를 작성하기 위한 일생에 걸친 헌신과 같다.

• 소프트웨어를 통해 가치를 창출할 수 있는 더 나은, 더 효과적인 방법을 찾는 끊임없는 노력의 길이다.

• 새로운 것에 대한 호기심을 가지고 실험한다는 것곽 같다.

• 코드 작성이 아니라 문제 해결에 집중한다.

• 긍정적인 일들로 연상되는 존재여야 한다.

정직과 용기

• 고객이 나쁜 의사결정을 할 때 그것이 적절치 못하다고 지적하는 정직함과 용기가 필요하다.

• 모든 '아니오'에는 항상 대안을 제시해야 한다.

여정과 이정표

소프트웨어 장인은 스스로의 커리어를 매우 신중하게 계획한다.

• 다음 단계를 위해 앞서 보고, 계획하는 것은 성공적인 커리어를 위해 핵심적이다.

• 일터를 더 나은 곳으로 만드는 데 투자한다는 의미는 우리의 커리어를 더욱 풍요롭게 할 수 있는 기회를 늘린다.

커리어 만들어 나가기

일을 선택하기 전에 질문을 스스로에게 던져보자.

면접 과정은 지원자 입장에서도 회사를 평가할 수 있는 기회다. 고용 관계를 맺기 전에 그 기회를 최대한 이용하여 정보를 얻어내자.

• 나의 커리어로부터 나는 무엇을 원하는가?

• 그것을 성취하기 위한 다음 단계는 무엇인가?

• 이 일은 나의 커리어 방향과 합치하는가?

• 내가 이 회사에 줄 수 있는 가치의 양은 얼마나 되는가?

• 그러한 투자에 대한 이익은 무엇인가?

• 그러한 투자는 대략적으로 얼마 동안 지속되어야 하는가?

• 내가 되고자 하는 프로페셔널에 이르는 데 이 일은 어떻게 도움이 되는가?

• 이 일에서 나는 자율성, 통달, 목적의식을 가질 수 있나?

• 나의 고용주와 생산적인 동반자 관계를 맺을 수 있나? 양측 모두 가치를 얻고 행복할 수 있나?

.

• 개인이 커리어 열망과 방향이 합치하는 한 그 회사에 가능한 오랫동안 머무르길 권한다.

• 앞으로 나아가지 못하고 정체되어 있다고 느낀다면, 무언가를 배우거나 스스로 일을 즐기지 못한다면, 그때는 움직여야만 한다.

원하는 바를 모른다면 어떻게 해야 할까?

• 내가 원하는 것을 나도 모른다는 것을 인정하자.

• 마음을 열고 사람들을 만나보자.

• 내가 모르던 큰 세상이 있음을 알게 될 것이다.

다양성

• 인적 네트워크는 소프트웨어 장인으로서 커리어를 개발해 나가는 데 큰 도움이 된다.

• 다양한 환경을 경험하는 것은 전문화된 장인에 이르는 길에도 도움이 된다.

• 여러 프로젝트, 환경, 회사, 산업, 기술, 소프트웨어적인 문제 접근 방법론을 경험해 나가면서 어떤 분야에 집중할지 방향을 잡아보자.

소프트웨어 장인의 사명

• 더 나아지는 데 집중하고, 계속해서 자신의 커리어에 투자하며, 배우고, 가르치고, 공유하기

• 고객에게 항상 가치를 전달할 수 있도록 해야 하고, 프로페셔널리즘, 열정, 관심으로 소프트웨어 산업의 수준을 높이는 것

• 다른 개발자들이 더 나은 코드를 만들고 스스로가 하는 일에 자부심을 갖도록 돕는 데 관심 두기

• 전 세계적으로 소프트웨어 프로젝트들의 품질과 성공 비율을 오늘날보다 높아지도록 하는 것

• 주변의 것들을 더 나아지게 하고 우리가 사는 세상을 변화시킬 것