[실용주의 프로그래머] 개인적인 리뷰

1장. 실용주의 철학

• 깨진 창문(나쁜 설계, 잘못된 결정, 형편없는코드)을 그대로 내버려 두지 마라
  • 적절히 코드를 고칠 시간이 주어지지 않는다면 TODO 메세지를 표시하거나 Dummy 데이터로 대치해 놓아라.
• 지식 포트폴리오에 주기적으로 투자하라.

2장. 실용주의 접근법

• 유연한 아키텍처를 통해 유지보수와 유연성, 테스트를 용이하게 한다.
• 예광탄처럼 빨리 눈에 보이게, 반복적으로 도달하는 목표물을 찾을수 있는 코드를 작성하는 것이 좋다.
  • 예광탄 코드는 나중에 버리려고 만드는 것이 아닌 계속 사용할 코드이다.

3장. 기본적인 도구

• 도구는 재능을 증폭한다.
  • 도구가 더 훌륭하고 그것을 어떻게 사용하는지 잘 알수록 더욱 생산적일 수 있다.
• 임시 변통한 작업을 수행할 때 GUI 툴이 지원하지 않을 수도 있다.
  • 강력한 쉘 명령어를 익힐 시간을 투자해보는 것도 좋다.
• 하나의 에디터를 마스터해보아라.

4장. 실용주의 편집증

• 죽은 프로그램은 거짓말을 하지 않는다.
  • 가능한 한 빨리 문제를 발견하면 프로그램을 멈추도록 하는 것이 좋다.
• 단정적 프로그래밍
  • 이런일은 절대 일어나리가 없어 하는 마인드로 생각하지 말라.
  • 정말 절대 일어나지 않을 상황이라면 그것을 확인하는 코드를 추가하라.
• 예외는 예외적인 문제에 사용하라.
  • 예외를 정상적인 처리과정의 일부로 사용하게 된다면 고전적 스파게티 소스의 가독성, 관리성의 문제와 캡슐화를 무너트리게 된다.
• 리소스를 사용한다면 끝맺음(자원 해제)을 지어라
  • try-catch 예외문을 사용하는 경우라면 finally 에서 자원 해제 등을 처리하는 것이 좋다.

5장. 구부러지거나 부러지거나

• 코드를 세포(모듈)로 구성하고 이들간의 상호작용을 제한하라.
  • 한 모듈이 변경되거나 교체된다 하더라도 다른 모듈들은 변경없이 수행될 수 있을 것이다.
• 활동 다이어그램을 사용해라.
  • 동시에 수행할 수 있지만 아직 그렇지 않은 활동들을 찾아내어 병렬성을 극대화할 수도 있다.
  • 작업 흐름분석을 통해 동시성을 개선해라.
• 인터페이스 - 동시성을 고려해서 설계해라
  • 문자열 자르기 - [C언어] strtok vs [Java] StringTokenizer
• 칠판을 사용해 작업 흐름을 조율하라
  • 참여하는 요소의 독립성, 고립성을 유지하는 동시에 이질적인 사실과 행위자들을 잘 조정하는데 칠판이 사용될 수 있다.
    • 작업흐름이 분산된 요소들을 방지할 수 있다.
  • 칠판시스템의 예
    • 음성인식, 지식기반 추론 시스템, JavaSpaces 등등

6장. 코딩하는 동안 해야 할 일들

• 우연에 맡기는 프로그래밍을 하지 말라.

  • 다른 사람의 루틴을 호출할 때도 문서화 된 동작에 의존하라.

• 의도적으로 프로그래밍을 한다.

• 복잡한 알고리즘은 빅오 표기법으로 추정해보는것이 좋다 (속도, 성능)

• 성급한 최적화를 조심하라

  • 어떤 알고리즘을 개선 하느라 시간을 투자하기 전에 그 알고리즘이 정말로 병목인지 먼저 확실하게 하라.
    • 병목 : 전체 시스템의 성능이나 용량이 하나의 구성 요소로 인해 제한을 받는 현상

• 테스트를 엄두하여 코드를 설계하라

7장. 프로젝트 전에

• 요구사항을 수집하지 말고 채굴해라
• 요구사항의 정책은 수시로 바뀌기 때문에 문서화하고 양자를 하이퍼링크 하라
• 여러분의 청중과 요구사항을 가장 잘 소통할 수있는 방법이라면 무엇이든 사용하라
• 프로젝트 용어사전을 만들고 유지하라
• 생각의 틀에 벗어나지않고 틀을 찾아라
• 형식적인 방법의 노예가 되지 말아라

8장. 실용주의 프로젝트

• 실용주의 팀을 구성하기 위해선
  • 깨진 창문(아무도 고치려고 하지 않는 사소한 결점)을 없애라
    • 품질은 팀의 이슈, 상품의 품질에 책임을 져야 한다.
  • 팀을 기능 중심으로 조직하라(직교성)
    • 사람들을 작은 팀으로 나누고 각 팀은 최종 시스템의 특정한 기능 측면에 책임 지도록 한다.
  • 팀을 하나로 의사소통하게 도와주는 간단한 마케팅 비결
    • 프로젝트를 시작할 때 이름을 지어 팀의 정체성 확립의 기반을 얻을 것
• 수작업 절차를 사용하지 말라
  • 반복되는 작업을 위한 스크립트 / 빌드 자동화
• 일찍 테스트하고 자주 테스트하라. 자동으로 테스트하라
  • 모든 테스트가 통과하기 전에 코딩이 다 완성된 것이 아니다
  • 완전한 목록이 아니지만 이 목록을 통해 테스트의 훌륭한 출발점이 될 수 있다.
    • 단위 테스트
    • 통합 테스트
    • 유효성 평가와 검증
    • 자원고갈, 에러 그리고 복구
    • 성능 테스트
    • 사용 편의성 테스트
  • 테스트를 어떻게 해야 할까
    • 희귀 테스트
    • 테스트 데이터
    • GUI 시스템 구동
    • 테스트를 테스트하기
    • 철저히 테스트하기
• 문서가 애초부터 전체의 일부가 되게 하고 나중에 집어넣으려고 하지 말라
• 변수명을 유의미하게 설정하고 약어를 사용하지 마라. 또한 의미없는 이름보다 더 안좋은 것은 오해를 불러올 수 있는 이름이다.