프로의 마음가짐

결함이 있는 코드란 어떤 코드일까? 확실을 갖지 못하는 코드는 모두 결함이 있는 코드다.

테스트를 자동화해야한다. 순식간에 실행할 수 있는 테스트를 만들고 가능한 자주 돌려라.

얼마만큼의 코드를 자동화한 단위 테스트로 테스트해야 할까? 대답할 필요조차 없다. 모조리 다 해야 한다. 모조리.

비현실적이라고? 전혀 그렇지 않다. 작성한 코드는 당연히 실행된다. 실행된다면 제대로 돌아가는지 알아야한다. 알 수 있는 방법은 테스트뿐이다.

어떤 코드는 테스트하기 어렵지 않나? 그렇다 하지만 그 이유는 코드를 테스트하기 어렵기 설계했기 때문이다. 해결책은 테스트하기 쉽게 코드를 설계하는 것이다. 가장 좋은 방법은 테스트 코드를 먼저 작성한 다음, 그 테스트를 통과하도록 코드를 작성하는 것이다.

자동화된 QA

QA 절차가 3분 정도밖에 안걸려서 끝나면 바로 선적한다.

테스트를 자동화하면 최소한 시스템이 QA를 통과할 정도는 된다고 말할 수 있다.

구조에 해를 끼치지 마라

전체 구조를 희생하면서까지 기능을 추가하는 일이 헛수고라는 사실은 프로라면 당연히 알고 있어야 한다. 구조가 좋아야 코드가 유연해진다.

소프트웨어는 계속 변한다. 변경을 할 대 터무니 없는 비용을 치르지 않고 변경할 수 있어야한다.

소프트웨어가 바꾸기 쉬운지 아닌지 증명하는 유일한 길은 실제로 조금씩 바꿔보는 것이다. 바꾸기 쉽지 않다면 설계를 갈고 닦아서 다음 번에는 더 쉽게 바꿀 수 있도록 해야한다.

코드를 조금 바꾸는 일은 언제해야할까? 항상 해야한다. 모듈을 살펴볼 때마다 작고 가벼운 변화를 더해 구조를 개선해야 한다. 코드를 읽을 때마다 변화를 더해 구조를 개선해야 한다. 코드를 읽을 때마다 구조를 바꿔야 한다.

보이스카웃 규칙. 체크인할 때는 항상 체크아웃했을 때보다 깨끗해야 한다는 규칙이다. 코드를 볼 때마다 착한 일을 하라.

코드를 바꾸는게 위험한게 아니라 코드를 그대로 두는 것이 위험한것이다. 왜 코드를 바꾸기를 두려워 하는가 테스트가 없어서이다. 자동화된 테스트 묶음(suite)의 커버리지가 거의 100%이고 내킬때마다 테스트할 수 있으면 코드를 바꾸는 일은 전혀 무섭지 않다. 코드 바꾸기가 무섭지 않다는 사실을 어떻게 증명할 수 있을까? 항상 코드를 바꾸면 된다.

프로 개발자는 코드와 테스트에 대한 확신이 넘치기 때문에, 시도 때도 없이 이리저리 코드를 바꿔도 마음이 평안하다. 마음이 내키면 클래스 이름을 바꾼다. 코드를 읽다가 메소드가 좀 길다 싶으면 아무렇지 않게 메소드를 나눈다. switch 문장을 다형성을 활용한 구조로 바꾸기도 하고, 상속 계층을 무너트려 연속된 명령어로 바꾸기도 한다. 한 마디로 조각가가 진흙을 다루는 것처럼 코드도 끊임없이 모양을 바꾼다.

직업윤리

자신의 경력은 자신이 책임져야 한다. 실무에서 통할만한 능력을 갖추는 일은 회사 책임이 아니다. 훈련시키고, 컨퍼런스에 보내고, 책을 사주는 일도 회사 책임이 아니다. 이런 일은 스스로 책임져야한다.(회사가 호의를 베풀지 않으면 스스로 찾아야 한다.)

