How to be a Programmer

How to be a Programmer: A Short, Comprehensive, and Personal Summary

프로그래머가 되는 방법: 짧고 폭넓고 개인적인 요약.

번역 원문은

http://wiki.kldp.org/wiki.php/HowToBeAProgrammer#s-6.3

영어로된 원문은..

http://samizdat.mines.edu/howto/HowToBeAProgrammer.pdf

번역 처로 강창기

Copyright © 2002, 2003 Robert L. Read

Permission is granted to copy, distribute and/or modify this d0cument under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with one Invariant Section being 'History (As of May, 2003)', no Front-Cover Texts, and one Back-Cover Text: 'The original version of this d0cument was written by Robert L. Read without renumeration and dedicated to the programmers of Hire.com.' A copy of the license is included in the section entitled 'GNU Free Documentation License'.

목차

목차

1 도입

2 초보자

2.1 개인적 기능들

2.1.1 디버그 배우기

2.1.2 문제 공간을 나눠서 디버그 하는 방법

2.1.3 오류를 제거하는 방법

2.1.4 로그를 이용해서 디버그 하는 방법

2.1.5 성능 문제를 이해하는 방법

2.1.6 성능 문제를 해결하는 방법

2.1.7 반복문을 최적화하는 방법

2.1.8 I/O 비용을 다루는 방법

2.1.9 메모리를 관리하는 방법

2.1.10 가끔씩 생기는 버그를 다루는 방법

2.1.11 설계 기능을 익히는 방법

2.1.12 실험을 수행하는 방법

2.2 팀의 기능들

2.2.1 시간 추정이 중요한 이유

2.2.2 프로그래밍 시간을 추정하는 방법

2.2.3 정보를 찾는 방법

2.2.4 사람들을 정보의 원천으로 활용하는 방법

2.2.5 현명하게 문서화하는 방법

2.2.6 형편없는 코드를 가지고 작업하기

2.2.7 소스 코드 제어 시스템을 이용하는 방법

2.2.8 단위별 검사를 하는 방법

2.2.9 막힐 때는 잠깐 쉬어라

2.2.10 집에 갈 시간을 인지하는 방법

2.2.11 까다로운 사람들과 상대하는 방법

3 중급자

3.1 개인적 기능들

3.1.1 의욕을 계속 유지하는 방법

3.1.2 널리 신뢰받는 방법

3.1.3 시간과 공간 사이에서 균형을 잡는 방법

3.1.4 압박 검사를 하는 방법

3.1.5 간결성과 추상성의 균형을 잡는 방법

3.1.6 새로운 기능을 배우는 방법

3.1.7 타자 연습

3.1.8 통합 검사를 하는 방법

3.1.9 의사소통을 위한 용어들

3.2 팀의 기능들

3.2.1 개발 시간을 관리하는 방법

3.2.2 타사 소프트웨어의 위험 부담을 관리하는 방법

3.2.3 컨설턴트를 관리하는 방법

3.2.4 딱 적당하게 회의하는 방법

3.2.5 무리 없이 정직하게 반대 의견을 내는 방법

3.3 판단 능력

3.3.1 개발 시간에 맞춰 품질을 조절하는 방법

3.3.2 소프트웨어 시스템의 의존성을 관리하는 방법

3.3.3 소프트웨어의 완성도를 판단하는 방법

3.3.4 구입과 개발 사이에서 결정하는 방법

3.3.5 전문가로 성장하는 방법

3.3.6 면접 대상자를 평가하는 방법

3.3.7 화려한 전산 과학을 적용할 때를 아는 방법

3.3.8 비기술자들과 이야기하는 방법

4 상급자

4.1 기술적 판단 능력

4.1.1 어려운 것과 불가능한 것을 구분하는 방법

4.1.2 내장 언어를 활용하는 방법

4.1.3 언어의 선택

4.2 현명하게 타협하기

4.2.1 작업 일정의 압박과 싸우는 방법

