‘앤드류 헌트, 데이티드 토머스, 실용주의 프로그래머(인사이트), 2020)‘를 읽고, 제가 느낀 방식대로 정리한 문서입니다.

1. 실용주의 철학

• 나의 기술에 애정과 관심을 가지자.
• 내가 무엇을 하고 있는지 생각하면서 일하자.
• 이튼 칼리지의 500년의 잔디밭과 달리, 나는 며칠 후부터 바로 결과를 볼 수 있다. 몇 년이 지나고 나 스스로도 그것에 대해 놀래보자.

1. 내가 한 일에 대해서는 적극적으로 책임을 진다.

• 내가 분명히 모든 것을 통제하지는 못할 수도 있지만, 그 상황에서도 나 나름의 윤리의식과 판단 기준으로 해당시점에 있어 최선이라고 생각되는 결과를 도출해야 한다.
• ‘고양이가 코드를 삼켰어요’의 어설픈 변명보다는 그 변명을 없애려해보고 대안을 제시한다.

2. 깨진 창문

• 발견하자마자 바로 고치자.

3. 돌멩이 수프와 삶은 개구리

• 일단 저지르고, 예외가 발생하면 그에 대해 처리하자.

• 냄비 속의 개구리처럼 서서히 익어가는 우를 범하지 말자.

  • 큰 그림을 보자. 개인적으로 뭘 하는지만 보지 말고, 주변에서 어떠한 일이 일어나는지 지속적으로 보자.

4. 적당히 괜찮은 소프트웨어

• 적당한 타협이 필요하다. 완벽을 위해 과도한 시간을 쏟지 말자. 완벽은 상황에 따라 다르고 대부분 불가능하다.

5. 지식 포트폴리오

• 지식에 대한 투자가 언제나 최고의 이윤을 낸다.

  • 하지만 내가 지금 공부하는 것은 Expirigin assets이다. 내가 현재 공부하는 것이 영원히 나를 지탱해줄 것이라고 생각하면 안 된다.

    • 그렇다면 어떻게 해야할까? 금융 포트폴리오와 같은 관점에서 생각해보자.
    • 주기적: 비록 소량 투자여도 그 습관 자체가 금액의 합계만큼 중요하다. 이것이 가장 중요하다.

    • 다각화: 특정 기술에만 얽매이지 말고, 더 많은 기술을 배워보자.

      • 기술 서적을 자주 읽자.

    • 리스크 관리: 안정적 결과를 가져다 줄 것과 불안하지만 흥미로워보이는 것을 함께 균형을 맞춰보자.

      • 모든 독서와 연구는 시간이 걸리고, 시간은 늘 부족한 자원이다. 그래서 미리 계획해야할 필요가 있다.
    • 싸게 사서 비싸게 팔기: 새롭게 떠오르는 기술이 인기를 끌기 전에 학습하고 우위에 서 보자.
    • 검토 및 재조정: 언제나 현재의 포트폴리오의 방향성에 대해 검토 및 재조정이 필요하다.

6. 소통하자

• 내가 만들고자 하는 것을 사용자에게 설명하자. 그리고 ‘이게 내가 말하고자 하는 것을 잘 전달하는가?‘라고 자문해본다. yes라고 답할 수 있을 때까지 다듬자.
• 무엇을 말하는가와 어떻게 말하는가는 모두 중요하다.

2. 실용주의 접근법

7. 중복의 해악

• 유지보수는 전체 개발의 일상적 활동이다.
• 지금 당장 몇 초를 절약할 수 있을지 몰라도, 나중에는 몇 시간을 잃게 될 수도 있다.
• 코드 리뷰를 하며 타인의 코드와 문서를 읽는다. 단순히 기웃거리는 것이 아니라 배우는 것이다. & 접근은 상호적이다.

8. 직교성 ( = decoupling, independence)

• Q. 특정 기능에 대한 요구사항 변경시 영향 받는 모듈의 수는? A. 직교적 시스템에서 답은 ‘하나’

  • 관련 없는 것들끼리는 영향이 서로 없어야 한다.
  • MVC 패턴처럼 서로 관련 없는 것들끼리는 결합도를 줄여야 한다.

