[실용적인 프로그래머] 내용 정리

실용적인 프로그래머 도서를 요약한 내용입니다.

서문

도구 벤더 - 자신의 제품이 수행할 수 있는 기적같은 일들을 자랑.
방법론 도사 - 자신의 기법이 좋은 결과를 보장한다고 약속
도구든, 언어든, 운영체제든 상관없이 최고의 해결방안 같은 것도 없다. 특정한 환경 조건의 집합마다 각 집합에 가장 적절한 시스템들이 있을 뿐이다.

==> 이것이 실용주의가 뜻하는 바다.

어떤 특정 기술에 매이면 안 되며, 개별 상황마다 그 상황에서 좋은 해결방안을 고를 수 있도록 충분한 배경지식과 경험을 가져야 한다.
배경지식은 컴퓨터 과학의 기본 원리들을 이해하는 것에서 나오고, 경험은 다양한 범위의 실제 프롲게트들을 수행해보는 것에서 나온다. 이론과 실천의 결합이 여러분을 강하게 만든다.

이 책은 누가 읽어야 할까?

이 책은 더 효율적이고 생산성 높은 프로그래머가 되고 싶어 하는 사람들을 대상으로 쓰였다.

무엇이 실용주의 프로그래머를 만드는가?

• 얼리어덥터 성향/새로운 것에 빨리 적응하는 성향
• 캐묻기 좋아한다.
• 비판적인 사고의 소유자
• 현실적이다.
• 다방면의 기술에 익숙하다.

[실용주의 프로그래머 Tip - 1]

자신의 기술에 관심과 애정을 가져라.

[실용주의 프로그래머 Tip - 2]

자신의 일에 대해 생각하면서 일하라!

1. 실용주의 철학

1. 고양이가 내 소스코드를 삼켰어요.

책임지기

[실용주의 프로그래머 Tip - 3]

어설픈 변명을 만들지 말고 대안을 제시하라.

변명 대신에 대안을 제시하라. 안 된다고 하지 말고 상황을 개선하기 위해 무엇을 할 수 있는지 설명하라.

2. 소프트웨어 엔트로피

[실용주의 프로그래머 Tip - 4]

깨진 창문을 내버려두지 말라.

깨진 창문(나쁜 설계, 잘못된 결정, 형편없는 코드)

발견하지마자 바로 고쳐라. 고칠 시간이 없다면 판자로 덮는 것이라도 하라.

깨진 창문이 꽤 있는 프로젝트를 한다면, "나머지 코드가 전부 쓰레기니까 나도 그렇게 하지 뭐" 라는 사고로 빠져들기 너무도 쉽다.

3. 돌멩이 수프와 삶은 개구리

[실용주의 프로그래머 Tip - 5]

변화의 촉매가 되라.

큰 무리없이 요구할 수 있을 만한 것을 찾아내라. 그리고 그걸 잘 개발해라. 일단 되면, 사람들에게 보여 주고, 그들이 경탄하게 하라.

[실용주의 프로그래머 Tip - 6]

큰 그림을 기억하라.

개인적으로 무엇을 하고 있는가에만 정신을 쏟지 말고, 주변에서 무슨 일이 벌어지는지 지속적으로 살펴보라.

4. 적당히 괜찮은 소프트웨어

'적당히 괜찮은'이라는 문구는 너절하거나 형편없는 코드를 의미하지 않는다.

소프트웨어가 얼마나 좋아야 하는지 사람들에게 얼마나 자주 묻는가?

여러분이 만드는 시스템의 범위와 품질은 해당 시스템 요구사항의 일부로 명기되어야 한다.

[실용주의 프로그래머 Tip - 7]

품질을 요구사항으로 만들어라.

많은 사람들은 멀티미디어 버전을 위해 일 년을 기다리느니 차라리 오늘 당장 좀 불편한 소프트웨어를 사용하고 싶어 한다.

완벽하게 훌륭한 프로그램을 과도하게 장식하거나 지나칠 정도로 다듬느라 망치지 마라. 완벽하지 않을 수 있다. 걱정하지 마라. 완벽해지기란 불가능하다.

5. 지식 포트폴리오

주기적인 투자 - 지식 포트폴리오에 주기적으로 투자해야 한다.

