1) 신중하게 행동하라
"기술채무를 기록해서 추적하고 가능한 한 빨리 갚아야 한다"
제대로 하기와 빨리 하기 선택 시 빨리 하기 선택하면서 발생하는 기술 채무(technical debt)
2) 함수형 프로그래밍 법칙을 적용하라
"변하기 쉬운 멤버 변수를 참조하기 보다 그것을 함수의 인자로 전달하고 좀 더 작고, 많은 수의 함수로 책임을 나누는 형태의 설계"
참조 투명성(referential transparency)를 높여야 한다
함수들이 주어진 같은 입력에 대해 언제 어디서 호출되는지 상관없이 지속적으로 같은 결과를 얻는 것
상태가 변하는 부작용에 전혀 의존하지 않는다는 것
3) 당신은 사용자가 아니다
"요구사항을 분석하는 가장 좋은 방법은 사용자를 관찰하는 것"
사용자에게 물어보는 것은 좋지 않은 방법
프로그래머가 사용자 입장이 되는 것이 대단히 어렵다.
4) 코딩 표준을 자동화하라
"코딩 표준을 만들고 자동화해야 한다"
자동화 가능한 것은 모두 자동화할 수 있도록
5) 아름다움은 단순함에 있다.
"코드를 간단하고 명료하게"
단순한 코드가 가독성, 유지보수성, 개발속도를 보장
6) 리팩토링하기 전에
"기존 코드의 장단점을 평가해서 기존 코드의 실수를 파악하고 여러 번 피드백 받으면서 수정하고 기존 테스트를 모두 통과하도록 해야한다"
모든 것을 새로 작성하려는 유혹을 피하고, 제품화한 코드를 버리지 말아라
새로운 언어와 프레임워크가 답이 아니다
리팩토링을 한다고 항상 새로운 코드가 더 좋아진다고 장담할 수 없다.
7) 공용화에 대해 주의하라
"올바른 문맥에서 공용화를 검토해라"
8) 보이스카웃 규칙
"원래 소유주가 누구였든간에 스스로 항상 그 모듈을 개선하기 위하여 조금이라도 노력을 기울여야 한다"
모듈을 체크아웃할 때보다 더 개선해서 체크인해야 한다.
9) 다른 사람을 비난하기 전에 먼저 자신의 코드를 리뷰하라
"일관성있게 버그를 찾기 위해서는 디버깅과 단위테스트에만 의존할 수 없고 설계를 단순하게 하는 것에 더 큰 비중을 두어야 한다"
툴 오류는 극히 일부
10) 심사숙고해서 도구를 선택하라
"반드시 필요한 도구만을 사용해서 조금씩 시작해라"
open source나 구매하는 것이 직접 개발하는 것보다 더 저렴하고 안정적일 수 있으나 라이센스 정책, 설정, 도구 실행 환경을 잘 고려해야 한다.
11) 도메인 언어로 코딩하라
"코드를 추상화해서 도메인 개념으로 접근할 수 있도록 해라"
내부 구현을 모두 드러낼 필요없이
12)코드는 설계다
"좋은 설계를 얻을 수 있는 방법을 찾자"
설계 비용 예측의 중요성은 높아지고 있지만 신뢰할 만한 결과를 얻기는 쉽지 않다.
13) 코드 레이아웃은 중요하다
"가능한 한 코드를 읽기 쉽게 작성해라"
실제 동작하는 코드를 작성하는 것보다 수정할 부분을 찾아내기 위해 코드 읽는 것이 더 많은 시간이 걸린다
14) 코드 리뷰
"코드리뷰는 코드상 실수를 고치는 것이외 지식을 공유하고 공통 코드 가이드라인을 구축하는 과정"
리뷰 결과 논평은 상냥해야 하고 비판적이기보다 건설적이어야 한다
15) 이치에 맞는 코딩
"코딩 규칙을 정해서 지켜라"
이름을 잘 짓고, 변수는 가능한 한 가장 작은 영역을 가지도록, 함수는 짧고 적은 수 인자를 가지도록, 캡슐화
16) 주석에 관한 조언
"코드가 코드의 내용을 다른 프로그래머에게 스스로 설명해야 한다"
쓰기가 어려우면 읽기도 어렵다
17) 단지 코드가 말하지 않는 것을 주석으로 추가해라
"코드 자체로도 충분히 많은 것을 설명할 수 있도록 만들어라"
코드가 표현할 수 없는 것만 주석으로 작성해라.
코드를 흉내내는 주석은 필요없다.
18) 끊임없는 배움
"조금씩 시간내서 계속 공부해라"
19) 편리함은 명사형이 아니다
"구현하기 편한 것이 아니라 사용하기 편하도록 API를 설계해라"
가이드라인 원칙을 안다고 해서 그것을 잘 실천할 수 있는 것은 아니다.
20) 자주 빠르게 릴리즈하라
"릴리즈는 초반부터 시작해서 릴리즈 프로세스를 실험해서 개선시켜라"
21) 상황에 맞는 에외처리가 필요하다
"기술적인 예외와 비즈니스 예외를 분리해서 처리해라"
에러처리를 직접 해결하려는 시도가 실수가 될 수 있으니 에러를 최상위로 전달해서 일반적인 예외처리 매커니즘을 동작하게 하라
22) 많은 의도적 수련 - 계획된 연습을 하라
"꾸준히 계속 연습해라"
일을 끝내기 위한 것이 아닌 정복하기 위해!
만 시간의 법칙
23) 도메인에 특화된 언어들
"도메인 특화 언어의 대상이 되는 청중을 고려해야 한다"
24) 부수는 것을 두려워하지 마라
"점진적으로 리팩토링을 수행하고, 리팩토링해야할 대상목록을 유지해라"
25) 테스트 데이터를 속이지 마라
"코드, 주석, 로그, 대화창, 테스트 데이터를 신중하게 작성해라"
26) 에러는 발견 즉시 고쳐라
"에러는 발생했을 때 바로 확인해라"
27) 언어만 배우지 말고 문화를 배워라
"다양한 언어의 방식을 익혀 문제를 해결하는 방법을 찾자"
매년 새로운 언어를 배우자
28) 프로그램을 너무 높은 곳에 매달아 못박지 마라
"예외처리를 너무 많이 사용하지 말자"
에러가 발생할 경우 가장 바람직한 태도는 무엇인가?
29) 기적이 일어난다는 생각을 버려라
"모든 일은 각각 열심히 해서 진행되는 것이지 한번에 되는 것이 아니다"
경험이 없으면 쉽게 말한다
잘 진행된다는 것은 다들 각자에서 열심히 하고 있는 것
30) 중복을 제거하라
"프로세스 중복은 자동화를, 로직의 중복은 추상화를 해라"
Don't repeat yourself.
31) 그 코드를 건드리면 안된다
"개발자는 개발서버에만 접근하고, 운영서버는 버그를 고치는 곳이 아니다"
32) 상태 뿐 아니라 행위까지도 캡슐화하라
"객체간의 상호작용을 통해 다른 객체에게 책임을 할당하고 위임하라"
캡슐화
33) 부동 소수점수는 실수가 아니다
"부동소수점 수는 실제 존재하는 수의 근사값으로 반올림 오차를 고려해야 한다"
부동 소수점 수는 제한된 유효숫자를 가진 유한 수
34) 오픈 소스를 통해 잠자고 있는 열망을 이뤄라
"오픈 소스에 참여해라"
35) API 설계의 황금률
"API 설계 시에 API를 위한 테스트 뿐만 아니라 API를 사용하는 코드들을 위한 테스트도 이뤄져야 한다"
36) 구루에 대한 근거없는 믿음
"구루도 역시 사람이고, 구루가 다 해결해준다는 생각을 하지 말고 스스로 구루가 되려고 노력해라"
37) 고생은 성과를 내지 못한다
"교육과 학습을 통해 계속 준비하면서 일정 속도를 유지하면서 일을 해야 한다"
38) 버그 트래커를 이용하는 방법
"버그 리포트는 버그 재현 경로, 빈도, 정상 결과, 실제 결과를 같이 작성해줘야 한다"
버그는 작업의 표준 단위가 아니다
39) 제거를 통해 코드를 개선하라
"지금 당장 필요한 코드만 구현해라"
그것이 모두 필요한 작업인가요?
40) 나를 인스톨하라
"설치 위치를 알려주고, 완벽하게 제거되도록, 쓰기 쉽고 튜토리얼이 제공되는 프로그램을 만들어라"
41) 프로세스간 통신은 응용프로그램 반응 시간에 영향을 미친다
"원격 프로세스 간 통신이 있을 경우, 여기서 성능 개선이 이루어져야 한다"
목적에 맞는 필요한 데이터만 교환하고, 통신을 병렬화하고, 통신 내용을 캐시하는 방법 이용
42) 빌드를 깨끗하게 유지하라
"빌드 시 나온 경고는 예외없이 고쳐야 한다"
43) 커맨드 라인 도구 사용법을 알아라
"커맨드 라인 도구를 이용해 배우고 통합 개발 환경을 이용해라"
통합 개발 환경을 사용하면 실제로 도구가 무엇을 하는지 충분히 이해하기 어렵다
44) 두 개 이상의 프로그래밍 언어를 습득하라
"프로그래밍을 통해 프로그래밍 패러다임을 익혀라"
프로그래밍 언어는 프로그래머가 소프트웨어에 대해 생각하는 방법에 지배적인 영향을 끼침
절차적, 객체 지향적, 기능적, 로직, 데이터 흐름 패러다임에 맞는 언어
45) 자신의 통합 개발 환경을 이해하라
"개발환경툴의 기본적인 사용법 이상을 익혀라"
46) 자신의 한계를 알아라
"리소스가 한정되어 있으니, 알고리즘과 데이터구조를 효율적으로 해라"
47) 다음 커밋을 알아라
"일의 전체 그림을 그리고, 일을 세분화해라"
48) 서로 연결된 큰 데이터는 데이터베이스에 속한다
"데이터베이스를 활용해라"
49) 다른 세계의 언어를 배워라
"여러 다른 분야 사람들도 이해할 수 있는 언어를 사용해서 설명해라"
프로그램에 대한 지식이 없는 사람에게 내용을 전달하는 것
50) 예측하는 것을 배워라
"적절한 프로젝트 관리 계획을 세우고 실현 가능한 목표를 바탕으로 커밋먼트를 작성해라"
51) 'Hello World'를 작성하는 것을 배워라
"전체를 테스트하려고 하지 말고, 부분을 띄어서 테스트해라"
간단하게 생각하고, 통합 개발도구에 너무 의존하지 말아라
52) 프로젝트가 스스로 말할 수 있게 하라
"형상 관리 시스템, 빌드 시스템, 코드 측정 시스템은 자동으로 돌아가고 측정되는 수치 변화가 있을 때 개발자에게 알려줘야 한다"
Extreme Feedback Device
53) 링커는 마법의 프로그램이 아니다
"링커가 하는 일을 잘 알고 경고 메시지 세부 내용을 확인해야 한다"
링커는 오브젝트 파일의 코드와 데이터 영역을 통합하고 심볼을 참조하는 부분을 선언부와 연결한 후 선언부를 확인할 수 없느 심볼을 라이브러리에서 추출해 실행파일을 만듬
54) 임시 솔루션의 장수
"시스템에 임시 솔루션이 많아질수록 복잡도 증가되고 유지보수는 어려워진다"
55) 정확한 사용이 쉽고, 잘못된 사용이 어려운 인터페이스를 만들어라"
"사용자 관점에서 인터페이스를 설계해라"
API는 사용하는 사람을 위해 존재하는 것
56) 보이지 않는 것을 더 잘 보이게 하라
"진척사항을 파악할 수 있도록 프로젝트 가시성을 확보해라"
눈으로 확인할 수 있는 결과가 필요하다
57) 병렬 시스템에서 메시지 전달방식은 더 나은 확장성을 제공한다
"공유메모리보다 메시지 전달방식을 이용하여 동시성을 해결해라"
경쟁상태, 교착 상태, 무한 반복의 동시성 문제는 공유메모리와 관련되어 있다
58) 미래로의 메시지
"내가 작성한 모든 코드는 미래의 어떤 사람에게 전달되는 메시지이다"
59) 다형성을 고려하지 않아 놓쳐버린 기회들
"다형성을 적용한 코드가 더 적은 양으로도 가독성이 높고 견고한 코드 생성이 가능하다"
60) 이상한 뉴스: 테스터는 여러분의 친구다
"테스터는 코드에서 버그를 잡아주는 꼭 필요한 존재이다"
61) 하나의 바이너리
"환경에 대한 세부 설정은 분리해서 별도로 유지하고 하나의 바이너리를 만들어라"
환경 정보 버전도 유지해야 한다.
62) 오직 코드만이 진실을 말한다.
"프로그램이 무엇을 하는지 알고자 한다면 소스코드를 살펴보는 것이 가장 확실한 방법이다"
좋은 이름, 간단한 주석
63) 빌드를 소유하라(그리고 재작성하라)
"빌드 스크립트도 코드이고 빌드 프로세스를 충분히 학습해라"
64) 짝 프로그래밍으로 흐름을 느껴라
"동료 개발자와 같이 프로그래밍을 통해 익혀라"
65) 원시타입보다 도메인에 특화된 타입을 선호하라
"품질높은 소프트웨어 개발을 위해서는 도메인에 특화된 타입을 사용해야 한다"
추상 데이터 타입을 이용하여 강력한 타입 체크를 해라
66) 에러를 예방하라
"에러가 생기지 않도록 잘 설계해라"
지침은 에러를 예방하는데 효과적이지 않음
67) 프로페셔널 프로그래머
"작성한 코드에 대해 책임을 지고, 최신 동향을 파악해라"
68) 모든 것의 버전을 관리하라
"모든 프로젝트의 자산을 버전 관리해라"
논리적인 변경을 별도 작업으로 커밋하고 커밋마다 메시지 작성해라
69) 마우스를 내려놓고 키보드에서 떨어져라
"계속 고민한다고 해서 답이 나오지 않는다. 적당한 휴식이 필요하다"
70) 코드를 읽어라
"프로그래밍 실력을 향상시키기 위해서는 코드를 읽어라"
다른 사람의 코드로부터 배워라
71) 인문학을 읽어라
"소프트웨어 개발은 사람과 관계된 비즈니스"
72) 처음부터 다시 개발하라
"개발자의 기술 향상을 위해 처음부터 다시 개발해 볼 필요가 있다"
73) 싱글톤 패턴의 유혹을 견뎌라
"인스턴스 두개 이상 생기지 않아야 할 때만 싱글톤 패턴을 사용해라"
전역 접근을 위한 목적으로 사용하지 말아라
74) 좋은 성능에 이르는 길에는 더러운 코드 폭탄이 곳곳에 도사리고 있다
"메트릭은 성능 개선 작업 과정에서 리스크를 줄 수 있는 부분을 사전에 인지할 수 있도록 도와준다"
메트릭을 활용할 때 경험에 바탕을 두어야지 수식에만 집중하면 안된다
75) 단순함은 제거로부터 온다
"코드는 간단해야 한다"
76) 단일 책임의 원칙
"모든 객체는 하나의 책임을 가지고, 책임에 대한 변경이 있을 때 관련된 책임이 있는 객체만 수정해야 한다"
77) '예'로 시작하라
"새로운 요구사항이 들어왔을 때 안된다고 하는 방어 자세를 버려야 한다"
78) 한걸음 물러서라 그리고 자동화, 자동화, 또 자동화를 하라
"자동화가 중요하다"
79) 코드 분석 도구를 활용하라
"코드 분석 도구를 이용하여 정적분석을 하라"
테스트를 품질 보증 활동의 전부라고 생각하지 말아라
80) 부수적 행위가 아닌, 실제 요구된 행위에 대해 테스트를 수행하라
"효과적인 테스트는 원래 해야할 일을 하고 있는지를 하고 있는 것이고 블랙박스 관점에서 단위테스트를 수행해라"
81) 테스트를 명확하고 구체적으로 수행하라
"테스트의 사후조건을 명확히, 구체적으로 작성해야 한다"
82) 당신이 자는 동안(그리고 주말동안) 테스트를 수행하라
"정상근무 외 시간의 컴퓨팅 파워를 이용하여 자동화 테스트를 하라"
83) 테스팅은 소프트웨어 개발의 엔지니어링 리거다
"테스트만으로 충분하지 않지만 테스트는 꼭 필요하다"
84) 상태에 대해 생각하기
"상태를 명확히 설정해야한다"
85) 종종 한 사람보다 두사람이 낫다
"혼자 일하기보다 같이 일하는 짝 프로그래밍을 통해 많은 것을 얻을 수 있다"
86) 두 번의 잘못이 옳은 것을 만들 수 있다 (그리고 이것은 고치기 어렵다)
"side effect을 고려해야 한다"
87) 친구들을 위한 우분투 코딩
"좋은 품질의 코드는 모든 사람에게 영향을 준다"
88) 유닉스 도구는 여러분의 친구다
"유닉스 도구는 확장 가능하며 여러 곳에 쉽게 적용할 수 있다"
89) 올바른 알고리즘과 자료구조를 사용하라
"알고리즘과 데이터 구조의 선택은 매우 중요하다"
꾸준히 기본기를 다져야 한다
90) 장황한 로깅은 잠을 방해할 것이다
"에러 로그는 정확히, 간단히"
91) WET은 성능 병목을 찾기 힘들게 한다
"하나의 시스템 안에 있는 모든 지식을 단일하게 표현해라"
Don't repeat yourself.
WET(Write Every Time)
92) 프로그래머와 테스터가 협업할 때
"프로그래머와 테스터는 서로 신뢰하면서 협업해야 한다"
93) 마치 평생 지원해야 하는 것처럼 코드를 작성하라
"항상 최고 품질의 코드를 낼 수 있도록 노력해야 한다"
94) 예를 사용해 작은 함수를 작성하라
"기본 자료형보다 문제 도메인과 밀접하게 연관된 자료형 사용"
95) 사람들을 위해 테스트를 작성하라
"자동화 테스트"
96) 코드에 주의를 기울여라
"좋은 코드에 관심을 가질 때만 좋은 코드를 얻을 수 있다"
마음가짐이 적당한 프로그래머와 훌륭한 프로그래머 사이의 진짜 차이
지옥으로 가는 코드는 좋은 의도로 도배되어 있다
97) 고객이 말한 것과 의도한 것은 다르다
"초기 단계부터 고객과 자주 만나야 한다"
고객은 그들의 관점에서, 그들만의 용어를 사용한다
고객은 처음에는 정말로 원하는 것이 무엇인지 모른다
[ 그 외 ]
1) 개발자로 늙고 싶다면 코딩(코더)에서 벗어나라
"시스템 전체를 아우르는 시각과 비즈니스적인 마인드"
2) 과거에서 미래를 찾아라
"새로 나오는 기술은 과거의 기술로부터 출발, 팀워크와 열정이 중요하다"
3) 훌륭한 소프트웨어를 개발하기 위해 필요한 것
"소프트웨어 개발 프로세스, 아키텍처와 아키텍트, 자기 계발, 좋은 사람들, 비즈니스 이해 능력"
4) 잘못 알려진 디자인 패턴의 두번째 원칙
"구현 상속보다 인터페이스 상속을 기반으로 한 객체 조합을 이용해라"
5) 좋은 소프트웨어의 개발은 서로를 이해하면서 시작된다
"소프트웨어 개발하는 사람들간의 존중과 이해"
6) 개발자-"?" = 0
"호기심을 계속 키워라"
프로젝트에 정답은 없다. 프로젝트 별로 상황에 맞는 최적의 방법만이 있다
7) 피드백
"참여자간의 긴밀하고 잦은 협업, 수시 피드백"
8) 너의 언어는 너의 사고의 한계이다
"다양한 프로그래밍 언어, 관련 기술을 지속적으로 파악해라"
하나의 언어를 배운다는 것은 언어 자체의 의미보다 언어를 사용하는 사람의 사고를 배우는 것
9) 개발자들이 가져야 할 것
"자신의 제품을 가지고 주위와 계속 소통하라"
10) 공유하고 연대해라
"자발적인 공유와 연대"
'생산성' 카테고리의 다른 글
| 프리젠테이션 태반이 지루한 이유··· 해법은 '작가 스타일' (0) | 2015.03.16 |
|---|---|
| 프로젝트 망치는개발자, 살기리는개발자 (0) | 2015.03.07 |
| 부자들이 매일하는 20가지 (0) | 2015.03.06 |
| 왜 적은 인원으로 빨리 개발하나…개발문화의 비밀 (0) | 2015.03.05 |
| 시간관리10계명 (0) | 2015.02.25 |
