심플 소프트웨어 : 프로그래머를 위한 원칙

1부 프로그래머를 위한 원칙

• 뛰어난 프로그래머가 되고자 하는 마음이 있어야만 뛰어난 프로그래머가 될 수 있다. 이런 마음이 없는 사람은 아무리 훈련을 받아도 뛰어난 프로그래머가 될 수 없다.
• 올바른 방법이 떠오르지 않을 때 잠시 쉬고오는게 좋다. 잠시 그 문제에서 떨어져 있거나 다음 날 다시 그 문제로 돌아왔을 때 해결책이 떠오르기도 한다.
• 올바른 방법을 두고 논쟁이 벌어지면 종종 논의가 산으로 가기도 한다. 이럴 때는 작업중인 분야의 기본 법칙을 이해하고 있는 시니어 엔지니어를 선별하고 기존 논의를 검토하게 하고 표준적이고 타당한 엔지니어링 절차에 따라 올바른 방법을 정하게 하는게 좋다.
• 능력자 프로그래머는 평범한 프로그래머보다 자신이 하는 일을 훨씬 더 잘 이해하고 있다. 뛰어난 프로그래머가 되고 싶다면 자신이 하는 일을 제대로 이해하라.
• 어느 분야든 기본을 제대로 이해해야 그다음 수준도 쉽게 배운다. 그렇게 한 단계씩 올라가야 한다. 최고로 복잡한 수준에 도달한 후 다시 기초단계를 살펴보면 맨 밑바닥에는 여전히 알아야 할 게 엄청 많다는걸 깨닫는다.
• 소프트웨어 설계의 기본 원칙
  • 구현에 드는 수고보다 유지보수에 드는 수고를 줄이는게 더 중요하다.
  • 유지 보수에 드는 수고는 시스템의 복잡성에 비례한다.
    
    

2부 소프트웨어 복잡성과 원인

[복잡성을 키우는 방법 : API 분리]

• API는 ‘언제든 우리가 알려준 대로 우리 프로그램와 안전하고 정확하게 인터랙션 할 수 있다’라는 약속이다.
• 개발자 입장에서는 오래된 API를 계속 유지보수 하는게 괴로울 수 있다. 이 문제를 피하는 가장 좋은 방법은 나쁜 API를 공개하지 않는 것이다.
• 예전 API를 그대로 유지하는 대신 최신 API에 접근할 다른 방법을 제공하는 것도 사용자 입장에서는 괜찮다.
• 출시 전에 실제 API가 어떻게 작동해야 할지 합리적인 조치를 취한다는게 핵심이다. 그리고 일단 공개했다면 API를 망가뜨리지 마라.

[복잡성은 감옥이다]

• 사람들은 가끔 자신이 쓴 코드가 너무 단순하다고 느낄 때 이런 걱정을 한다
  • 자신이 얼마나 똑똑하고 가치있는 있물인지 관리자에게 충분히 보여주지 못할 것 같다.
  • 그 프로젝트가 너무 단순해져서 누구나 자신의 일자리를 빼앗을 수 있을 것 같다.
• 하지만 너무 복잡한 코드를 만들어서 아무도 이해할 수 없다면 다른 프로젝트로 자리를 옮기고 싶어도 유지보수가 불가능 하기 때문에 옮길 수 없을 것이다.
• 복잡성은 감옥이고 단순성은 자유다.
  
  

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

• 설계는 반드시 작업 초반에 해야한다. 그 프로젝트를 어떻게 단순하게 만들지 초반부터 고민해야 한다.
• 아주 작은 기능은 추가해도 나중에 리팩토링하기가 어렵지 않다. 아키텍처가 감당할 수 없는 거대한 기능을 넣었다가 나중에 없애는 건 끔찍하게 어려운 일이다. 크기가 중요하다.
• 시스템이 복잡해질 수록 미래의 아주 작은 부분조차 정확하게 예측할 수 없다. 시스템이 단순해질수록 먼 미래까지 정확하게 예측할 수 있다. 그래서 시스템을 단순하게 유지하는게 최선이다. 목표를 유연하게 혹은 포괄적으로 처럼 추상적으로 잡지말고 ‘쉽게 이해하고 수정할 수 있게’ 처럼 구체적으로 잡아야한다.
• 엄격한 앱일 수록 더 단순하게 작성할 수 있다. 하지만 엄격한 프로그램은 대체로 실용성이 떨어진다.
• 원칙적으로는 개발자가 코드 일부를 수정한 후에 코드의 다른 부분까지 그와 비슷하거나 똑같은 방식으로 작동하도록 수정할 필요가 없어야 한다.
• 하나로 통합해야하는 구현체가 많을 때는 한 번에 통합하는 구현체를 두 개로 제한하는 방식으로 점진적 리팩토링을 할 수 있다.
  
  

4부 디버깅

• 버그의 정의
  • 프로그램이 프로그래머의 의도에 따라 움직이지 않는다.
  • 프로그래머의 의도가 사용자의 평범하고 합리적인 기대를 충족시키지 않는다.
• 프로그래머가 의도한 방식에 따라 의도한 동작을 프로그램이 정확히 수행하는데도 사용자의 기대에 못미친다면 새로운 기능이 필요하다. 이것이 ‘기능’과 ‘버그’의 차이다.
• 버그는 보통 복잡성을 줄이지 못할 때 발생한다. 또 그보다는 드물지만 간단한 대상을 잘못 이해했을 때도 발생한다.
• 복잡성과 이해도는 매우 밀접하게 연관되어 있다. 미래에 내가 작성한 코드를 접할 프로그래머가 코드를 이해할 수 있을지, 혹은 쉽게 이해할 수 있을지는 우리도 일부 책임져야 할 문제이다.
• 프로그래머라면 프로그래밍과 해당 언어에 대한 기본적인 이해를 갖춘 상태에서 미래에 자신의 코드를 볼 다른 프로그래머가 쉽게 알아볼 수 있는 코드를 쓰겠다는 책임감을 지녀야 한다.
  1. 코드가 단순할수록 버그가 줄어들 것이다.
  2. 프로그램의 모든 것이 단순해지도록 늘 노력하라.
• 소프트웨어 회사의 코드베이스가 관리할 수 없는 지경에 이르는 이유는 문제가 제대로 해결될 때까지 손보지 않아서다. 그래서 소프트웨어 설계를 잘 이해해야하고, 충분한 인력을 동원해서 문제가 다시는 재발하지 않을때까지 제대로 처리해야한다.
• 디버깅의 기본 철학
  • 디버깅은 본인이 아직 답을 모른다고 자각하는 데에서 시작해야 한다.
  • 디버깅을 완료하려면 문제의 원인을 이해할 때까지 데이터를 수집해야 한다.
• 디버깅은 크게 다음 4가지로 볼 수 있다.
  • 정상 시스템이 어떻게 작동하는지 알아낸다.
  • 문제의 원인을 아직 모른다는 사실을 인정한다.
  • 문제를 일은키는 원인이 무엇인지 알아낼 때까지 데이터를 살펴본다.
  • 증상이 아닌 원인을 고친다.