Contents

1 Part 1 프로그래머를 위한 원칙
2 Part 2 소프트웨어의 복잡성과 원인
3 Part 3 단순성과 소프트웨어 설계
4 Part 4 디버깅
5 Part 5 엔지니어링 팀에서 일하기
6 Part 6 소프트웨어 이해하기
7 Part 7 나아지기

1 Part 1 프로그래머를 위한 원칙 #

Chapter 3 능력자 프로그래머의 한 가지 비밀

자신이 하는 일을 잘 이해할수록 그 일을 더 잘한다.

뛰어난 프로그래머가 되고 싶다면 자신이 하는 일을 제대로 이해하라.


Chapter 4 두 문장으로 요약한 소프트웨어 설계
  1. 구현에 드는 수고보다 유지 보수에 드는 수고를 줄이는 게 더 중요하다.
  2. 유지 보수에 드는 수고는 시스템의 복잡성에 비례한다.


2 Part 2 소프트웨어의 복잡성과 원인 #


Chapter 5 복잡성의 단서

  1. 약간의 꼼수를 써야만 코드가 잘 작동한다.
  2. 다른 개발자들이 코드 작동 방식을 계속 물어본다.
  3. 다른 개발자들이 코드를 잘못 사용해 버그가 계속 발생한다.
  4. 경력이 많은 개발자조차 한 줄의 코드를 바로 이해하지 못한다.
  5. 그 코드를 수정할 생각을 하면 두렵다.
  6. 관리자가 클래스 하나 혹은 파일 하나를 다루는 일에 여러 개발자를 붙이려 한다.
  7. 기능 추가 방법을 알아내기 어렵다.
  8. 그 코드에 어떤 사항을 구현하는 방법을 두고 자주 논쟁이 벌어진다.
  9. 수정 사항을 체크인한 후나 코드 리뷰를 할 때 겨우 알아차릴 정도의 무의미한 수정이 자주 이루어진다.


Chapter 6 복잡성을 키우는 방법: API 분리

Chapter 7 하위 호환성이 가치를 잃는 시점은 언제인가?

하위 호환성 유지가 진보를 막는 지경에 이르면 그 '유물'은 이제 한물 갔으므로 버려야 한다는 걸 기억하자.

이 원칙을 따르지 않고 반대로 가면 진보를 포기하고 무제한의 하위 호환성을 보장할 수 있다. 그러면 제품은 완전히 사망할 것이다.


Chapter 8 복잡성은 감옥이다

복잡성은 감옥이고 단순성은 자유이다.



3 Part 3 단순성과 소프트웨어 설계 #


Chapter 9 설계는 프로젝트 초반에 하라

업격한 설계 없이 시작한 프로젝트가 계속 성장하면 결국 개발자의 능력을 벗어날 정도로 복잡해진다.


Chapter 10 미래 예측의 정확성

미래 예측의 정확성은 시스템이 복잡해질수록, 예측하고자 하느 시점이 멀어질수록 낮아진다.


Chapter 11 단순성과 엄격성

엄격한 애플리케이션일수록 더 단순하게 작성할 수 있다.

프로그래머를 위한 프레임워크나 언어를 만드는 중이라면 '덜 엄격한' 인터페이스는 최대한 간소하게 만드는 게 좋다. 그러면 사용성을 위해 단순성을 희생하지 않아도 되므로 사용성과 단순성, 두 마리 토끼를 모두 잡을 수 있다.

컴퓨터 세계는 애초에 엄격했어야 하는 것으로 가득 차 있다. 하지만 그렇지 못했기 때문에 말도 안 되게 복잡해졌다.


Chapter 12 둘은 너무 많다

공통된 부분이 눈에 띄면 코드를 잘라 붙이고 싶겠지만, 그렇게 하지 말고 공통 부분의 특정 목적에 부합하는 포괄적 솔루션을 설계한다.

포괄적 솔루션을 만들되 필요 이상의 영역까지 포괄하는 솔루현을 만들지 않는다.


Chapter 13 분별 있는 소프트웨어 설계


4 Part 4 디버깅 #


Chapter 15 버그의 원인
  1. 코드가 단순할수록 버그가 줄어들 것이다.
  2. 프로그램의 모든 것이 단순해지도록 늘 노력하라.

Chapter 16 재발을 방지하라

명심하라. 소프트웨어에서 가장 신경 써야 할 부분은 미래다.

Chapter 17 디버깅의 기본 철학

디버깅은 본인이 아직 답을 모른다고 자각하는 데에서 시작해야 한다.

답을 추측하는 것이 올바른 디버깅 방법이라고 착각하는 사람들도 생긴다.

디버깅 프로세스
  1. 정상 시스템의 작동 방식 기억하기
  2. 더 많은 데이터를 모을 수 있는 방법 알아내기

디버깅의 가장 중요한 원칙: 디버깅을 완료하려면 문제의 원인을 이해할 때까지 데이터를 수집해야 한다.

가끔은 깨달음이 올때 까지 적절한 데이터를 들여다보는 것만으로도 버그를 해결할 방법을 알아내는 마법 같은 경험을 할 수도 있다.



5 Part 5 엔지니어링 팀에서 일하기 #


Chapter 18 엔지니어링 생산성을 효과적으로 개선하기

자기 눈에만 보이는 뭄ㄴ제 말고 사람들이 인지하고 있는 문제를 해결하라.


Chapter 19 개발자 생산성 측정하기

개발자의 생선성을 측정하려면 그 사람이 생산한 제품을 측정하라.


Chapter 20 소프트웨어 회사에서 코드 복잡성을 다루는 법

관리자의 단순화 요구가 변화를 불러올수 없는 이유:
  1. 관리자의 지시가 구체적이지 않다.
  2. 코드의 구체적인 부분까지 지시를 내릴정도의 지식이 관리자에게 없을 수 있다.
  3. 문제해결과정에서 깊어지는 이해도가 있다. 하지만 관리자는 문제를 직접 해결하지 않는다.


Chapter 21 리팩토링할 때는 기능에 주목하라

복잡한 코드베이스를 정리하는 핵심 원칙은 항상 기능을 위해 리팩토링하라는 것이다.

일단 시간이 지날수록 시스템이 더 나빠지지 않고 더 나아지는 상태로 만드는 걸 첫 번째 목표로 삼아라.

세상에 완벽한 설계는 없다. 더 나은 설계가 있을 뿐이다.

리팩토링 시 해당 코드의 제작 목적에 부합하지 않는 부분을 목적에 부합하게 바꿔라.


Chapter 22 친절과 코드



6 Part 6 소프트웨어 이해하기 #


Chapter 27 지식으로서의 소프트웨어

소프트웨어는 지식으로 만든 단단한 실체다. 이는 지식의 모든 규칙과 법칙을 따른다. 구체적인 형태를 지니고 있다는 사실만 제외하면 거의 모든 상황에서 지식과 똑같은 양상을 보인다.


Chapter 30 단순성과 보안

보안을 지키는 최고의 방법은 단순성을 유지하는 것이다.


7 Part 7 나아지기 #


Chapter 36 프로그래머가 개떡 같은 이유

내가 대화하고 함께 일하고 들어본 모든 프로그래머의 10퍼센트만이 자신이 실제로 무슨 일을 하는지 제대로 이해하고 있었다.


Chapter 42 성공은 혁신이 아니라 실행에서 온다

Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2020-07-05 12:45:49
Processing time 0.2192 sec