한 주에 60시간 일할 계획을 짜야한다. 40시간은 회사를 위해쓰고 나머지 20시간은 자신을 위해 쓴다. 20시간은 읽고 연습하고 공부하고 경력에 도움이 되는 여러가지를 하며 보내야 한다.

점심시간에 책을 읽고, 출퇴근할때 팟캐스트를 듣고, 새언어를 배우는데 90분을 쓰면 3시간이다. 프로는 자신의 직업을 돌보는데 시간을 투자한다. 어떤때는 회사를 위해 하는 일이 경력에 큰 도움이 되기도 한다. 하지만 20시간은 자신을 위한 시간임을 명심해야 한다. 그 시간은 프로로서 자신의 가치를 높이기 위해 써야 한다.

전산 분야 지식을 익혀라

밀리상태기계와 무어상태 기계가 어떻게 다른지 알아야한다. 검색하지 않고 퀵소트를 작성할 수 있는가? 변환 분석이란 용어를 아는가? 데이터 흐름도를 기능분해 할 수 있나? Tramp Data가 무슨 뜻인지 아는가?

확실히 몇몇 아이디어는 비주류로 물러나긴 했다. 예를 들어 폭포수 개념은 확시히 사람들의 관심이 줄어들었다. 그렇긴 하지만 폭포수 개발의 의미와 장단점을 몰라도 된다는 말은 아니다.

다음은 프로 소프트웨어 개발자라면 알아야 하는 최소한의 기술 목록이다.

• 디자인패턴 : 24가지 GOF 패턴을 설명할 수 있고, POSA 패턴을 실무에 적용할 수준으로 알아야한다.
• 설계원칙: SOLID 객체지향 원칙을 알아야 하고 컴포넌트 개념을 충분히 이해해야 한다.
• 방법론 : XP, 스크럼, 린, 칸반, 폭포수, 구조적 분석, 구조적 설계개념을 충분히 이해해야한다.
• 원칙: TDD, 객체지향 설계, 구조적 프로그래밍, 지속적 통합, 짝 프로그래밍을 실천해야 한다
• 도구 : UML, 데이터 흐름도, 구조차트, 페트리넷(Petri Net), 상태전이 다이어그램과 테이블, 흐름도, 결정테이블을 어떻게 쓰는지 알아야 한다.

끊임없이 배우기

책, 기사, 블로그, 트윗을 읽어라. 컨퍼런스에 가라. 여러 무임에 참가하라. 스터디 그룹에 들어가라. 익숙한 영역을 벗어나 낯선 것을 익혀라. .NET 프로그래머라면 자바를 배워라. 자바 프로그래머라면 루비를 배워라.

연습

프로는 연습한다. 진정한 프로는 기술을 날카롭게 갈고 닦아 항상 준비된 상태로 만들려고 애쓴다. 일상적인 업무를 연습이라 부르면 안 된다. 일상 업무는 연습이라기보다 공연이다. 업무라는 공연을 떠나 기술을 개선하고 향상시키고자 하는 목적만으로 하는 훈련이 바로 연습이다.

6장에서 다시 설명하지만, 볼링 점수 계산이나 인수분해 프로그래밍 같은 간단한 훈련을 계속해서 반복한다. 이런 훈련을 품새라 한다. 품새는 종류가 다양헤서 선택의 여지가 넓다. 품새는 대개 프로그래밍으로 간단한 문제를 푸는 형식이다. 문제를 어떻게 푸는지는 이미 알고 있다. 품새의 핵심은 손가락과 두뇌를 단련시키는 일이다.

보통 업무를 시작하기 전에 푸는 일이 많다. 자바나 루비 혹은 클로저로 풀기도하고, 잊고 싶지 않은 언어로 풀기도 한다. 품새를 통해 특정 리팩토링을 활용하거나 단축키를 익숙하게 누르는 것 같은 세부 기술을 날카롭게 다듬는다. 아침에 10분, 저녁에 10분

