[클린 코더] The Clean Coder -1

• 프로의 마음가짐
• 아니라고말하기
• 예라고 말하기
• 코딩
• 테스트 주도 개발
• 연습
• 인수 테스트
• 테스트 전략
• 시간 관리
• 추정
• 압박
• 함께 일하기
• 팀과 프로젝트
• 도구 활용

1. 프로의 마음가짐

"그냥 웃어, 이 친구야."

• 프로페셔널리즘 Professionalism
  : 명예와 긍지의 상징이자 동시에 책임과 의무를 나타낸다.
• 책임감을 가져라
• 무엇보다도 해를 끼치지 마라
  : 기능에 해를 끼치지 마라 (QA는 아무것도 찾지 못해야한다.)
  [QA : 소프트웨어 기획의도나 목적에따라 올바르게 구동하는지 테스팅]
  제대로 작동하는지 아닌지 알아야 한다.
  자동화된 QA
  구조에 해를 끼치지 마라 (구조가 좋아야 코드가 유연해진다.)
  : 변경을 할 때 터무니없는 비용을 치르지 않고 변경할 수 있어야 한다.
  자신의 경력은 자신이 책임져야 한다.
  : 한 주에 60시간 일할 계획을 짜야한다.
  40시간은 회사를 위해쓰고, 20시간은 자신을 위해 써야한다.
• 전산분야 지식을 익혀라

  나씨 슈나이더만 도표
  : 구조적 프로그램의 순차, 선택, 반복의 구조를 사각형으로 도식화하여 논리적으로 표현한 기법
  무어머신
  : 출력이 현재의 상태에서만 의존하는 것
  밀리머신
  : 출력이 현재의 상태와 입력에 의존하는 것
  변환분석
  : 자료의 흐름도(입력)를 구조도(출력)으로 변환하는 방법 중 하나

• 끊임없이 배우기
• 연습
• 함께 일하기
• 멘토링
• 업무지식을 익혀라
• 회사와 고객에 동질감을 가져라
• 겸손

2. 아니라고 말하기

" 한다. 하지 않는다 둘 뿐이야. 해본다는 말은 없어"

• 일을 제대로 처리하기 위해 불가능한 업무는 "아니요, 불가능합니다." 라고 말할 수 있어야한다.

3. 예라고 말하기

• 약속의 세부분

1. 하겠다고 말한다.
2. 진심을 담는다.
3. 실제로 실행한다.

• 나는 언제까지 할 것이다.
• 아니라고 말하는 법도 중요하지만, 제대로 '예'라고 말하는 법도 중요하다.
• 확실한 대답
• 원칙을 가지고 의사소통하기

  모든 업무요청에 예라고 대답할 필요가 없다.
  단, 내뱉은 말에 모호한 부분이 없도록 해야한다.

4. 코딩

• 준비된 자세

1. 코드는 반드시 동작해야한다.
2. 코드는 고객이 제시한 문제를 반드시 풀어야 한다.
3. 기존 시스템에 잘 녹아들어야 한다.
4. 다른 프로그래머가 읽기 쉬워야 한다.

• 충분히 강하게 집중하지 못하면 잘못된 코드를 만들게 된다.
• 코딩시간과 디버깅 시간은 전혀 다를 것이 없다.
  디버깅 시간을 피하거나 줄이는 일은 좋은 일이다.
• 가능한 0에 가깝게 디버깅 시간을 줄일 수 있도록 한다.
• 속도조절 : 소프트웨어 개발은 마라톤이지 단거리 질주가 아니다. 시작부터 있는 힘껏 빨리달리지는 말자.
• 가짜출시를 하지말자
  끝내지도 않았는데 끝냈다고 말하는 것은 명백한 거짓말이고 아주 나쁜 짓이다.
• 완료
  : 업무 분석가와 테스터가 자동화된 인수 테스트를 만들어 완료했다고 말하기 전에 반드시 테스트를 통과해야한다.
• 프로그램은 작고 알기 쉬운 단위로 주의깊게 쪼개고 그 단위는 가능한 서로 간섭이 적도록 만들어야 한다.

5. 테스트 주도 개발

TDD
: 익스트림 프로그래밍 움직임의 일부로 시작했으나 스크럼을 포함한 모든 애자일 방법론에서 TDD를 받아들였다.

• 반복 시간을 줄이는 이상의 의미
• 외과 의사가 꼭 손을 씻어야 하듯 프로그래머도 TDD를 꼭 적용해야한다.
• 작성한 코드가 전부 잘 돌아가는지 알아야한다.

TDD의 세가지 법칙
1. 실패한 단위 테스트를 만들기 전에는 제품 코드를 만들지 않는다.
2. 컴파일이 안 되거나 실패한 단위 테스트가 있으면 더 이상의 단위 테스트를 만들지 않는다.
3. 실패한 단위 테스트를 통과하는 이상의 제품 코드는 만들지 않는다.