9. 가역성

• 결정은 언제나 바뀔 수 있고, 코드도 그에 맞춰져야 한다.

10. 예광탄

• 엉성하더라도, 특정 기능이 작동하는 예광탄 코드를 만든다 → 그렇게 만들어진 애플리케이션의 요소들을 이어붙이면 사용자와 개발자에게 보여줄 프레임워크가 생성된다 → 보충해나간다.

11. 프로토타입과 포스트잇

• 프로토타입의 코드는 예광탄과는 달리 나중에 버릴 수 있다. 예광탄이 발사되기 전에 거쳐야 하는 & 위험을 수반하는 모든 것에 대해 조사하는 단계가 프로토타입

  • 그러므로 정확하지 않아도 되고(dummy data사용), 완전하지 않아도 된다.(input에 대해 동작만 하면 된다). 당연히 안정적이지 않을 가능성이 크고, 프로토타입 코드는 주석이나 문서화도 많이 필요 없다.

13. 추정

• 어떤 의미에서 모든 답은 추정치다.
• 추정치가 잘못되더라도 도망가지 않는 용기를 가지자. 왜 추측과 실제가 달라졌는지 원인을 찾는다. 점차 그 차이가 적어지도록 노력한다.
• 코드의 진행과 함께 일정도 반복해가며 조정하자.

4. 실용주의 편집증

• 완벽한 소프트웨어는 만들 수 없다. 그 어느 누구도 완벽한 소프트웨어는 만들지 못했고, 이것을 기정 사실로 받아들이지 않는다면, 불가능한 꿈을 뒤쫓으며 시간과 노력을 낭비하게 될 것이다.

21. 계약에 의한 설계

• 최소 한도를 약속하자. shy & lazy. 내어줄 것만 내어주고, 할 것만 하는 코드
• 문제를 찾고 원인을 밝히기 위해서는, 사고가 났을 때 일찍 멈추는 것이 좋다.

22. 죽은 프로그램은 거짓말을 하지 않는다.

• 문제가 발생한다면 더 이상 망치지 말고, 멈추자.

23. 단정적 프로그래밍

• ‘이건 절대 안 일어날거야’라는 생각이 든다면, 그것을 확인하는 코드를 추가하자.

24. 언제 예외를 사용할까?

25. 리소스 사용의 균형

• 시작한 것은 끝내라.

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

26. 결합도 줄이기

• 코드는 각각의 세포처럼. 각자 할 일만 하고, 불필요하게 결합되지 않도록.

27. 메타프로그래밍

• 코드에는 추상화를, 메타데이터에는 세부 내용을 담는다.

  • 메타데이터: 데이터에 관한 데이터. 즉 애플리케이션이 어떻게 실행되어야 하고, 어떤 자원을 이용해야하는지 등에 대한, 무언가 계속해서 바뀔 수 있는 것.

28. 시간적 결합

• 동시성concurrency은 둘 이상의 코드가 동시에 실행중인 것처럼 행동하는 것

  • 실행 중에 코드의 다른 부분으로 실행을 전환할 수 있는 환경에서 코드를 구동해야한다.

• 병렬성parallelism은 실제로 동시에 실행되는 것

  • 두가지 일을 동시에 할 수 있는 하드웨어가 필요하다.
• 시스템의 규모가 어느 정도 넘어가면 동시성을 반드시 고려해야 한다. 세상은 순차적이 아닌 비동기적이므로.
• JS에서의 동시성은 event loop가 비동기함수들을 관리함으로써 작동이 가능

29. 단지 뷰일 뿐이야.

• 기능과 뷰를 완전히 분리하자. 좋은 예는 MVC 모델

  • 모델: 대상 객체를 나타내는 데이터 모델/뷰나 컨트롤러에 대해 직접적으로 연결되지 않는다.
  • 뷰: 모델을 해석하는 방법/ 모델의 변화와 컨트롤러가 보내는 이벤트를 구독
  • 컨트롤러: 뷰를 제어하고, 모델에 새로운 데이터를 제공/ 모델과 뷰에 모두 이벤트 보냄