다각화 - 여러가지 기술에 익숙하면 변화에 잘 적응할 수 있다.

리스크 관리 - 기술 달걀을 한 바구니에 담지 말라.

싸게 사서 비싸게 팔기 - 저 평가된 주식

검토와 재조정 - 지날달부터 탐구하기 시작한 인기 있는 기술이 지금에 와선 완전히 식어버릴 수도 있다.

[실용주의 프로그래머 Tip - 8]

지식 포트폴리오에 주기적으로 투자하라.

[목표]

• 매년 새로운 언어를 최소 하나는 배워라.
• 기술 서적을 분기마다 한 권씩 읽어라
• 비 기술 서적도 읽어라
• 수업을 들어라
• 지역 사용자 모임에 참여하라
• 다른 환경에서 실험해보라.
• 요즘 흐름을 놓치지 마라
• 인터넷을 이용하라

[실용주의 프로그래머 Tip - 9]

읽고 듣는 것을 비판적으로 분석하라.

상업주의의 힘을 절대 과소평가하지 마라. 콘텐츠 제공자가 돈을 지불했을 수 있다.

--> 블로그 마케팅, 특정 기술관점(SQL), 개발 방법론(MSA)

6. 소통하라!

• 말하고 싶은 게 무언지 알아라.
  • 개요를 작성하라. 이게 내가 말하고자 하는 것을 잘 전달하는가? 그렇게 될 때까지 다듬어라.
• 청중을 알아라
  • 청중의 요구와 관심, 능력을 이해해야 한다.
• 때를 골라라
  • 금요일 오후 6시?
  • 소스코드 일부가 사라진 일로 인해 소스코드 저장소에 대한 아이디어는 유용함
• 스타일을 골라라
  • 문서, 메모, 이메일 중 좋은 스타일을 골라라.
  • 간단하게, 상세하게?
• 멋져 보이게 하라
  • 내용에만 집중하지 말고 보기도 좋아야 한다. (요리는 맛있지만 모양새가 나쁘면 헛수고가 될 수 있다)
  • 워드 프로세서? (머리말, 꼬리말)
• 청중을 참여시켜라
  • 가능하다면 문서 초고에 독자가 참여하도록 하라. (피드백을 받고, 그딜의 머리속을 도용하라)
  • 더 좋은 관계를 형성하게 될 것이고, 더 나은 문서를 만들게 될 것이다.
• 청자(listener)가 되어라
  • 경청하지 않으면 그들 역시 여러분의 말을 귀기울여 듣지 않을 것이다.
• 응답하라
  • 누군가 질문했는데 응답없다면? 무례?
  • "다음에 답해 드리겠습니다"

[실용주의 프로그래머 Tip - 10]

무엇을 말하는가와 어떻게 말하는가 모두 중요하다.

2. 실용주의 접근법

7. 중복의 해악

지식은 고정적이지 않다. 그것은 변화한다. 급격하게. (클라이언트와 미팅 후에 변화, 정부규제 후, 알고리즘 변경)

유지보수는 애플리케이션 출시 후 시작되는게 아니라 늘 유지보수 모드에 있다. (설계, 코딩 중 항상 새로운 요구사항이 생긴다)

[실용주의 프로그래머 Tip - 11]

