왜 단순하게 만들어야 하는가

‘심플 소프트웨어’, 이 책은 소프트웨어를 왜 단순하게 만들어야 하는가에 대해서 이야기합니다. 복잡할수록 유지보수에 드는 비용이 커지므로 단순성을 중심에 두어야 한다고 이야기합니다.

많은 내용이 소프트웨어 회사에서 일하는 개발자에게 적합하지만 서비스 회사에서 일하는 개발자도 알아두면 좋은 내용도 많습니다. 객관적인 자료뿐만 아니라 주관적인 주장도 담겨있으므로 독자 스스로 충분히 고민할 필요가 있습니다.

프로그래머를 위한 원칙
가능한 한 좋은 프로그래머가 되기를 진심으로 원하지 않는 사람이라면 아무리 가르치고 지적하고 세미나에 보내도 아무 의미가 없다. 그런 사람은 나아지지 않는다.
단순성을 유지하는 동시애 미래에 있을 기능 개선에 대처할 유연성까지 갖춘 소프트웨어 코드라면 ‘올바른 방법’이라고 볼 수 있다.
자신이 하는 일을 잘 이해할수록 그 일을 더 잘한다. 자신이 이해한 내용을 실전에 적용할 수 있느냐가 관건이다. 기본을 제대로 이해해야 그다음 수준도 쉽게 배운다.
소프트웨어 설계의 기본 원칙은 구현에 드는 수고보다 유지 보수에 드는 수고를 줄이는 게 더 중요하다와 유지 보수에 드는 수고는 시스템의 복잡성에 비례한다이다.

소프트웨어의 복잡성과 원인
출시하기 전에 실제 API가 어떻게 작동해야 할지 합리적인 조치를 취한다. 일단 공개했다면 제발 API를 망가뜨리지 마라. 하위 호환성 유지가 진보를 막는 지경에 이르면 그 ‘유물’은 이제 한물 갔으므로 버려야 한다.
앞으로 나올 많고 많은 버전에서 그 기능을 지원하고 싶은 생각이 없다면 추가하지 않는 게 이상적인 결론이다.

단순성과 소프트웨어 설계
미래를 고려하지 않으면 코드가 엉망으로 설계되고 너무 복잡해진다. 이해할 수 있고 유지 보수도 가능한, 단순한 시스템을 만들어야 한다. 미래 예측의 정확성은 시스템이 복잡해질수록, 예측하고자 하는 시점이 멀어질수록 낮아진다.
컴퓨터가 사용자의 입력에 대해 ‘추측’하거나 ‘안 되는 걸 되게 하려 해서는’ 안 된다.
둘은 너무 많다. 겹치는 부분이 있는 두 가지 사항을 반복해서 구현하는 대신 즉시 포괄적 솔루션을 만든다. 필요 이상의 영역까지 포괄하는 솔루션을 만들지 않는다. 즉시 행동으로 옮긴 것이 핵심이다. 통합하면 안 되는 것을 통합하지 않는 것도 중요하다.
규격화하고 각 부분을 작고 간단하게 유지함으로써 작업을 단순화한다. 변화를 작은 범위로 이루어지도록 관리하고 테스트한다.

소프트웨어 이해하기
컴퓨터 프로그램의 세 요소
- 구조 = 클래스, 그 사이의 연결. 함수나 변수의 이름이나 자료형 등
- 동작 = 메서드의 내부 코드 등
- 결과 = 생산하는 것
소프트웨어를 만들 때 보통 구조부터 만들고 동작과 관련된 부분을 작업한 다음, 결과를 표시하는 부분을 만든다. 거꾸로 하기도 한다. 하지만 구조나 결과 없이 동작을 수행하려면 혼란스러우므로 동작부터 시작하지는 않는다.
테스트의 전반적인 목표는 시스템에 관해 유효한 지식을 얻는 것이다. 이러한 결과를 낼 수 있다면 어떤 테스트 방법을 사용해도 괜찮다. 하지만 상대적으로 더 효율적인 테스트 방법은 존재한다.

나아지기
사람들은 자신이 쓰던 소프트웨어가 개떡 같은 상태로 좀처럼 나아질 기미가 없을 때 새 소프트웨어를 찾아 나선다. 새로운 버전을 출시할 때마다 나아진다면 소프트웨어 프로젝트를 성공으로 이끌 수 있다. 나아지고 싶다면 우선 가장 명백한 큰 문제를 찾아라. 그리고 아무리 큰 수고가 들어도 꼭 해결하라.
지식을 얼마나 갖추었든지 간에 어느 분야에서나 언제나 더 배울 게 있다. 그러므로 다 안다고 자신하는 건 현명치 못한 처사다. 다른 사람의 코드를 베껴 쓰면서 자신에게 잘 맞는 코드이길 염원하며 사는 한 절대 훌륭한 프로그래머가 될 수 없다. 훌륭해지고 싶다면 학습에 시간을 투자해야 한다. 지금 바로.
훌륭한 프로그램은 사용자의 의사를 정확히 수행한다.