30. 칠판

• 모든 것을 한번에 볼 수 있는 페이지와 함께 그것을 통해서 작업의 흐름을 조율하자.

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

• 테스트하기 쉬운 코드를 만들자. 대부분 반복적인 일일지라도 상황을 검토하고, 잠재적 문제를 예상한다면 예방할 수 있다.

31. 우연에 맡기는 프로그래밍

• 내가 지금 무엇을 하고 있는지 알아야 한다. 우연에 맡겨서 시간과 코드가 우연처럼 흘러가게 내버려두지 말자.

• 적절하지 않다면 언제든지 리팩토링을 해야 한다.

  • 다만 일정이 늦어져서 발생하는 비용이 리팩토링을 하지 않을 때의 비용보다 적어야 한다. 계약은 이미 정해져 있다.

33. 리팩터링

• 지금 리팩터링을 하지 않으면, 나중에 더 많은 의존성을 신경쓰면서 해야 한다.

  • 일정에 여유가 생기면 해야지! → 일정에 여유가 생길 일은 없다.

34. 테스트하기 쉬운 코드

• 정해놓은 약속을 잘 지키는 코드는 테스트하기 쉽다.
• 항상 테스트를 염두에 두고 설계하자.

7. 프로젝트 전에

36. 요구사항의 구렁텅이

• 요구사항이 겉으로 드러나 있는 경우는 드물다. 수집하려 하지 말고 채굴하자.
• 하나의 프로젝트에 대해서는 같은 용어를 쓰자. 용어를 규정하는 문서를 만들고 공유하고 유지하자.

37. 불가능한 퍼즐 풀기

• 어떤 제약조건은 절대적이지만, 다른 것들은 대부분 지레짐작으로 어려워보이는 것이다.

  • 풀리지 않는 문제라면, 생각 가능한 모든 해결 경로를 다 나열하고, 하나씩 해보자. 안된다면 왜 안 되는지에 대해 설명해보자.
  • 진짜 문제를 풀려고 노력하는지, 혹은 중요하지 않은 다른 것에 정신이 팔려있는지 확인해보자.
  • 문제 풀기를 어렵게 만드는 이유가 무엇인지 생각해보자.

38. 준비가 되어야만

• 의심되는 것이 있다면, 그것을 해결하고 시작하자. 나의 수행 능력에 직감도 충분히 관여한다.

39. 명세의 함정

• 명세를 ‘완벽’하게 쓰고, 코드 작성을 하려고 하면 코드 작성은 못 한다. 완벽은 없다.

  • 어떤 일들은 설명하기보다 실제로 하는게 더 쉽다.

8. 실용주의 프로젝트

41. 실용주의 팀

• 깨진 창문을 내버려 두지 말자.
• 덧질을 언제 멈출지 알자.
• 반복하지 말자.
• 소통하자.

42. 유비쿼터스 자동화

• 생각 없이 행할 수 있는 중요한 작업의 수가 늘어남에 따라 문명은 발전한다.
• 우리의 목표는 자동화, 무인화이고, content-driven인 작업 흐름을 유지한다.

43. 가차 없는 테스트

• 일찍, 자주, 자동으로 테스트하자.

44. 결국은 모두 글쓰기

• 아무리 흐린 먹물이라도 가장 훌륭한 기억력보다 낫다.

45. 위대한 유산

• 기대를 가뿐하게 뛰어넘자. 기대하는 것보다 조금 더 하자. 그 과정은 절대 가뿐하기 않겠지만!

• 소유권에 대한 긍지

  • 내가 이것을 만들었고, 내 작품의 품질을 보증합니다. 사람들이 코드에 붙은 내 이름을 보고 그것이 튼튼하게 잘 작성되었고, 제대로 테스트 되었고, 훌륭히 문서화되었을 것이라고 기대하도록 만들자. 진정으로 프로페셔널한 일. 진정한 프로페셔널이 작성한.