"심플 소프트웨어" 도서 리뷰

 

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

가능한 한 좋은 프로그래머가 되기를 진심으로 원하지 않는 사람이라면 아무리 가르치고 지적하고 세미나에 보내더라도 의미가 없다. 그런 사람은 나아지지 않는다.
핵심은, 더 나아지려면 반드시 더 나아지고 싶다는 의욕이 있어야 한다는 것이다.

 

엔지니어의 자세

분야를 막론하고 엔지니어라면 다음과 같은 생각을 해야 한다.

 

나는 이 문제를 올바른 방법으로 해결할 수 있다.

 

어떤 문제든 그 문제를 해결할 올바른 방법이 항상 존재하고, 그 방법을 알아낼 수도 구현할 수도 있다.

• 올바른 방법이란, 유지보수에 유별나게 공을 들이지 않더라도 발생할 수 있는 모든 상황의 조건에 대응하고, 합리적 수준의 트래픽 양을 감당할 수 있는 일종의 다리를 짓는 일

짧은 기간이었지만 초기의 프러덕트를 만들어가는 과정에서 이런 저런 장애 상황이 발생했었다. 제한된 리소스 속에서 장애 상황에 대한 완벽한 대처보다는, 위의 내용 처럼 차선책으로 적용하고 빠르게 해결할 수 있는 역량도 엔지니어에게 굉장히 중요할 수 있겠다는 경험을 했었다.

 

올바른 방법을 모른다

• 올바른 방법을 아직 모른다는 핑계로 올바르지 않은 방법과 타협하지 않도록 노력한다.

 

올바른 방법에 관한 합의가 이루어지지 않는다

• 작업 중인 분야의 기본 법칙을 이해하고 있고 신뢰할 수 있는 시니어 엔지니어를 한 명 선발하라.

 

지금 당장 올바른 방법이 무엇인지 따지기에는 귀찮고, 지치고, 배고프고 등 여유가 없다

• 잠시 쉬었다가 나중에 다시 하라.
• 좀 자거나, 먹거나, 걷거나 등 여유를 확보하여 잠시 쉬는 게 좋다.

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

• 소프트웨어 개발자의 성패를 결정하는 단 한 가지 사실은, 자신이 하는 일을 잘 이해할수록 그 일을 더 잘한다는 점이다.
• '능력자' 프로그래머는 평범한 프로그래머보다 자신이 하는 일을 훨씬 잘 이해하고 있고, 그게 핵심이다.
• 뛰어난 프로그래머가 되고 싶다면 자신이 하는 일을 제대로 이해하라.
• 어느 분야든 기본을 제대로 이해해야 그 다음 수준도 쉽게 배울 수 있다.

이전에 본 시니어 개발자분의 경우에도 레거시하고 복잡한 도메인애 대해 단기간에 높은 이해도를 기반으로 일을 굉장히 잘하셨었는데, 결국 그러하기 위해서는 담당하고 있는 서비스에 더 많은 관심을 가지고, 이것저것 만져보며 자신의 일을 잘 이해하는 것이 굉장히 중요하다는 것을 경험했었다.

두 문장으로 요약한 소프트웨어 설계

1. 구현에 드는 수고보다 유지 보수에 드는 수고를 줄이는 게 더 중요하다.
2. 유지 보수에 드는 수고는 시스템 복잡성에 비례한다.

 

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

복잡성의 단서

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

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

 

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

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

• 설계는 반드시 작업 초반에 해야 한다. 그 프로젝트를 어떻게 단순하게 만들지 프로젝트 초반부터 고민하자.
• 저자는 설계가 간단히 지원할 수 없는 기능은 절대 추가하지 않는다는 방침을 준수한다.
• 미래를 고려하지 않으면 코드가 엉망으로 설계되고 너무 복잡해진다.

미래 예측의 정확성

• 시스템을 최대한 단순하게 유지하는 것이 최선이다.
• 목표를 ‘유연하게' 혹은 ‘포괄적으로'처럼 추상적으로 잡지 말고 ‘쉽게 이해하고 수정할 수 있게' 처럼 구체적으로 잡아야 한다.
• 합리적인 선에서 최대한 단순성을 유지하며 자신, 사용자, 시스템에게 미래에 도움이 될 결정을 하자.

개발을 하며 흔히 트레이드 오프, 은총알은 없다(No Silver Bullet) 라고도 불리는 문제로서 미래의 가능성에 대해 어느정도 예측을 해야할지는 정답이 없는 부분이고, 어려운 선택인 것 같다. 결국 많은 경험들을 통한 체득이 어느정도 중요한 부분이라고 생각한다.

 

 

4부 | 디버깅

버그의 원인

• 버그는 보통 복잡성을 줄이지 못할 때 발생한다. 또한 간단한 대상을 잘못 이해했을 때도 발생한다.
• 미래에 여러분이 작성한 코드를 접할 프로그래머가 코드를 이해할 수 있을지, 혹은 쉽게 이해할 수 있을지는 여러분도 일부 책임져야 할 문제임을 기억하라.
• 코드가 단순할수록 버그가 줄어들 것이다.
• 프로그램의 모든 것이 단순해지도록 늘 노력하라.