• 위의 세가지 법칙을 지키면 반복 주기는 대략 30초 길이를 유지한다.
• 처음에는 아직 만들지도 않은 클래스나 함수의 이름을 써야하고, 컴파일이 어렵다.
  컴파일이 가능하도록 코드를 만들고 단위테스트도 더 만들기 시작한다.
  두 가지 코드 흐름이 동시에 자라나 상호 보완하는 컴포넌트가 된다.
  *컴포넌트는 독립적인 소프트웨어 모듈
• 용기는 TDD의 가장 강력한 이점이다.
  믿음직한 테스트 묶음이 있으면 변경에 대한 두려움이 모두 사라진다.
• 깔끔한 코드는 바꾸기도 쉬우며 확장하기도 쉽다.
• 단위 테스트는 문서다.
  시스템의 가장 낮은 단계의 설계를 알려준다. 명확하고 정확하며 독자가 이해하는 언어로 만들어져 실행 가능한 형식을 갖춘다.
• 테스트를 먼저 만들기 위해서는 좋은 설계를 고민해야 한다.
• "테스트를 나중에 만들 수 있어요" 라는 말은 틀렸다.

6. 연습

• 모든 프로는 기술 연마 훈련을 통해 그들의 기예를 갈고 닦는다.
• 뭔가를 빠르게 처리하려면 연습이 필요하다.
• 재빨리 결정을 내린다는 뜻은 수많은 상황과 문제를 인식하고 이를 어떻게 처리해야 할지 이미 안다는 뜻이다.
• 프로그래밍에서 품새란 어떤 문제 풀이를 가상해 만든 키 누름과 마우스 조작을 정교하게 짜 모은 것
• 연습은 회사의 의무가 아니라 자신의 의무

7. 인수테스트

• 개발은 물론 의사소통 또한 프로 개발자의 임무
  입력이 형편없으면 출력도 형편없다.
• 사업부에서 전달한 요구사항을 프로그래머는 나름대로 구현한다.
  현실에서 요구사항 관련 의사소통은 엄창나게 어렵고, 그 과정에 오류는 가득하다.
• 어떤 기능에 대한 고객들의 예상은 컴퓨터로 구현하고 나서 보면 그 예상이 틀린경우가 잦다.
• 사업부와 프로그래머는 모두 시기상조의 정밀도라는 함정에 빠지기 쉽니다.
  사업부는 프로젝트를 승인하기 전에 일이 어떻게 진행될지 정확히 알고싶어한다.
  개발자들은 프로젝트를 추정하기 전에 어떤 제품을 만들어야 할지 정확히 알고 싶어한다.
• 불확실성의 원칙
  : 서류와 실제 시스템 동작이 다르다.
• 관찰자 효과
  : 불확실성의 원칙
• 요구사항이 정밀해질수록 최종 구현된 시스템과 초기 요구사항의 차이는 더 벌어진다.
• 불안한 추정

1. 완벽한 정보로 추정을 한다 해도 추정에는 큰 편차가 생기고야 만다.
2. 불확실성의 원칙이 초기 정밀도를 엉망으로 만든다.

• 요구사항은 반드시 바뀌기 때문에 초기 정밀도는 고려할 가치가 없다.
• 시기상조의 정밀도를 해결하려면 가능한 정밀도를 늦추면 된다.

  인수테스트
  : 요구사항이 언제 완료되는지를 정의하기 위해 이해 당사자들과 프로그래머들이 힘을 모아 작성하는 테스트

  • 목적 : 소통, 명확성 및 정밀성

• 완료란 ?
  모든 코드를 작성했고, 모든 테스트를 통과했음을 말하는것.
  QA전문가와 이해당사자들이 이를 인수했다는 것
• 인수 테스트는 언제나 자동화 해야한다.
  *예를 들어 FitNesse, Cucumber, cuke4duke 등이 있다.
• 테스트 협상과 수동적 공격성
• 인수 테스트는 단위 테스트가 아니다.
  단위 테스트는 프로그래머가 프로그래머들을 위해 만든다.
  단위테스트는 코드의 최하위 구조와 행동을 설명하는 공식 디자인 문서다.
  인수테스트는 사업부를 위해 사업부가 작성한다. 시스템이 어떻게 운영되어야 하는지를 구체적으로 표시한 공식 요구사항 문서다.
• GUI
  : 그래픽 사용자 인터페이스
• GUI는 변화가능성이 커서 테스트를 매우 취약하게 만든다.
• GUI 바로 아래에 위치한 API를 통과하기 위한 업무 규칙 테스트를 만들어라
• GUI와 업무규칙을 분리해서 GUI를 테스트하는 동안, 업무 규칙을 스텁으로 교체하는 것이 좋다.