“프로그래머가 알아야 할 97가지”의 목차를 부분적으로 요약 설명과 함께 정리하였다. 다수 저자의 자료를 취합 정리하여 하나의 책으로 엮었으므로, 다소 산만하기도 하지만 프로그래머의 다양한 관점을 제공하고 있는 유용한 자료이다. 상세한 내용은 원서와 번역서를 참고하기 바란다. 원서는 책이나 eBOOK으로 구매할 수 있고, 인터넷에서 무료 PDF 파일로 다운로드 받을 수도 있다.
1.
신중하게 행동한다 Seb Rose
일정이 여유있는 프로젝트를
진행하더라도 제대로 하는 것과 빨리 하는 것 사이의 선택을 해야 할 때, 빨리 하기를 선택하면 제대로
하지 않는 기술적 부채를 갖게 된다. 기술적 부채는 가능하면 빨리 갚지 않으면 나중에 이자를 지불한다.
2.
기능적 프로그래밍 원칙 (functional programming
principles)을 적용한다 Edward Garson
3.
“사용자가 무엇을 할 것인가?”라고 묻는다. 당신은 사용자가 아니다 Giles Colborne
그들이 생각하고 원하는 것을 파악한다.
4.
코딩 표준을 자동화한다 Filip van Laenen
가능한 범위 내에서 코딩
표준을 점검하기 위한 도구를 사용한다.
5.
아름다움은 단순함에 있다 Jørn Ølmheim
단순한 코드가 아름답고, 우아하다.
6.
리팩토링을 하기 전에 Rajith Attapattu
§ 재구조화를 위한 최선의 방법은
현재의 코드와 그 코드를 위해 개발된 테스트 자료를 가지고 시작한다.
§ 모든 것을 다시 고치려는
유혹을 피한다.
§ 반복된 점진적 변경이 대규모
변경보다 좋다.
§ 매 반복마다, 현재의 테스트를 통과하는 지를 확인한다.
§ 개인적 선호와 에고를 개입시키면
안 된다.
§ 신기술이 리팩토링에 대한
이유로 충분하지 않다.
§ 사람은 실수한다는 것을 기억한다.
7.
공용화 (the share – reuse) 에 대해 주의하라 Udi Dahan
Context가 같으면, 재사용 확률이 높아진다. 의존성이 높으면 의미가 없다.
8.
보이스카웃 규칙 Robert C. Martine (Uncle Bob)
“캠핑을 시작할 때보다 더
깨끗하게 캠핑장을 청소하고 떠난다.”는 보이스카우트 규칙을 따라 체크 아웃했을 때 항상 더 깨끗한 모듈로
체크인한다.
9.
다른 사람을 비난하기 전에 먼저 자신의 코드를 리뷰한다 Allan Kelly
10.
신중하게 도구를 선택한다 Giovanni Asproni
11.
도메인 언어로 코딩한다 Dan North
12.
코드는 설계다 Ryan Brush
13.
코드 레이아웃이 중요하다 Steve Freeman
14.
코드 리뷰 Mattias Karlsson
코드리뷰는 반드시 실시 한다. 지식공유와 함께 상냥하고, 거부감 없이 편하고 재미있게, 비판적이기보다는 건설적으로 실시한다.
15.
타당성에 따른 코딩 Yechiel Kimchi
16.
주석에 관한 조언 Cal Evans
주석도 필요하다. 그러나 주석이 없어도 될 정도로 읽기 쉽게 코딩하는 것이 더 좋다.
17.
코드가 말할 수 없는 것만을 주석으로 추가한다 Kevlin Henney
18.
끊임없는 학습 Clint Shank
기술은 빠르게 변한다. 뒤 떨어지지 않기 위하여 끊임없이 공부한다.
19.
편리함은 –ility가 아니다 Gregor
Hohpe
API 구현 편의성보다는 사용 편의성이
더 중요하다.
20.
빠르게 그리고 자주 릴리즈한다 Steve Berczuk
21.
업무적인 예외와 기술적인 예외를 구분한다 Dan Bergh Johnsson
22.
의도적으로 반복하여 많이 연습 (deliberate practice) 한다 Jon Jagger
단순히 무엇인가를 반복하는
것이 아니라, 능력을 넘어서는 일에 도전하고, 열심히 계속하면서
결과를 분석하면서 실수를 고쳐 나간다.
23.
도메인에 특화된 언어를 사용한다 Michael Hunger
24.
물건을 부수는 것을 두려워하지 않는다 Mike Lewis
오믈렛을 만들 때 달걀을
깨는 것을 두려워하지 마라. 리팩토링으로 코드가 불안정해지는 것을 두려워하지 마라.
25.
프로그램 코드에 불필요한 내용을 쓰지 않는다. 결국 누군가 본다 (don’t be cute with your test data) Rod Begbie
26.
모든 에러를 무시하지 않고 처리한다 Pete Goodliffe
에러는 발견할 때 해결한다.
27.
언어만 배우지 말고 문화를 배운다 Anders Noras
28.
프로그램을 너무 높은 곳에 매달아 못박지 마라 (don’t nail your
program into the upright position) Verity Stob
너무 많은 예외 처리를 하지 말자.
29.
기적이 일어난다고 믿지 마라 Alan Griffiths
30.
스스로 반복하지 않는다 (DRY – don’t repeat yourself)
Steve Smith
코드 중복은 낭비이고, 프로세스 반복은 자동화를, 로직 반복은 추상화를 필요로 한다.
31.
스테이징 서버나 운영 서버 코드를 직접 고치면 안 된다 Cal Evans
32.
상태뿐 아니라 행위까지도 캡슐화한다 Einar Landre
33.
부동소수점 수는 실수가 아니다 Chuck Allison
부동소수점 계산 결과는 정확하지 않다. 결과
값이 중요한 업무는 주의해서 사용한다.
34.
오픈 소스를 통해 당신의 꿈을 이뤄라 Richard Monson-Haefel
35.
API 설계의 황금률 Michael Feathers
API 개발자는 개발한 API에 대한 테스트 뿐 아니라 API를 사용하는 코드에 대한 단위
테스트도 실시한다.
36.
구루 (guru) 에 대한 신화 Ryan
Brush
구루도 사람이다. 다 알 것이라고 생각하지
않는다.
37.
많은 시간 일하면 성과를 못 낸다 Olve Maudal
프로그래밍은 목적지에 도달해야만
목표 지점을 볼 수 있는 달리기와는 다르다. 프로젝트는 대략 그려진 지도를 가지고 목적지를 찾아가는
장거리 오리엔티어링 마라톤과 비슷하다.
38.
버그 트래커를 이용하는 방법 Matt Doar
버그 보고서는 최대한 상세하게
적는다.
39.
불필요한 코드를 제거하여 코드를 개선한다 Pete Goodliffe
40.
나를 인스톨한다 Marcus Bake
설치가 쉽고, 사용이 쉬운 것이 매우
중요하다.
41.
프로세스간 통신 (IPC – Inter Process Communication)은
응용프로그램 응답 시간에 영향을 미친다 Randy Stafford
42.
빌드를 깨끗하게 유지한다 Johannes Broadwall
빌드 시 발생하는 경고 메시지도 발생할 때마다 해결한다.
43.
커맨드 라인 (command line) 도구 사용법을 숙지한다 Carroll Robinson
44.
두 개 이상의 프로그래밍 언어를 습득한다 Russel Winder
45.
통합 개발 환경 (IDE – integrated development
environment) 을 이해한다 Heinz Kabutz
46.
자신의 한계를 안다 Greg Colvin
47.
다음 커밋을 파악한다 Dan Bergh Johnsson
48.
크고 서로 연결된 데이터는 데이터베이스에 저장한다 Diomidis Spinellis
49.
외국어를 배운다 Klaus Marquardt
50.
견적을 배운다 Giovanni Asproni
좋은 방법을 배운 후 반복하여 연습한다..
51.
“Hello World” 라고 말하는 것을 배운다 Thomas Guest
52.
프로젝트가 스스로 말할 수 있게 한다 Daniel Lindner
53.
링커는 마법의 프로그램이 아니다 Walter Bright
54.
임시 솔루션의 장수 Klaus Marquardt
55.
정확한 사용이 쉽고, 잘못 사용하기가 어렵도록 인터페이스를 만든다 Scott Meyers
56.
보이지 않는 것을 더 잘 보이게 하라 Jon Jagger
눈에 보이지 않는 것은 해결할
수 없으므로, 모든 이슈는 바로 파악하고 보고한다. 정상적인
프로젝트가 1주일 후에 6개월이 지연된다고 보고한다면, 프로젝트의 더 큰 문제는 6개월의 지연이 아니라 6개월 지연을 그 동안 감춘 비가시성이다.
57.
병렬 시스템에서 메시지 전달 방식은 더 나은 확장성을 제공한다 Russel
Winder
복잡한 병렬 문제를 해결하기 위하여 서로 독립적인 환경이 되도록 공유 메모리를
사용하지 않는다.
58.
미래에 대한 메시지 Linda Rising
코드는 미래의 누군가에게
보내는 메시지이므로, 읽기 쉽고, 완벽하고, 아름답고, 잊혀지지 않는 멜로디 같은 코드를 개발한다.
59.
다형성을 고려하지 않아 놓친 기회 Kirk Pepperdine
if-then-else 대신 다형성을 활용한다. if-then-else 구문을 사용하는 것이 더 실용적인 경우도 있지만, 대개
다형성을 적용하면 가독성이 높고 견고한 코드를 만들 수 있다.
60.
테스터는 당신의 친구이다 Burk Hufnagel
61.
하나의 바이너리 Steve Freeman
커스텀 바이너리를 여러 개 생성하지 말고 하나만 생성한다.
62.
오직 코드만이 진실을 말한다 Peter Sommerlad
코드를 제외한 각종 문서, 주석 등은
모두 틀릴 수 있다. 프로그램의 기능을 알려면 소스 코드를 분석하는 것이 가장 확실한 방법이다.
63.
빌드를 소유한다 (그리고 재작성한다)
Steve Berczuk
빌드는 개발 과정의 필수 부분이다. 빌드
스크립트도 코드만큼 중요하다.
64.
둘이서 프로그램을 작성하고 흐름을 느낀다 GudnyHauknes, Kari
Røssland, and Ann Katrin Gagnat
65.
원시 타입보다 도메인 특화 타입을 선호한다 Einar Landre
66.
에러를 예방한다 Giles Colborne
67.
프로페셔널 프로그래머 Robert C. Martin (Uncle Bob)
지속적인 학습을 통해 자신의
경력을 책임지고, 완벽한 코드를 작성하려는 자세를 갖고, 팀 플레이를 하고, 버그는 절대
용납하지 않는다
68.
모든 것의 버전을 관리한다 Diomidis Spinellis
69.
마우스를 내려 놓고 키보드에서 떨어진다 Burk Hufnagel
전체 흐름을 점검하기 위해서는
잠시 쉬는 것이 좋다.
70.
코드를 읽는다 Karianne Berg
책과 설계 문서도 좋지만, 더 좋은 건 코드를 직접 읽어보는 것이다.
71.
인문학을 읽는다 Keith Braithwaite
72.
가끔 처음부터 다시 개발한다 Jason P. Sage
잘 사용하고 있는 기능을
배우기 위해 의도적으로 다시 개발한다. 값진 경험을 얻을 수 있다.
73.
싱글톤 (singleton) 패턴의 유혹을 이겨낸다 Sam Saariste
싱글톤은 단점이 많으므로, 사용 전에 꼭 필요한지 다시 생각한다. 특히 단위테스트가 어렵다.
74.
성능을 얻기 위해서 더러운 코드 폭탄을 제거한다 Kirk Pepperdine
75.
단순함은 제거를 통하여 달성한다 Paul W. Homer
76.
단일 책임의 원칙 (Single Responsibility Principle)
Robert C. Martin (Uncle Bob)
하나의 서브시스템, 모듈, 클래스, 함수는 하나의 기능을 갖도록 한다.
77.
“예” 하면서 시작한다 Alex Mille
긍정적인 태도로 일을 한다.
78.
한 걸음 물러서라. 그리고 자동화, 자동화, 또 자동화 한다 Cay Horstmann
79.
코드 분석 도구를 활용한다 Sarah Mount
80.
요구되지 않은 행위가 아닌, 요구된 행위를 테스트한다 Kevlin Henney
81.
테스트를 명확하고 구체적으로 실시한다 Kevlin Henney
82.
당신이 자는 동안 (그리고 주말 동안) 테스트를
수행한다 Rajith Attapattu
83.
테스팅은 소프트웨어 개발의 공학적 엄격함을 가져온다 Neal Ford
테스트는 소프트웨어 개발에서
엄격히 지켜야 하는 규칙이다. 교량 건설자는 결코 상사로부터 “건물의
구조를 분석하지 마시요. 우리는 납기가 더 중요하니까” 라고
지시 받지는 않는다.
84.
상태에 대해 생각하기 Niclas Nilsson
상태를 명확히 구분해야 하는 경우에는 State
Machine을 사용한다.
85.
한 사람보다 대부분 두 사람이 더 낫다 Adrian Wible
86.
두 번의 잘못이 옳은 것을 만들 수 있다 (그리고 고치기 어렵다) Allan Kelly
버그 두 개가 서로 영향을 주어서 둘 다 드러나지 않는 경우가 있다. 버그를 발견하기도 어렵지만 수정하기는 더 어렵다.
87.
친구들을 위한 우분투 코딩 Aslam Khan
88.
유닉스 도구는 여러분의 친구이다 Diomidis Spinellis
89.
올바른 알고리즘과 자료 구조를 사용한다 Jan Christiaan “JC” van Winkel
90.
장황한 로깅은 잠을 방해한다. 필요한 로그만 기록한다 Johannes Brodwall
91.
WET (write every time) 은 성능 병목을 찾기 힘들게
한다 Kirk Pepperdine
동일한 코드를 중복하는 것은 좋지 않다.
92.
프로그래머와 테스터가 협업할 때 Janet Gregory
개발자와 테스트는 적이 되기 쉽다. 서로에게
배울 점이 있으며 서로 도움이 되도록 협업한다.
93.
평생 지원해야 하는 것처럼 코드를 작성한다 Yuriy Zubarev
94.
예를 사용해 작은 함수를 작성하라 Keith Braithwaite
특정 도메인에 집중하면 고려하는 대상이 좁아지고 문제가 더 쉬워진다.
95.
사람들을 위해 테스트 문서를 작성한다 Gerard Meszaros
테스트는 코드를 어떻게 사용하는지, 무슨
일을 하는지를 자세히 작성한다.
96.
코드에 주의를 기울인다 Pete Goodliffe
고객이 말한 것과 의미한 것은 다르다 Nate Jackson
댓글 없음:
댓글 쓰기