재발을 방지하라

• 문제가 제대로 해결되었는지에 대한 판단은 "아무도 그 문제에 다시는 주의를 기울일 필요가 없을 정도가 되어야 한다"는 것이다.

디버깅의 기본 철학

디버깅을 위해 무엇을 해야할까? 문제를 처음 접했을 때 머릿속에 떠오르는 생각은 대체로 시간 낭비이고, 해야 할 일은 다음과 같다.

• 정상 시스템의 작동 방식 기억하기
• 더 많은 데이터를 모을 수 있는 방법 알아내기

위를 통해 디버깅의 가장 중요한 원칙을 알 수 있다.

• 디버깅을 완료하려면 문제의 원인을 이해할 때까지 데이터를 수집해야 한다.
• 데이터: 로그, 데이터베이스, 동일한 상황 재현 조건 등
• 로그 모니터링, 에러 메시지 등을 비롯한 시스템의 여러 출력 결과물을 살펴본다.
• 만약 위와 같은 장치가 없다면, 시스템을 완전히 디버깅하기 전에 이런 정보를 제공해주는 새로운 시스템 버전을 배포하는게 좋다.

디버깅이 필요한 상황인데 위와 같이 로그, 에러 메시지 등이 없는 경우는 생각보다 빈번하게 발생한다. 책의 내용처럼 보통 디버깅을 하기 전에 필요한 정보를 알아내기 위해 로그를 추가하는 방식을 많이 적용했던 것 같다.

버그 하나 수정하자고 너무 많은 일을 하는 것 같겠지만, 실제로 시스템 이곳저곳을 마구잡이로 수색하거나 아무 정보 없이 어떤 일을 추측하는 것보다는 충분한 정보를 얻을 수 있는 새 버전을 출시하는 게 더 빠를때가 많다고 한다.

또한 디버깅을 하다보면 예상했던 방식과 다르게 동작하는 부분이 존재할 확률이 높기 때문에, 기존의 지식들에 대해 비판적으로 바라볼 필요가 있겠다.

디버깅은 크게 다음 4단계로 볼 수 있다.

• 정상 시스템이 어떻게 작동하는지 알아낸다.
• 문제의 원인을 아직 모른다는 사실을 인정한다.
• 문제를 일으키는 원인이 무엇인지 알아낼 때까지 데이터를 살펴본다.
• 증상이 아닌 원인을 고친다.

 

5부 | 엔지니어링 팀에서 일하기

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

• 작은것부터 변화와 개선을 이루고 신뢰를 얻어라.
• 자신이 도움을 줄 수 있는 일을 찾아라.
• 전체를 한 번에 바꾸는 것은 불가능하다.
• 자기 눈에만 보이는 문제 말고, 사람들이 인지하고 있는 문제를 해결하라.

자기 눈에 보이는 문제가 사람들이 인지하고 있는 문제와 동일하다면 굉장히 좋은 상황이겠지만 그렇지 않은 상황도 많을 것이다. 동료들과 협업하는 상황속에서 사람들이 공통적으로 인지하고 있는 문제를 파악하고, 개선하여, 신뢰를 쌓아보자.

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

복잡한 코드 베이스를 단순하게 만들고 싶을 때 할 수 있는 6단계 과정

1단계: 문제 목록

• 각 팀원에게 코드에서 가장 답답하다고 느끼는 부분을 목록으로 정리하게 한다.
• 이 단계에서 찾는 것은 원인이 아닌 증상이다.

2단계: 회의

• 목록을 확인하고 증상과 연관있는 정보들(디렉터리, 파일, 클래스, 메서드 등)을 파악한다.
• 문제를 정확하게 묘사하는 것이 중요하다.

3단계: 버그 리포트

• 회의에서 수집한 정보들을 바탕으로 문제를 묘사하는 버그 리포트를 작성한다.

4단계: 우선순위 선정

• 최우선으로 처리해야 하는 문제는 개발자를 가장 많이 괴롭히는 것이다.

5단계: 과제

• 각 작업자에게 도출된 문제/버그를 할당한다.

6단계: 계획

• 모든 버그를 정리한 후에는 그 문제를 언제 수정할지 정해야 한다.

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

• 리팩토링을 위한 리팩토링을 하는 것은 시간 낭비 (ex. 현재 작업 중인 코드와 아무 상관없는 코드에 대한 리팩토링)
• 불편하거나 혼란스럽다는 느낌에 빠져 있을 게 아니라 문제를 단계적으로 공격할 체계를 구축하고, 상황을 개선하기 위해 노력해야 한다.

복잡한 코드 베이스를 정리하는 핵심 원칙은, 항상 기능을 위해 리팩토링하라는 것이다.
일단 시간이 지날수록 시스템이 더 나빠지지 않고 더 나아지는 상태로 만드는 걸 첫 번째 목표로 삼아라.

 

