책을 읽을때 그 내용을 오래 기억하고 체득하기 위해 어딘가에 정리하면서 보기도 하는데요, 실용주의 프로그래머는 그렇게 했던 최초의 책입니다. 대학생시절 힘들게 공부할때 봤던 책이라 그 시절 나름 추억(?)을 떠올려 주기도 합니다. 당시에는 그 내용이 그냥 뭐 그런가보다 했지만 세월이 지나 다시 보면 공감이 되고 개발자로서의 태도를 다시 잡게끔 해줍니다. 몇몇 내용은 요즘 개발방법이나 절차에 있어 당연하게 여겨지는 것들이 되었네요.
- 자신의 기술(craft)에 관심과 애정을 가져라. - 소프트웨어 개발을 잘 해보려는 생각이 없다면 왜 인생을 그 일을 하면서 보내는가?
- 자신의 일에 대해 생각하면서 일하라! - 자동 조종 장치를 끄고 직접 조종하라. 스스로의 작업을 지속적으로 비판하고 평가하라.
- 어설픈 변명을 만들지 말고 대안을 제시하라. - 변명하는 대신 대안을 제시하라. 그 일은 할 수 없다고 말하지 말고, 무엇을 할 수 있는지에 대해 설명하라
- 깨진 창문을 내버려두지 말라. - 눈에 뜨일 때마다 나쁜 설계, 잘못된 결정, 좋지 않은 코드를 고쳐라.
- 변화의 촉매가 되라. - 사람들에게 변화를 강요할 수는 없다. 대신, 미래가 어떤 모습일지 그들에게 보여주고 미래를 만드는일에 그들이 참여하도록 도우라.
- 큰 그림을 기억하라. - 주변에 무슨 일이 일어나는지 점검하는 일을 잊어버릴 정도로 세부사항에 빠지지 말라.
- 품질을 요구사항으로 만들어라. - 프로젝트의 진짜 품질 요구사항을 결정하는 자리에 사용자를 참여시켜라
- 지식 포트폴리오에 주기적으로 투자하라. - 학습을 습관으로 만들어라.
- 읽고 듣는 것을 비판적으로 분석하라. - 벤더, 매체들의 야단법석, 도그마에 흔들리지 말라. 여러분과 여러분 프로젝트의 관점에서 정보를 분석하라.
- 무엇을 말하는가와 어떻게 말하는가 모두 중요하다. - 효과적으로 전달하지 못한다면 좋은 생각이 있어봐야 소용없다.
- DRY 반복하지 말라.(Don’t Repeat Yourself) - 어떤 지식 한 조각도 하나의 시스템 안에서는 모호하지 않고, 권위 있고, 단 하나뿐인 표현을 가져야 한다.
- 재사용하기 쉽게 만들라. - 재사용하기 쉽다면, 사람들이 재사용할 것이다. 재사용을 촉진하는 환경을 만들라.
- 관련 없는 것들 간에 서로 영향이 없도록 하라. - 컴포넌트를 자족적이고, 독립적이며, 단 하나의 잘 정의된 목적만 갖도록 설계하라.
- 최종 결정이란 없다. - 돌에 새겨진 것처럼 불변하는 결정은 없다. 그렇게 생각하는 대신, 모든 결정이 해변의 백사장 위에 쓴 글자와 같다고 생각하고 변화에 대비하라.
- 목표물을 찾기 위해 예광탄을 써라. - 예광탄은 이것저것을 시도해보고 그것들이 목표와 얼마나 가까운 데 떨어지는지 보는 방법으로 목표를 정확히 맞추게 해준다.
- 프로토타입을 통해 학습하라. - 프로토타이핑은 배움의 경험이다. 프로토타이핑의 가치는 만들어낸 코드에 있지 않고, 여러분이 배운 교훈에 있다.
- 문제 도메인에 가깝게 프로그래밍하라. - 사용자의 언어를 사용해서 설계와 코딩을 하라.
- 추정을 통해 놀람을 피하라. - 시작하기 전에 추정부터 하라. 잠재적인 문제점들을 미리 찾아내게 될 것이다.
- 코드와 함께 일정도 반복하며 조정하라. - 구현하면서 얻는 경험을 이용해서 프로젝트의 시간 척도를 세밀히 조정하라
- 지식을 일반 텍스트로 저장하라. - 일반 텍스트 형식은 시일이 지났다고 못쓰게 되는 일이 없다. 일반 텍스트 형식은 여러분의 작업을 활용하고 디버깅과 테스팅을 쉽게 만드는 데 도움이 된다.
- 명령어 셸의 힘들 사용하라. - 그래픽 사용자 인터페이스로는 할 수 없는 일에 셀을 이용하라.
- 하나의 에디터를 잘 사용하라. - 에디터를 마치 손의 연장으로 자유자재로 다루어야 한다. 여러분이 사용하는 에디터는 설정을 바꿀 수 있고, 확장가능하고, 프로그램 가능해야 한다.
- 언제나 소스코드 관리 시스템을 사용하라. - 소스코드 관리는 여러분 작업을 위한 타임머신이다. 언제라도 과거로 돌아갈 수 있게 해준다.
- 비난 대신 문제를 해결하라. - 버그가 여러분 잘못인지 다른 사람 잘못인지는 별로 중요하지 않다. 그것은 여전히 여러분의 문제이며, 여전히 고쳐야 할 필요가 있다.
- 디버깅을 할 때 당황하지 마라. - 숨을 깊게 들이 쉬고, 무엇이 버그를 일으키는지 ‘생각하라!’
- ‘select’는 망가지지 않았다. - OS나 컴파일러의 버그를 발견하는 일은 정말 드물게 일어나며, 심지어 써드파티 제품이나 라이브러리일지라도 드문 일이다. 버그는 애플리케이션에 있을가능성이 가장크다.
- 가정하지 마라. 증명하라. - 진짜 데이터와 경계 조건이 있는 실제 환경에서 여러분이 내렸던 가정들을 증명하라.
- 텍스트 처리 언어를 하나 익혀라. - 여러분은 하루 가운데 많은 시간을 텍스트와 씨름하며 보낸다. 왜 여러분 대신 컴퓨터가 그 일의 일부를 하게끔 만들지 않는가?
- 코드를 작성하는 코드를 작성하라. - 코드 생성기는 생상성을 증가시키며 중복을 막는 일에도 도움이 된다.
- 완벽한 소프트웨어는 만들수 없다. - 소프트웨어는 완벽할 수 없다. 피할 수 없이 나타나는 에러로부터 여러분의 코드와 사용자들을 보호하라
- 계약에 따른 설계를 하라. - 코드가 실제로 하기로 한 것을 문서화하고 검증하기 위해 계약을 사용하라.
- 일찍 작동을 멈추게 하라. - 보통은 죽은 프로그램이 절름발이 프로그램보다 해를 훨씬 덜 끼친다.
- 단정문을 사용해서 불가능한 상황을 예방하라. - 단정은 여러분이 세운 가정을 검증해준다. 확실할 것이 없는 세상에서 여러분이 코드를 보호하려면 단정문을 사용하라.
- 예외는 예외적인 문제에 사용하라. - 예외를 잘못 쓰면 고전적 스파게티 코드의 모든 가독성과 유지보수 문제를 그대로 겪을지도 모른다. 예외는 예외적인 일들만을 위해 남겨두어라.
- 시작한 것은 끝내라. - 가능하다면, 리소스를 할당한 루틴이나 객체가 해제도 책임져야 한다.
- 모듈간의 결합도를 최소화 하라. - 디미터 법칙을 적용하고 ‘부끄럼 타는shy’코드를 작성해서 결합이 생기는 일을 피하라.(디미터 법칙 : 객체의 모든 메서드는 다음에 해당하는 메서드만을 호출해야한다.자신, 메서드로 넘어온 인자, 자신이 생성한 객체, 직접 포함하고 있는 객체)
- 통합하지 말고 설정하라. - 애플리케이션에서 기술 선택을 설정 옵션으로 구현하고, 통합하거나 만들어 넣지 말라.
- 코드에는 추상화를, 메타데이터에는 세부내용을… - 프로그램은 최대한 일반화해서 만들고, 세부사항들은 가능하면 컴파일된 코드 기반 바깥으로 빼라.
- 작업흐름 분석을 통해 동시성을 개선하라. - 사용자의 작업흐름이 허용하는 동시성을 최대한 활용하라.
- 서비스를 사용해서 설계하라. - 서비스, 곧 잘 정의되고 일관성 있는 인터페이스를 통해 의사소통하는 독립적이고 동시성 있는 객체들의 관점에서 설계하라.
- 언제나 동시성을 고려해 설계하라. - 동시성이 가능하도록 설계하면, 더 적은 가정만 내리고서도 더 깔끔한 설계를 할 수 있다.
- 모델에서 뷰를 분리하라. - 애플리케이션을 모델과 뷰의 관점으로 설게해서 적은 비용만 들이고도 유연함을 얻어내다.
- 칠판을 사용해 작업흐름을 조율하라. - 참여하는 요소들의 독립성과 고립성을 유지하면서도 개별적인 사실과 에이전트를 잘 조율하려면 칠판을 사용하라.
- 우연에 맡기는 프로그래밍을 하지 말라. - 정말 믿을 만한 것만 믿어야 한다. 우발적인 복잡함을 조심하고, 우연한 행운을 목적의식을 가지고 만든 계획과 착각하지 말라.
- 여러분의 알고리즘의 차수를 추정하라. - 코드를 작성하기 전에, 실행 시간이 대략 얼마나 걸릴지 감을 잡아 놓아라.
- 여러분의 추정을 테스트하라. - 알고리즘의 수학적 분석이 모든 것을 다 알려주지는 않는다. 실제 대상 환경에서 코드의 수행 시간을 측정해보라.
- 일찍 리팩터링하고, 자주 리팩터링하라. - 정원의 잡초를 뽑고 식물 배치를 조정하는것과 똑같이, 코드도 필요할 때면 언제라도 다시 작성하고 다시 작업하고 다시 아키텍처를 만들라. 문제의 근원을 해결하라.
- 테스트를 염두에 두고 설계하라. - 코드에 한 줄이라도 쓰기 전에 테스팅에 대해 생각하기 시작해야 한다.
- 소프트웨어를 테스트하라. 그렇지 않으면 사용자가 테스트하게 될 것이다. - 가차 없이 테스트하라. 사용자가 여러분을 위해 버그를 찾게 만들지 말라.
- 자신이 이해하지 못하는, 마법사가 만들어준 코드는 사용하지 말라. - 마법사는 엄청난 양의 코드를 만들 수 있다. 그것들을 프로젝트에 통햅해 넣기 전에 그 코드 내용을 전부 이해하는지 확실히 해놓도록 하라.
- 요구사항을 수집하지 말고 채굴하라. - 요구사항이 지면에 놓여져 있는 경우는 퍽 드물다. 보통은 가정과 오해, 정치의 지층들 속 깊이 묻혀있다.
- 사용자처럼 생각하기 위해 사용자와 함께 일하라. - 시스템이 정말로 어떻게 사용될지 통찰력을 얻을 수 있는 가장 좋은 방법이다.
- 구체적인 것보다 추상적인 것이 더 오래간다. - 구현 말고 추상에 투자하라. 추상은 서로 다른 구현이나 새로운 기술의 출현 때문에 빗발치듯 생기는 변화를 견뎌내고 살아남을수 있다.
- 프로젝트 용어사전을 사용하라. - 프로젝트에서 쓰이는 특정 용어와 어휘들의 유일한 출처를 만들고 유지하라.
- 생각의 틀을 벗어나지 말고, 틀을 찾아라. - 해결이 불가능해 보이는 문제와 마주쳤을때 진짜 제약 조건을 찾아라. 스스로에게 이렇게 물어보라. ‘정말로 반드시 이런방식으로 해야하는 일인가? 꼭 해야만 하는 일이긴 한건가?
- 준비가 되었을때 시작하라. - 여러분은 살아오면서 경험을 쌓아왔다. 자꾸 거슬리는 의혹을 무시하지 말라.
- 어떤 일들은 설명하기보다 실제로 하는 것이 더 쉽다. - 명세의 나선의 빠지지 말라. 언젠가는 코딩을 시작해야 한다.
- 형식적 방법의 노예가 되지 마라. - 여러분의 개발 실천방법과 개발 능력의 맥락 안에 넣어보지 않고, 맹목적으로 어떤 기법을 채택하지 말라.
- 비싼 도구가 더 좋은 설계를 낳지는 않는다. - 벤더들의 과장, 어떤 분야의 도그마 그리고 가격표의 휘광에 넘어가지 말라. 도구 자체의 장점만 갖고 판단하라.
- 팀을 기능 중심으로 조직하라. - 설계자와 코더를, 테스트 담당자와 데이터 모델 담당자를 분리시키지 말라. 코드를 만드는 방식에 맞춰 팀을 만들어라.
- 수작업 절차를 사용하지 말라. - 쉘 스크립트나 배치 파일은 똑같은 명령을, 똑같은 순서로, 어느 때라도 반복해서 실행 해준다.
- 일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라. - 매번 빌드할 때마다 실행되는 테스트가 책꽂이의 테스트 계획보다 훨씬 효과적이다.
- 모든 테스트가 통과하기 전엔 코딩이 다 된게 아니다. - 뭐 더 할 말 있나?
- 파괴자를 써서 테스트를 테스트하라. - 코드의 별도 복사본을 만들고, 그 복사본에 고의로 버그를 넣은 다음 테스트가 잡아내는지 검증하라.
- 코드 커버리지보다 상태 커버리지를 테스트하라. - 중요한 프로그램 상태들을 파악해서 테스트하라. 단지 많은 코드 줄 수를 테스트 범위안에 넣는 것만으로는 충분하지 않다.
- 버그는 한 번만 잡아라. - 인간 테스터가 버그를 찾아내면, 그 때가 인간 테스터가 그 버그를 찾는 마지막 순간이 되어야 한다. 그 순간 이후부터는 자동화된 테스트가 그 버그를 담당하도록 만들라.
- 한국어도 하나의 프로그래밍 언어인 것처럼 다루라. - 코드를 작성하는 것처럼 문서도 작성하라. DRY 원칙을 존중하고 메타데이터를 사용하고, MVC 모델을 쓰고, 자동 생성을 이용하고 등등.
- 문서가 애초부터 전체의 일부가 되게하고, 나중에 집어넣으려고 하지 말라. - 코드와 떨어져서 만든 문서가 정확하거나 최신정보를 반영하기는 더 힘들다.
- 사용자의 기대를 부드럽게 넘어서라. - 사용자들이 무엇을 기대하는지 아해한 다음, 그것보다 약간 더 좋은 것을 제공하라.
- 자신의 작품에 서명하라. - 옛날 장인들은 자신의 작업 결과물에 서명하는 일을 자랑스럽게 여겼다. 여러분도 마찬가지여야 한다.