4.2.2 사용자를 이해하는 방법

4.2.3 진급하는 방법

4.3 팀을 위해 일하기

4.3.1 재능을 개발하는 방법

4.3.2 일할 과제를 선택하는 방법

4.3.3 팀 동료들이 최대한 능력을 발휘하게 하는 방법

4.3.4 문제를 나누는 방법

4.3.5 따분한 과제를 다루는 방법

4.3.6 프로젝트를 위한 지원을 얻는 방법

4.3.7 시스템이 자라게 하는 방법

4.3.8 대화를 잘 하는 방법

4.3.9 사람들에게 듣고 싶어 하지 않는 말을 하는 방법

4.3.10 관리상의 신화들을 다루는 방법

4.3.11 조직의 일시적 혼돈 상태를 다루는 방법

5 참고 문헌

5.1 책

5.2 웹 사이트

6 역사 (2003년 5월 현재) / History (As Of May, 2003)

6.1 피드백 및 확장 요청 / Request for Feedback or Extension

6.2 원본 / Original Version

6.3 원저자의 경력 / Original Author's Bio

[edit]

1 도입 ¶

좋은 프로그래머가 되는 것은 어렵고도 고상한 일이다. 소프트웨어 프로젝트의 공동 비전을 현실화하려고 할 때 가장 어려운 부분은 함께 일하는 개발자들과 고객들을 상대하는 일이다. 컴퓨터 프로그램을 짜는 것은 중요한 일이고 지식과 기능이 많이 드는 일이다. 하지만 그것은 좋은 프로그래머가 고객 및 자기가 크고 작게 책임을 지고 있는 수많은 동료들을 만족시키는 소프트웨어 시스템을 만들기 위해 해야 하는 다른 모든 일들에 비교해 볼 때 정말 어린아이 장난과 같다. 나는 내가 스물 한 살이었을 때 누군가가 나에게 설명해 주길 바랐던 것들을 가능한 한 간결하게 요약하려고 했다.

이것은 매우 주관적이며, 따라서 이 글은 개인적이고 다소 고집스럽게 보일 수밖에 없다. 이 글은 프로그래머가 일하면서 맞부딪치기 아주 쉬운 문제들에 한정되어 있다. 이런 문제들과 이에 대한 해결책은 사람 사는 데서 흔히 볼 수 있기 때문에 이 글이 설교처럼 보일 수도 있다. 그럼에도 불구하고 이 글이 유용하게 쓰이길 바란다.

컴퓨터 프로그래밍은 여러 강좌를 통해 배울 수 있다. The Pragmatic Programmer <Prag99>, Code Complete <CodeC93>, Rapid Development <RDev96>, Extreme Programming Explained <XP99> 등의 훌륭한 책을 통해 컴퓨터 프로그래밍에 대해 배우고, 좋은 프로그래머란 무엇인가에 대한 다양한 논점들을 알게 된다. 폴 그레이엄(Paul Graham) <PGSite>과 에릭 레이먼드(Eric Raymond) <Hacker>의 글은 이 글을 읽기 전이나 읽는 도중에 꼭 읽어 보아야 한다. 이 글은 이상의 훌륭한 글들과 달리 사회 활동의 문제를 강조하고 있으며 내가 보기에 꼭 필요하다고 생각하는 모든 기능들을 폭넓게 요약하고 있다.

이 글에서 "상사"는 나에게 프로젝트를 배정해 주는 사람을 의미한다. 사업, 회사, 부족(tribe)이라고 할 때, 사업이 돈을 버는 것, 회사가 현시대의 일터, 부족이 충성심을 공유하는 사람들이라는 뜻을 내포하는 것 외에는 모두 같은 뜻으로 사용했다.

우리 부족에 온 것을 환영한다.......이하생략.....

프로그래밍을 하는 엔지니어라면 한번쯤 꼭 읽어봐야 할 글인것 같습니다....