회사 직원 이름 목록을 생성하는 코드에서 입사일 순서로 정렬하는 기능을 새롭게 추가해야 한다면?

• 코드를 읽어도 변수명 파악이 불가능하다? -> 변수 이름을 수정하는 작업부터 해야한다.
• 그래도 코드가 이해되지 않는다면 함수를 여러 개로 나눠 분리해야 한다.

 

6부 | 소프트웨어 이해하기

테스트 철학

• 얻고자 하는 지식이 무엇인지 정확히 알아야 효과적이고 유용한 테스트를 만들 수 있다.
• 테스트를 설계할 때는 테스트 대상과 테스트에 속하지 않는 부분을 정확히 구분해야 한다.
• 전체 테스트를 조합했을 때 원하는 지식을 빠짐없이 얻을 수 있다.

E2E 테스트

• 웹 서버, 데이터베이스, 웹 브라우저를 작동시켜 계정 생성 웹 페이지를 불러와서 작성하고, 내부적인 동작이야 어찌됐든 결과 페이지에서 계정을 성공적으로 생성했다는 것을 보여준다고 단언
• E2E 테스트는 시스템 로직을 관통하는 하나의 ‘경로'를 완료하는 방식으로 진행하는 테스트
• 시스템으로 들어간 입력과 거기서 생산되는 결과의 양극단만 확인한다.
• 테스트가 부족한 초기에 임시방편으로, 전체 시스템을 조립한 후에 제대로 작동하는지 확인하는 용도로 쓰면좋다.
• E2E 테스트로만 확인할 수 있는 방식으로 설계된 시스템은 코드 아키텍처에 광범위한 문제가 있다고 볼 수 있다.

통합 테스트(계정 생성 후 신규 사용자에게 이메일을 보내는 어플리케이션)

• 계정 생성, 데이터베이스를 ‘통합' 하는 등 두 개 이상의 컴포넌트를 함께 사용할 때 정상적으로 작동하는지 명확하게 확인하는 테스트

단위 테스트

• 계정 생성 코드, 이메일 전송 코드, 계정 정보 입력 등을 대상으로 각각의 일련 단위 테스트
• 하나의 컴포넌트가 정상 작동하는지 확인하는 테스트가 단위 테스트

결론적으로 테스트의 전반적인 목표는, 시스템에 관해 유효한 지식을 얻는 것

테스트 방법론은 아직도 너무나 어려운 것 같다. 정답도 없고 각자의 상황, 환경에 따라 다르기에 경험을 쌓아도 어려운 영역 중 하나인 것 같다. 다양한 테스트를 작성하고, 학습을 하면서 내가 느꼈던 불편함들은 다른 분들도 비슷하게 느끼는 상황들도 많았고, (대표적으로 Mocking...) 여러 공감대를 가지고 경험하다보니 최소한의 방법은 알게된 것 같지만, 아직도 어려운 영역이다.. 😭

 

7부 | 나아지기

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

• 멍청하다는 건 자신이 모른다는 걸 모르는 것
• 멍청한 사람들은 자신이 모르는 걸 안다고 생각하거나 더 알아야 할 게 있다는 걸 모른다. → 메타인지 부족

메타인지는 정말 중요한 개념이라고 생각한다. 문제를 파악할 때 내가 무엇을 알고, 무엇을 모르는지, 어떻게 접근해야 하는지 등도 결국 메타인지와 관련이 있지 않을까 생각한다.

 

공부할 분야를 스스로 알아내고 싶을 때 자문할 수 있는 몇 가지 질문

• 자신이 쓴 모든 코드에 등장하는 모든 단어와 부호를 아는가?
• 자신이 쓰는 함수의 문서를 모두 꼼꼼히 읽고 완전히 이해했는가?
• 소프트웨어 개발의 기본 원칙을 잘 이해하고 있는가? 이런 원칙을 사내 초보 프로그래머에게 완벽히 설명해줄 수 있을 정도인가?
• 프로그래머라면 자신이 작성 중인 코드에 대해 이 목록에 있는 질문에 모두 답할 수 있어야 한다.
• 프로그래밍 학습과 실습의 균형을 맞추는게 중요하다.

기본이 가장 중요하다고 했던가.. 가장 기본적이면서도 가장 어려운 영역같다. 
초심으로 돌아가서 다시 내가 사용하는 기술에 대해서 어떻게 동작하는지 원리에 대해 더 깊이있게 파고드는 학습 습관을 가지자.

 

43. 훌륭한 소프트웨어

• 진짜 훌륭한 프로그램은 사용자의 의사를 정확히 수행한다
  1. 사용자의 명령을 정확하게 따른다.
  2. 사용자가 예상한 대로 작동한다.
  3. 사용자의 의도 전달을 막지 않는다.
• 단순성을 추구하고 소프트웨어 설계 원칙을 따를 때 훌륭한 소프트웨어가 만들어질 확률은 99.9퍼센트다.