함께 일하기.

멘토링

배우기에 가장 좋은 방법은 가르치는 것이다. 가르치고 배울 때 더 큰 이득을 보는 쪽은 선생님이다.

업무 지식을 익혀라

자신이 프로그래밍하는 제품의 업무 분야 지식을 알아야한다. 새로운 분야 프로젝트를 시작하게 되면, 관련 분야의 책을 한두 권 읽어보자. 프로답지 못한 행동 중에서 최악은 제품 사양이 사업 진행에 이치에 맞는지 따져보지도 않고 그저 사양에 따라 코딩하는 일이다.

겸손

2장 아니라고 말하기

반대하는 역할

경험상 어려운 결정을 내리는 최고의 방법은 대립하는 사람들 사이의 충돌이다.

// wrong
마이크 : 폴라 로그인 페이지를 내일까지 끝내야 돼요
폴라 : 미안한데 마이크 그보단 시간이 더 걸릴 거에요
마이크 : 언제쯤 끝낼수 있쬬?

// right
마이크 : 폴라 로그인 페이지를 내일까지 끝내야 돼요
폴라 : 안돼요. 2주나 걸리는 작업이라고요
마이크 : 2주나요? 설계팀은 3일이 걸린다고 추정했고 벌써 5일이나 지났어요
폴라 : 설계팀이 틀렸어요. 요구사항을 추가하기 전에 추정한거잖아요.
마이크 : 로그인에 필요한 최소기능만 구현하죠 내일 시연에 쓰도록

이해관계가 높을때

이해 관계가 높을 때야 말로 아니라고 말할 가장 중요한 순간이다. 이익과 손해가 클수록, 아니라는 말의 가치도 높아진다. 손해가 너무 커서 회사의 생존 여부가 달린 일이라면, 마음을 굳게 먹고 최고의 정보를 관리자에게 알려야 한다.

절 해고해도 예정일은 변하지 않습니다.

팀플레이어

팀 플레이어는 항상 네라고 하지 않는다.

노력해보기

마이크가 회유와 조종을 할 때, 최악의 선택은 “알았어요, 노력해볼게요”라고 대답하는 것이다. 해본다 라는 표현없다. 노력은 긍정의 행동이라 생각할 것이다.

노력하겠다는 약속은 근본적으로 정직하지 못한 행동이며 거짓말이다. 아마 체면을 차리고 대립을 피하려 했음이 틀림없다.

기한의 불확실함을 강조했고 절대 물러서지 않았다.

프로답게 행동하라. 안되는 것을 말하는 용기. 상대방은 되는 줄 알고 있을 수도 있다.

예라고 말하는 비용

우리는 언제나 예라고 말하고 싶다. 사실, 건강한 팀은 예라고 할 수 있는 방법을 찾으려 애쓴다. 잘 돌아가는 팀의 관리자와 개발자들은 서로 만족할 수 있는 계획이 나올 때까지 협상한다.

여담 : 훌륭한 코드는 불가능한가?

클린 코드란 개념을 아주 좋아한다. 클린 코드를 만든다는 것은 좀처럼 손에 잡히지 않는 어려운 일인데.

고객들이 요구하는 기능은 항상 말로 들을 때보다 더 복잡해진다는 불변의 진리를 몇 년이나 겪었으면서도, 이 일을 맡게 된다.

이 이야기의 교훈은 외부 고객이건 내부 관리자건 이해관계자는 개발자들이 빨리 코딩하도록 만들고 만다는 점이다. 효율적일까? 아니다. 빠를까?

• 개발자들에게 간단한 앱이라고 한다. 이말은 개발자들이 일찍 잡업을 시작하게 만들고, 그로 인해 개발자들은 내용파악을 하지 못한다.

코드 임파서블

프로는 종종 영웅이 되기도 하지만 영웅이 되려 애썼기 때문이 아니다. 프로가 영웅이 될 때는 업무를 충실히, 제 시간에, 예산안에서 완수했을 때다.