실용주의 프로그래머

ISBN:

2011-11-13

손 닿는 데 두고, 틈 날 때마다 보자. 아래는 팁 목록, 책 제일 뒤에 달린 종이에는 이 팁 목록과 함께 짤막한 설명도 달려 있다. 당연히 저작권은 저자한테 있고, 별로 침해할 생각은 없음. 일단 기억용&검색 빨리하려고 올려둠.

실용주의 프로그래머 팁 목록

자신의 기술에 관심과 애정을 가져라
자신의 일에 대해 생각하면서 일하라
어설픈 변명을 만들지 말고 대안을 제시하라
깨진 창문을 내버려두지 말라
변화의 촉매가 되라
큰 그림을 기억하라
품질을 요구사항으로 만들어라
지식 포트폴리오에 주기적으로 투자하라
읽고 듣는 것을 비판적으로 분석하라
무엇을 말하는가와 어떻게 말하는가 모두 중요하다
DRY-반복하지 마라
재사용하기 쉽게 만들라
관련 없는 것들 간에 서로 영향이 없도록 하라
최종결정이란 없다
목표물을 찾기 위해 예광탄을 써라
프로토타입을 통해 학습하라
문제 도메인에 가깝게 프로그래밍하라
추정을 통해 놀람을 피하라
코드와 함께 일정도 반복하며 조정하라
지식을 일반 텍스트로 저장하라
명령어 셀의 힘을 사용하라
하나의 에디터를 잘 사용하라
언제나 소스코드 관리 시스템을 사용하라
비난 대신 문제를 해결하라
디버깅을 할 때 당황하지 마라
'select'는 망가지지 않았다
가정하지 마라, 증명하라
텍스트 처리 언어를 하나 익혀라
코드를 작성하는 코드를 작성하라
완벽한 소프트웨어는 만들 수 없다
계약에 따른 설계를 하라
일찍 작동을 멈추게 하라
단정문을 사용해서 불가능한 상황을 예방하라
예외는 예외적인 문제에 사용하라
시작한 것은 끝내라
모듈간의 결합도를 최소화하라
통합하지 말고 설정하라
코드에는 추상화를, 메타데이터에는 세부 내용을
작업흐름 분석을 통해 동시성을 개선하라
서비스를 사용해서 설계하라
언제나 동시성을 고려해 설계하라
모델에서 뷰를 분리하라
칠판을 사용해 작업흐름을 조율하라
우연에 맡기는 프로그래밍을 하지 말라
여러분의 알고리즘의 차수를 추정하라
여러분의 추정을 테스트하라
일찍 리팩터링하고, 자주 리팩터링하라
테스트를 염두에 두고 설계하라
소프트웨어를 테스트하라. 그렇지 않으면 사용자가 테스트하게 될 것이다
자신이 이해하지 못하는, 마법사가 만들어준 코드는 사용하지 말라
요구사항을 수집하지 말고 채굴하라
사용자처럼 생각하기 위해 사용자와 함께 일하라
구체적인 것보다 추상적인 것이 더 오래간다
프로젝트 용어사전을 사용하라
생각의 틀을 벗어나지 말고 틀을 찾아라
준비가 되었을 때 시작하라
어떤 일들은 설명하기보다 실제로 하는 것이 더 쉽다
형식적 방법의 노예가 되지 마라
비싼 도구가 더 좋은 설계를 낳지는 않는다
팀을 기능 중심으로 조직하라
수작업 절차를 사용하지 말라
일찍 테스트하고, 자주 테스트하라, 자동으로 테스트하라
모든 테스트가 통과하기 전엔 코딩이 다 된 게 아니다
파괴자를 써서 테스트를 테스트하라
코드 커버리지보다 상태 커버리지를 테스트하라
버그는 한 번만 잡아라
한국어도 하나의 프로그래밍 언어인 것처럼 다루라
문서가 애초부터 전체의 일부가 되게하고 나중에 집어넣으려고 하지 말라
사용자의 기대를 부드럽게 넘어서라
자신의 작품에 서명하라

간단한 거긴 하지만, 여기서 하라는 대로(22,28) vi로 정규표현식을 사용해서 html코드를 넣어봤다. %s/^(.*)$/<li>1</li>/g

아래는 체크리스트

실용주의 프로그래머 체크리스트

배울만한 언어

다른 언어를 배워 보라. CLOS, Dylan, Eiffel, Objective C, Prolog, Smalltalk, TOM...

WISDOM놀이

What - 무엇을 배우길 원하나?
Interest - 말하려는 것에서 관심있어 하는 것은 무엇인가?
Sophisicated - 얼마나 소양이 있는가?
Detail - 어느 정도 구체적인 내용을 원하는가?
Own - 누가 정보를 소유하길 원하는가?
Motivate - 동기를 주려면 어떻게 해야 할까?

직교성을 유지하는 방법

독립적이고, 잘 정의된 컴포넌트를 설계하라.
코드의 결합도를 줄여라
전역 데이터를 피하라
비슷한 함수들을 리팩터링하라

프로토타입을 만들 것들

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

아키텍처에 관련된 질문

책임이 잘 정의되었는가?
협력이 잘 정의되었는가?
결합도는 최소화되었는가?
잠재적 중복을 찾아낼 수 있는가?
인터페이스 정의와 제약사항은 수용할 만 한가?
모듈이 필요한 데이터에 필요한 때 접근할 수 있는가?

디버깅 체크리스트

보고된 문제가 내재하는 버그의 직접적 결과인가 아니면 단순히 증상일 뿐인가?
버그가 정말로 컴파일러에 있나? OS에 있나? 아니면 여러분 코드에 있나?
이 문제를 동료에게 상세히 설명한다면 어떻게 말하겠는가?
의심이 가는 코드가 단위 테스트를 통과한다면, 테스트는 충분히 완전한 것인가? 이 데이터로 단위 테스트를 돌리면 무슨 일이 생기는가?
이 버그를 야기한 조건이 시스템의 다른 곳에도 존재하는가?

디미터 함수 법칙

어떤 객체의 메서드는 오직 다음 목록에 들어있는 메서드들만 호출해야 한다.

자기 자신
전달받은 매개 변수
자신이 생성한 객체
컴포넌트 객체

의도적으로 프로그래밍 하는 방법

지금 자신이 무엇을 하고 있는지 항상 의식하라.
맹목적으로 코딩하지 말라
계획을 세우고 그것을 바탕으로 진행하라
신뢰할 수 있는 것에만 기대라
여러분이 내린 가정을 문서로 남겨라
코드뿐 아니라 가정도 테스트하라
노력의 우선순위를 정하라
과거의 노예가 되지 말라

언제 리팩토링을 해야 하는가

DRY원칙의 위반을 발견했을 때
더 직교성이 좋게 만들 수 있는 것듰을ㄹ 찾았을 때
여러분의 지식이 더 나아졌을 때
요구사항이 진화했을 때
성능을 향상시킬 필요가 있을 때

고르디우스의 매듭을 자르기

불가능해 보이는 문제를 풀 때, 스스로에게 다음처럼 질문해 보라

더 쉬운 방법이 있는가?
지금 진짜 문제를 풀고 있는가?
왜 이것이 문제인가?
무엇이 이것을 어렵게 만드나?
반드시 이 방법으로 해야 하는가?
반드시 해야 하는 일인가?

테스트의 유형

단위 테스트
통합 테스트
유효성 평가와 검증
자원 고갈, 에러 그리고 복구
성능 테스트
사용편의성 테스트
테스트 자체를 테스트하기

잘 샀다.

독서기록

디퍼런트 구글을 지탱하는 기술