DRY - 반복하지 마라. (Don't Repeat Yourself)

어떻게 중복이 생기는가?

• 강요된 중복
  • 정보의 다양한 표현양식
    • 서버/클라이언트 데이터 구조
    • 코드 생성기 (빌드 될 때 여러 개의 언어에 따른 구조를 생성)
  • 코드내의 문서화
    • 주석
  • 문서화와 코드
    • 문서작성 -> 코드 작성
• 부주의한 중복
  • 설계에 의한 중복 (트럭, 배달 경로) ==> 정규화
  • 상호 의존적 데이터 (start, end, length) --> start, end, length(), 캐싱
• 참을성 없는 중복
  • 모든 프로젝트는 시간의 압박을 받는다.
  • 원래 것을 복사 후 조금만 수정 후 사용하면 쉽다(?)
  • 돌아가는 길이 지름길이다.
• 개발자간 중복
  • 개발자간 소통 부재로 인한 중복

[실용주의 프로그래머 Tip - 12]

재사용하기 쉽게 만들라.

8. 직교성

직교성(orthogonality): 하나가 바뀌어도, 다른 프로그램에 영향을 주지 않는다면 직교하다고 말한다.

독립성이나 결합도를 줄이는 것을 의미한다.

비직교적인 시스템: 헬리콥터

[실용주의 프로그래머 Tip - 13]

관련 없는 것들 간에 서로 영향이 없도록 하라.

직교적인 시스템을 작성하면 두 가지의 큰 장점이 있다.

1. 생산성 향상

• 변화가 국소화되서 개발 시간과 테스트 시간이 줄어든다.
  • 새로운 코드를 추가할 때 기존의 코드를 계속 바꾸어야 할 필요가 없다.
• 재 사용을 촉진한다.
  • 새로운 컴포넌트와 결합할 수 있다.
  • 리 엔지니어링하기 쉽다.

2. 리스크 감소

• 감염된 코드는 격리된다.
• 시스템이 잘 깨어지지 않는다.

프로젝트 팀

프로젝트 팀 구조가 얼마나 직교성을 갖는지 간단히 측정해 볼 수 있는 방법이 있다. 요청된 개별 변화에 대한 토론에 참여할 필요가 있는 사람이 몇 명인가 보라.

설계

설계 과정에서 모듈, 컴포넌트, 레이어 같은 다른 용어를 사용하기도 한다.

컴포넌트를 나누었을 때 '특정 기능에 대한 요구사항을 극적으로 변경했을 경우, 몇 개의 모듈이 영향을 받는가?' 직교적인 시스템에서는 답이 '하나'여야 한다.

GUI 패널의 단추 하나를 옮기는 것 때문에 데이터베이스 스키마가 변경되어서는 안 된다.

툴킷과 라이브러리

RMI는 직교적이지 않다.

코딩

• 코드의 결합도를 줄여라
  • shy code, demiter law
• 전역 데이터를 피하라
  • Singleton pattern
• 유사한 함수를 피하라
  • strategy pattern

테스트

모듈 수준의 테스트가 통합 테스트보다 테스트케이스를 만들고 수행한다.

문서화

내용과 표현이 두 축이 된다. 스타일시트와 매크로

9. 가역성

오늘 2인 x값이 내일은 5가 되고, 다음 주에는 3이 될 수 있다. 영원한 것은 없다.

무언가를 구현하는 방법에는 여러 가지 길이 있고, 보통 하나의 솔루션에는 여러 벤더의 제품이 존재한다.

가역성

우리가 프로젝트 초기에 항상 최선의 결정을 내리는 것은 아니라는 점

• 데이터베이스 변경 (성능상의 문제)
• 클라이언트-서버 --> 독립형 버전 or n-티어
• CORBA: java --> C++
• 유닉스 -> windows

특정 벤더 의존성은 인터페이스에 의존하게 수정해야 한다.

[실용주의 프로그래머 Tip - 14]

최종 결정이란 없다.

10. 예광탄

전에 만들어진 적이 없는 전혀 새로운 것을 만들고 있다면

요구사항 막연, 익숙하지 않은 알고리즘, 기술, 언어, 라이브러리

코딩에서도 동일한 효과를 얻으려면, 우리는 요구사항으로부터 최종 시스템의 일부 측면에까지 빨리, 눈에 보이게, 반복적으로 도달하게 해줄 무언가를 찾아야 한다.

[실용주의 프로그래머 Tip - 15]

목표물을 찾기 위해 예광탄을 써라.

• 사용자들은 뭔가 작동되는 것을 일찍부터 보게 된다.
• 개발자들은 들어가서 일할 수 있는 구조를 얻는다.
• 통합 작업을 수행할 기반이 생긴다
• 보여줄 것이 생긴다.
• 진전 상황에 대해 더 정확하게 감을 잡을 수 있다.

예광탄 코드 대 프로토타이핑

프로토타입은 최종 시스템의 어떤 특정한 측면을 탐사해 보는 것이 목표다. 대충 끼워 맞춘 것들을 모두 버린 다음, 실험 과정에서 얻은 교훈을 바탕으로 다시 코드를 만들게 된다.

예광탄 코드 접근 방법은 사용자들에게 실제로 애플리케이션의 요소들이 어떻게 상호작용하는지 보이고 싶고, 개발자들에게는 코드를 붙일 아키텍처적 골격을 제시하고 싶다.

프로토타입은 나중에 버릴 수 있는 코드를 만든다.

예광탄 코드는 기능은 별로 없지만 완결된 코드이며, 최종 시스템 골격의 일부를 이룬다.

11. 프로토타입과 포스트잇

포스트잇은 프로토타이핑해 볼 수 있는 훌륭한 도구다.

프로토타입의 대상

• 아키텍처
• 기존 시스템에 추가할 새로운 기능
• 외부 데이터의 구조 혹은 내용
• 써드파티 도구나 컴포넌트
• 성능 문제
• 사용자 인터페이스 설계

[실용주의 프로그래머 Tip - 16]

프로토타입을 통해 학습하라.

12. 도메인 언어

[실용주의 프로그래머 Tip - 17]

문제 도메인에 가깝게 프로그래밍하라.

13. 추정

[실용주의 프로그래머 Tip - 18]

추정을 통해 놀람을 피하라.

언제쯤 도착하느냐고 할머니께서 물으신다면, 아마도 점심을 준비해야 하는지 아니면 저녁을 준비해야 하는지 알기 위해서일 것이다.
반대로 물속에서 사고를 당한 다이버라면 정확히 언제 도착할 것인지에 대해 초 단위까지 관심이 있을 것이다.

[실용주의 프로그래머 Tip - 19]

코드와 함께 일정도 반복하며 조정하라.

3. 기본적인 도구

14. 일반 텍스트의 힘

• Fields19=467abc

  • 467abc의 의미가 뭔지 도무지 알 수 없을 것이다. 인간이 이해할 수 있도록 만드는 것이 더 나은 선택이다.

• DrawingType=UMLActivityDrawing

[실용주의 프로그래머 Tip - 20]

지식을 일반 텍스트로 저장하라.

15. 조개 놀이

GUI 인터페이스의 단점은 자동화할 수 없고, 쓸 수 있는 도구의 풀파워를 사용할 수 없다.

• Makefile보다 더 최근에 수정된 모든 .c 파일을 찾아라.
• 소스의 zip/tar 아카이브를 만들어라.
• 지난 주 중에 변경되지 않은 자바 파일은 어느 것들인가?
• 그 중에 어느 파일이 awt 라이브러리를 사용하나?

[실용주의 프로그래머 Tip - 21]

명령의 셸의 힘을 사용하라.

16. 파워 에디팅

[실용주의 프로그래머 Tip - 22]

하나의 에디터를 잘 사용하라.

에디터 하나를 골라서 완전히 마스터하고, 모든 편집 작업에 그 에디터를 사용하라.

17. 소스코드 관리

[실용주의 프로그래머 Tip - 23]

언제나 소스코드 관리 시스템을 사용하라.

하지만 우리 팀은 소스코드 관리 시스템을 사용하지 않는데... ==> 스스로 부끄러워해야 한다! 복음 전도를 할 기회로 들린다.

18. 디버깅

디버깅은 단지 문제 해결이라는 사실을 포용하고, 그 방식으로 공략하라.

[실용주의 프로그래머 Tip - 24]

비난 대신 문제를 해결하라.

[실용주의 프로그래머 Tip - 25]

디버깅 할 때 당황하지 마라.

[실용주의 프로그래머 Tip - 26]

'select'는 망가지지 않았다.

자신의 실수일 수 있는 일을 시스템의 문제라고 비난하는 경우

예상하지 못한 놀라운 실패를 대면했을 때 자신이 세운 가정들이 잘못되었다는 것을 깨달아야 한다.

버그에 관련된 루틴이나 코드가 제대로 작동한다고 '안다'고 해서 대충 얼버무려 지나치지 마라. 그것을 증명하라.

[실용주의 프로그래머 Tip - 27]

가정하지 마라. 증명하라.

19. 텍스트 처리

[실용주의 프로그래머 Tip - 28]

텍스트 처리 언어를 하나 익혀라.

20. 코드 생성기

[실용주의 프로그래머 Tip - 29]

코드를 작성하는 코드를 작성하라.

4. 실용주의 편집증

[실용주의 프로그래머 Tip - 30]

완벽한 소프트웨어는 만들 수 없다.

21. 계약에 의한 설계

[실용주의 프로그래머 Tip - 31]

계약에 따른 설계를 하라.

22. 죽은 프로그램은 거짓말을 하지 않는다.

[실용주의 프로그래머 Tip - 32]

일찍 작동을 멈추게 하라.

죽은 프로그램이 입히는 피해는 절름발이 프로그램이 끼치는 것보다 훨씬 덜한 법이다.

23. 단정적 프로그래밍

[실용주의 프로그래머 Tip - 33]

단정문을 사용해서 불가능한 상황을 예방하라.

"절대 일어나지 않을 거야"라는 생각이 든다면, 그걸 확인하는 코드를 추가하라. 가장 간단한 방법은 단정문을 사용하는 것이다.

24. 언제 예외를 사용할까

코드가 어떤 파일을 열어 읽으려고 하는데 그 파일이 존재하지 않는다면 예외가 발생해야 하는가?

--> 우리의 답은, '경우에 따라 다르다.' 이다.

파일이 꼭 있어야만 한다면, 예외이다.

파일이 반드시 있어야만 하는지 모른다면 에러를 반환하는 것이 적절하다.

[실용주의 프로그래머 Tip - 34]

예외는 예외적인 문제에 사용하라.

25. 리소스 사용의 균형

[실용주의 프로그래머 Tip - 35]

시작한 것은 끝내라.

이것은 리소스를 할당하는 루틴이나 객체가 리소스를 헤제하는 책임 역시 져야 한다는 것을 의미한다.

5. 구부러지거나 부러지거나

26. 결합도 줄이기와 디미터 법칙

부끄럼 타는(shy) 이란 자신을 남에게 속속들이 드러내지 말고, 너무 많은 사람과 상호작용하지 말라는 두 가지 의미를 모두 내포한다.

결합도 줄이기

상호 인지하는 모듈이 왜 나쁘다는 걸까?

디미터 함수 법칙

한 객체가 제공하는 메서드에 접근하기 위해 또 다른 객체들을 통하는 것을 허용하지 않는다.

• 한 줄에 점을 하나만 찍는다.

• 낮선 사람은 경계하고 친구랑만 놀라는 의미다.

• 묻지말고 시켜라.

java streams API도 위반인가?

[실용주의 프로그래머 Tip - 36]

모듈간의 결합도를 최소화하라.

27. 메타프로그래밍

[실용주의 프로그래머 Tip - 37]

통합하지 말고 설정하라.

메타데이터는 데이터에 관한 데이터다.

[실용주의 프로그래머 Tip - 38]

코드에는 추상화를, 메타데이터에는 세부 내용을.

이렇게 접근하면 다음의 이점이 생긴다.

• 설계의 결합도를 줄여 좀 더 유연하고 적응성 있는 프로그램을 만들 수 있다.
• 세부사항을 코드 밖으로 몰아냄으로써 보다 강하고 추상적인 디자인을 만들 수 있다.
• 애플리케이션을 커스터마이징 하기 위해 다시 컴파일 할 필요가 없다.
• 동일한 애플리케이션 엔진과 상이한 메타데이터를 이용해 여러 다른 프로젝트를 진행할 수 있게 된다.

가능한 마지막 순간까지 세부 정의를 피하고, 세부사항을 소프트하게, 변화하기 쉽게 남겨 두라. 많은 프로젝트에 범람하는 방향 전환이란 홍수에 보다 유연하게 대처할 수 있게 될 것이다.

28. 시간적 결합

[실용주의 프로그래머 Tip - 39]

작업흐름 분석을 통해 동시성을 개선하라.

[실용주의 프로그래머 Tip - 40]

서비스를 사용해서 설계하라.

[실용주의 프로그래머 Tip - 41]

언제나 동시성을 고려해 설계하라.

29. 단지 뷰일 뿐이야

[실용주의 프로그래머 Tip - 42]

모델에서 뷰를 분리하라.

30. 칠판

[실용주의 프로그래머 Tip - 43]

칠판을 사용해 작업흐름을 조율하라.

6. 코딩하는 동안 해야 할 일들

31. 우연에 맡기는 프로그래밍

지뢰밟기

[실용주의 프로그래머 Tip - 44]

우연에 맡기는 프로그래밍을 하지 말라.

32. 알고리즘의 속도

빅오 표기법

O(1) - 배열 접근, 상수

O(N) - 순차 검색

O(N logN) - 힙정렬

O(n^2) - 선택 정렬

O(2^N) - 지수적

[실용주의 프로그래머 Tip - 45]

여러분 알고리즘의 차수를 추정하라.

[실용주의 프로그래머 Tip - 46]

여러분의 추정을 테스트하라.

33. 리팩터링

리팩터링은 언제 해야 하는가?

언제나 바로 지금이 최적기다.

• 중복
• 직교성이 좋지 않은 설계
• 유효기간이 끝난 지식
• 성능

리팩터링을 하지 않는 핑계로 자주 사용되는 이유가 일정의 압박이다. 일정에 더 여유가 생기면 리팩토링을 할까?

[실용주의 프로그래머 Tip - 47]

일찍 리팩터링하고, 자주 리팩터링하라.

리팩터링해야 할 것들의 명단을 만들고 유지하라.

리팩터링은 어떻게 하는가?

1. 리팩터링과 새로운 기능 추가를 동시에 하지 말라.
2. 리팩터링을 시작하기 전 든든한 테스트 집합이 있는지 먼저 확인한다.
3. 단계를 작게 나누어서 신중하게 작업한다.

34. 테스트하기 쉬운 코드

계약을 잘 지키는지 테스트 하는 것을 강조함으로써, 프로젝트 후반부에 벌어질 수 잇는 이런 종류의 재앙들을 피하기 위한 노력을 할 수 있다.

[실용주의 프로그래머 Tip - 48]

테스트를 염두에 두고 설계하라.

[실용주의 프로그래머 Tip - 49]

소프트웨어를 테스트하라. 그렇지 않으면 사용자가 테스트하게 될 것이다.

35. 사악한 마법사

자신을 위해 만들어진 코드를 정말로 이해하지 못하는 한, 그는 자기 자신을 속이는 것이다. 우연에 맡기는 프로그램ㅇ을 하고 있다.

[실용주의 프로그래머 Tip - 50]

자신이 이해하지 못하는, 마법사가 만들어 준 코드는 사용하지 말라.

7. 프로젝트 전에

36. 요구사항의 구렁텅이

[실용주의 프로그래머 Tip - 51]

요구사항을 수집하지 말고 채굴하라.

요구사항 채굴하기

요구사항: 직원 기록은 지명된 사람들만 볼 수 있다. --> "해당 직원의 관리자와 인사부에서만 그의 기록을 열람할 수 있다"는 정정 요구사항일까?

비즈니스 정책이 내포되어 있다. 정책은 수시로 바뀐다.
이런 정책들을 요구사항에서 분리해 문서화하고 일반화 하는 것이 좋다.

개발을 통하여 요구사항을 충족하는 것이 아니고, 그들의 실질적 비즈니스 문제를 해결해야 하는 것이다. 요구사항 이면의 이유들을 문서화해 놓으면, 의사결정 할 때마다 값진 정보를 얻게 되는 셈이다.

[실용주의 프로그래머 Tip - 52]

사용자처럼 생각하기 위해 사용자와 함께 일하라.

지나치게 자세한 명세를 하는 것이 좋은 요구사항 문서화인가?

[실용주의 프로그래머 Tip - 53]

구체적인 것보다 추상적인 것이 더 오래간다.

요구사항 변경을 추정하는 것이 좋은가?

[실용주의 프로그래머 Tip - 54]

프로젝트 용어사전을 사용하라.

37. 불가능한 퍼즐 풀기

[실용주의 프로그래머 Tip - 55]

생각의 틀을 벗어나지 말고, 틀을 찾아라.

풀리지 않는 문제와 마주쳤다면, 생각해 볼 수 있는 모든 가능한 해결 경로를 눈앞에 나열해보라.

• 더 쉬운 방법이 존재하는가?
• 진짜 문제를 풀려고 노력하고 있나. 그렇지 않다면 중요하지 않은 기술적 문제에 정신이 팔려 있는 것인가?
• 왜 이것이 문제인가?
• 문제를 이렇게 풀기 어렵게 만드는 것이 무엇인가?
• 반드시 이 방법으로 해야 하는가?
• 반드시 해야 하는 일이긴 한가?

38. 준비가 되어야만

[실용주의 프로그래머 Tip - 56]

준비가 되었을 때 시작하라.

어떤 작업을 앞두고 마음속에 어던 의미심이 계속 거슬리거나 왠지 꺼림칙하다면 그 느낌을 따르라. 정확히 어떤 것이 문제라고 손가락으로 짚지 못하더라도, 시간을 좀 주면 여러분의 의심을 아마도 좀 더 단단한 것, 대응책을 생각할 수 있는 무엇으로 구체화될 것이다.

39. 명세의 함점

신반끈을 리본 모양으로 매는 방법을 설명하는 짧은 글을 하나 써보라.

[실용주의 프로그래머 Tip - 57]

어떤 일들은 설명하기보다 실제로 하는 것이 쉽다.

40. 동그라미와 화살표

[실용주의 프로그래머 Tip - 58]

형식적 방법의 노예가 되지 마라.

[실용주의 프로그래머 Tip - 59]

비싼 도구가 더 좋은 설계를 낳지는 않는다.

8. 실용주의 프로젝트

41. 실용주의 팀

• 깨진 창문을 없애라
  • 품질에 책임을 져야 한다.
• 삶은 개구리
  • 환경 변화를 감시해야 한다. 범위확장, 추가 기능, 새로운 환경, 합의되지 않은 사항 점검
• 소통하라
  • 바깥의 사람들에게 무뚝뚝하고 과묵해 보이는 프로젝트 팀이야말로 최악이다.
• 반복하지 마라
  • 중복은 노력을 남비하게 하고 결국 유지보수의 악몽을 끌어들일 수 있다.
• 직교성
  • 폭포수 모델, 위계 질서
  • 프로젝트 활동(분석, 설계, 코딩, 테스팅)이 독립적으로 이루어지는 것은 잘못된 생각이다. 프로그래머들은 자신의 작업물이 어떤 맥락에서 사용되는지 알기 어렵다.

[실용주의 프로그래머 Tip - 60]

팀을 기능 중심으로 조직하라.

• 자동화
  • 테스트를 손으로 직접 할것인가?
• 덧칠을 언제 멈출지 알아라
  • 팀은 개인들로 이루어진다. 각 팀원이 자신의 방식대로 빛나게 해 주어라.

42. 유비쿼터스 자동화

[실용주의 프로그래머 Tip - 61]

수작업 절차를 사용하지 말라.

43. 가차 없는 테스트

[실용주의 프로그래머 Tip - 62]

일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라.

[실용주의 프로그래머 Tip - 63]

모든 테스트가 통과하기 전엔 코딩이 다 된 게 아니다.

[실용주의 프로그래머 Tip - 64]

파괴자를 써서 테스트를 테스트하라.

[실용주의 프로그래머 Tip - 65]

코드 커버리지보다 상태 커버리지를 테스트하라.

[실용주의 프로그래머 Tip - 66]

버그는 한번만 잡아라.

44. 결국은 모두 글쓰기

[실용주의 프로그래머 Tip - 67]

한국어도 하나의 프로그래밍 언어인 것처럼 다루라.

내부 문서: 소스코드, 주석, 설계와 테스트 문서

외부 문서: 사용자 매뉴얼

[실용주의 프로그래머 Tip - 68]

문서가 애초부터 전체의 일부가 되게 하고, 나중에 집어넣으려고 하지 말라.

45. 위대한 유산

아이가 값비싼 크리스마스 선물을 열어 보고는 눈물을 터뜨린다. 아이가 바랐던 값싼 인형이 아니었던 것이다.

현실적으로 프로젝트의 성공은 사용자들의 기대를 얼마나 잘 충족하는가에 따라 측정된다.

[실용주의 프로그래머 Tip - 69]

사용자의 기대를 부드럽게 넘어서라.

46. 오만과 편견

[실용주의 프로그래머 Tip - 70]

자신의 작품에 서명하라.

코드의 공동 소유권