[실용주의 프로그래머]

* 정리하다가 그냥 공개....

Before Reading

실용주의란 무엇인가, 실용주의 프로그래머는 어떻게 될 수 있을까.

개발을 하면서 실용주의적인 개발에 대해 생각해보았지만 혼자서 답을 찾기 어려운 문제였던 것 같다. 제목부터 실용주의를 담은 유명한 이 책을 읽으면서 실용주의에 대해 다시 생각해보고 좋은 개발에 대한 나만의 정의를 보완하는, 좋은 시간을 만들 수 있을 것 같다.

 

이 책을 선택한 이유?

읽어보고 싶었던 책이기도 했는데, 좋은 기회로 스터디를 할 수 있게 되어 읽게 되었다.

 

1장. 실용주의 철학

1. 당신의 인생이다.

• 직접 바꾸어라

2. 고양이가 내 소스코드를 삼켰어요

• 실수나 무지 같은 단점에 대해서도 정직해져야 한다
• 어설픈 변명을 만들지 말고 대안을 제시하라

3. 소프트웨어 엔트로피

• 깨진 창문(나쁜 설계, 잘못된 결정, 혹은 형편없는 코드)을 코치지 않은 채로 내버려 두지 마라. 발견하자마자 바로 고쳐라. 적절히 고칠 시간이 충분치 않다면 판자로 덮는 것만이라도 하라

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

• 변화의 촉매가 되라.

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

6. 지식 포트폴리오

• 매년 새로운 언어를 최소 하나는 배워라
• 기술 서적을 한 달에 한 권씩 읽어라 (+ 기술 서적이 아닌 책도 읽어라)
• 지역 사용자 단체/모임에 참여하라
• 요즘 흐름을 놓치지 말라 - 자신이 배운 교훈들을 현재 프로젝트에 적용하도록 노력하라
• 이번 주부터 새로운 언어를 배우기 시작하라
• 비판적 사고
  • 왜냐고 다섯 번 묻기
  • 누구에게 이익이 되나?
  • 어떤 맥락인가?
  • 언제 혹은 어디서 효과가 있을까?
  • 왜 이것이 문제인가?

7. 소통하라!

• 말하고 싶은게 무언지 알아라
• 청중을 알아라
• 때를 골라라

2장. 실용주의 접근법

8. 좋은 설계의 핵심

• 좋은 설계는 나쁜 설계보다 바꾸기 쉽다.
• ETC(Easy-To-Change)
  • 앞으로 어떻게 바뀔지 모르겠을 때, 언제나 ‘바꾸기 쉽게'라는 길을 선택.
  • 5선택과 변경사항에 대한 추측을 정리하고 소스코드에 표시. 나중에 피드백을 줄 수 있다.

9. DRY: 중복의 해악

• 소프트웨어를 신뢰성 높게 개발하는 유일한 길, 개발을 이해하고 유지 보수하기 쉽게 만드는 유일한 길.
• 반복하지 마라 - 매크로 함수 사용 이유를 말하는 거임
• 부주의한 중복은 피해라 - 길이는 계산되는 필드로 만드는 것이 낫다
  • 지식의 중복/의도의 중복도 DRY의 범주이며 같은 코드가 들어가 있어도 의도가 다르면 DRY가 아니다
• 가능한 곳에서는 언제나 객체의 속성을 읽고 쓸 수 있는 액세스 함수를 사용하라
• 재사용하기 쉽게 만들라

10. 직교성

= 독립적. 결합도 줄이기. decoupling. 하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다.

• 코딩 - 전역 변수를 피해라 → 해당 데이터를 공유하는 다른 컴포넌트와 묶이기 때문
• 코드의 결합도를 줄여라.
  • 데메테르 법칙
• 전역 데이터를 피하라.
  • 전역 데이터 사용 ⇒ 다른 컴포넌트와 커플링.
  • 싱글턴 패턴을 사용할 땐 주의 ⇒ 불필요한 커플링을 만들어 낸다.
• 유시한 함수를 피하라.
  • 알고리즘은 다르지만 유사한 함수를 여럿 구현해야 할 때가 있다.
  • Strategy pattern을 사용하여 더 낫게 구현할 수 없는지 고민해봐야 한다.

자신이 작성하는 코드를 항상 비판적으로 바라보는 습관을 길러라. 기회가 있을 때마다 코드의 구조와 직교성을 개선하기 위해 노력하라(리팩터링).

11. 가역성

• 결정이 돌에 새겨지는 것이라 가정하고, 발생할지도 모를 우연한 사건들에 대해 준비하지 않는 데에서 실수가 나온다

12. 예광탄

목표물을 찾기 위해 예광탄을 써라

• 전에 만들어진 적이 없는 전혀 새로운 것을 만들려고 할 때, 즉각적인 피드백이 필요하다.
• 예광탄 개발 방법은 점진적인 접근 방법이다. 예광탄 코드는 여러 장점이 있다.
  • 사용자가 뭔가 작동하는 것을 일찍부터 보게 된다.
  • 개발자가 들어가서 일할 수 있는 구조를 얻는다.
  • 통합 작업을 수행할 기반이 생긴다.
  • 보여줄 것이 생긴다.
  • 진행 상황에 대해 더 정확하게 감을 잡을 수 있다.
• 예광탄은 지금 맞히고 있는 것이 무엇인지 보여준다. 그러나 꼭 목표물이라는 보장은 없다. 그럴 경우 목표물에 맞을 때까지 조준을 옮겨야 한다. 이것이 핵심이다.

→ 솔직히 예광탄도 예시가 좀 이해가 안 되었는데, 다른 블로그에 정리된 글을 보고 좀 이해했다

 

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

• 프로토타입은 실제 제품보다 훨씬 저렴하게 만들 수 있기 때문에 다양한 산업 분야에서 아이디어를 실험해보기 위해 이용한다. 소프트웨어 프로토타입은 꼭 코드로 작성할 필요는 없다. 포스트잇, 화이트보드, 그림판, 인터페이스 빌더 등을 이용해 만들어 볼 수도 있다.
• 위험을 수반하는 모든 것, 이전에 해본 적이 없는 것, 최종 시스템에 매우 중요한 것, 증명되지 않았거나, 실험적이거나, 의심이 가는 것, 심적으로 편하지 않은 것 모두가 프로토타이핑의 대상이 될 수 있다.
• 프로토타입의 가치는 생성된 코드에 있는 것이 아니라 이를 통해 배우게 되는 교훈에 있다. 이것이 프로토타이핑의 진정한 핵심이다.

14. 도메인 언어

잘 모르겠다…. 하단은 검색하다 본 다른 분이 정리한 내용이다.

• 내부 도메인 언어
  • RSpec이나 phoenix router처럼 host language가 있는 것.
  • 호스트 언어를 이용하여 도메인 언어를 공짜로 더 강력하게 만들 수 있다는 장점.
  • 호스트 언어의 문법과 의미론을 따라야하기 때문에 어느 정도 타협이 있어야 함.
• 외부 도메인 언어
  • cucumber나 Ansible처럼 자체 언어가 있는 것.
  • 의미 추가에 파서에 추가하기만 하면 됨.
  • 파서 만들 때, 절약하는 것보다 더 많은 시간을 쏟지는 말아라.
  • 가능하면, YAML이나 JSON, CSV 처럼 널리 통용되는 외부 언어를 사용하거나 내부 언어 사용 고려.

15. 추정

• 추정하는 법을 배우고 추정 능력을 계발하여 무언가의 규모를 직관적으로 짚을 정도가 되면, 추정 대상의 가능성을 가늠하는 마법과 같은 능력을 발휘할 수 있게 될 것이다.

3장. 기본적인 도구

16. 일반 텍스트의 힘

• 지식 저장 가능한 최고의 포맷
• 거의 모든 도구로 지식을 다룰 수 있음

17. 셸 가지고 놀기

GUI 인터페이스의 장점은 WYSIW-YG(What You See is What you Get)

즉, 여러분이 보는 것이 여러분이 얻는 것이라는 것이다. 그러나 단점은 WYSUAYG(What You see Is All You Get) 즉, 여러분이 보는 것이 여러분이 보는 전부라는 것

GUI환경은 일반적으로 설계자의 의도에 따른 제약을 받는다. 때문에 명령어 쉘의 힘을 활용하는 것은 너의 사고를 넓히는 첫번째 발자국.

[TODO] Git-Command 와 VIM-Command 마스터 하기.

→ 실제로 vim 에 대해 잘 모르는 부분이 많은데, 기초부터 다져볼 수 있는 사이트가 많아 실제로 조금 연습해보았다.

http://vimgenius.com/lessons/vim-intro

https://www.shortcutfoo.com/app/dojos/vim/beginner-text-navigation/practice

→ mac terminal은 편하게 꾸몄지만 ubuntu나 linux 내부 터미널 등을 다루는 것은 아직도 어렵게 느껴진다. 이러한 툴들도 잘 다룰 수 있도록 세팅하는 노력을 기울이도록 할 것이다.

18. 파워 에디팅

117p. 에디터

IDE 중 인텔리제이를 많이 사용하고 있는데, 평소 듣는 강의에서 정말 많은 단축키를 사용하는 것이 매우 어렵게만 느껴졌었다. 그러나 책을 보니 나도 그정도로 다룰 수 있도록 숙련도를 키우는 것이 좋을 것 같다는 생각이 들게 해주었다. 118의 도전 과제들을 모두 완수할 수 있도록 틈틈히 공부할 것이다.

122p. 복구하는 방법

맥의 터미널 같은 경우 많은 깃허브에서 각자 자신만의 설정으로 꾸민 많은 레포들을 확인 할 수 있다. 이러한 버전 관리의 강력함을 저자처럼 모든 세팅을 관리하는 데에 사용하는 것도 좋은 방법일 수 있을 것 같다.

19. 버전 관리

124p. 버전 관리

저번 빅챗 발표에서도 git 의 복구에 대한 재미있는 이야기를 들을 수 있었다. 나도 팀 프로젝트에서 잘못 업로드 된 secret 파일을 삭제하는 것을 알아보는 과정에서 git을 잘 알고 또 사용하는 것이 중요한 능력임을 깨달았다.

소스관리

언제나. 혼자서 한 주짜리 프로젝트를 진행하는 경우일지라도. 나중에 ‘버리기로 한’ 프로토타입일지라도. 심지어 여러분이 작업하는 것이 소스코드가 아닐지라도. 모든 것이 소스코드 관리 아래 있도록 하라.

→ 소스 관리 측면에서 혼자서 공부해본 것도 기록하는 습관을 들일 수 있도록 노력하고 있는 입장에서 많은 공감이 되었던 것 같다.

→ 빠르게 하는 방법을 찾자

20. 디버깅

• 디버깅은 단순히 문제 풀이일 뿐
• 디버깅과 테스트의 연관관계, 중요성
• → 항상 테스트보다는 기능 개발에 급급하여 제대로 된 테스트를 만들지 못한다. 이번 기회에 보다 확실한 TDD를 지향할 수 있도록 이 내용을 명심해야 할 것 같다.
• 가장 속이기 쉬운 사람은 자기 자신이다
• 컴퓨터는 거짓말하지 않는다

Bug

비난 대신 문제를 해결하라. 버그가 여러분의 잘못인지 다른 사람의 잘못인지는 그리 중요한게 아니다. 어쨌거나 그 버그는 여러분의 문제로 남는다.

버그를 목격하는 순간 “정말 그럴리가 없는데” 로 시작하는 사고에 감정을 소모하지 말라. 분명히 그런 일은 일어날 수 있으며, 실제로도 일어났기 때문이다.

버그를 고치는 최선의 첫 단계는 그 버그를 재현할 수 있게 만드는 것이다. 만약 재현할 수 없다면 어떻게 그 버그를 고쳤다는 것을 알 수 있겠는가?

→ 버그에 대해 다시 생각해보게 되었다.

21. 텍스트 처리

• 일반 텍스트가 형식이 없는 것은 아니다.
  • HTTP, JSON, SMTP, IMAP, YAML 모두 가능
  • Why?
    • 지원 중단에 대한 보험
    • 기존 도구의 활용
    • 더 쉬운 테스트 

22. 엔지니어링 일지

• 수첩으로 직접 적어서 종이에 글씨를 써라. 회고록을 쓰는데는 도움이 될 것이다.

→ 저자가 설명하는 일지와는 조금 다르지만, 나도 개발 과정중 발생하는, 혹은 생각해보았던 문제점을 노션에 모두 적고 있다. 실질적으로 도움이 되는 경험도 있고 현재 플젝에서 가볍게 적고 있는 KPT 회고 작성시에도 도움이 된다.

4장. 실용주의 편집증

완벽한 소프트웨어는 존재하지 않는다

23. 계약에 의한 설계

152p. DBC와 TDD

→ TDD에서는 미처 캐치하지 못한 “나쁜” 상황들에 대해 다시 생각해볼 수 있는 기회가 되었다.

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

• 불가능한 뭔가가 발생했다는 것을 코드가 발견한다면, 되도록 빨리 종료해야 한다

160p. 항상 try-catch 만 사용해서 오류를 잡았는데, 최대한 빨리 “종료”하는 것도 중요하다는 것을 느꼈다.

25. 단정적 프로그래밍

• 실행되어야만 하는 코드는 절대 asset 속에 두지 마라
• 단정assert은 결코 일어나서는 안되는 것들을 검사한다.
• 하이젠버그 적인 문제 ( 하이젠베르크 + 버그 ) 언어유희적인 표현..
  • 디버깅 행위가 디버깅하려는 시스템의 행동을 바꿔버리는 것

  while ( iter.hasMoreElements()) {
  	assert( iter.nextElement() != null);
  	Object obj = iter.nextElement();
  	//...
  }
  

  ( assert 문 안에 iter 의 다음 요소가 있는지 확인하고 밑에 다시 nextElement()를 실행하니깐..)
• 반복문은 컬렉션의 원소 중 절반만 처리하게 된다. ( p164 )

→ assert 잘 몰랐는데 조금 이해하게 된 것 같다.

26. 리소스 사용의 균형

• 시작한 것은 끝내라
• C or C++ 로 개발을 할때 메모리를 할당 후 해제할때는 해당 포인터를 NULL로 만들어라. → UAF 방지

171p. 지역적으로 행동하라는 것은 추후 개발시에도 중요하게 적용될 부분일 것 같다.

27. 헤드라이트를 앞서가지 말라

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

28. 결합도 줄이기

• 열차사고: 묻지말고 말하라. 다른객체의 내부 상태에 따라 판단을 내리고 그 객체를 갱신해서는 안 된다. 객체의 내부 상태를 묻는 것으로 인하여 캡슐화의 장점은 완전히 사라지고, 또 그 과정에서 구현에 대한 지식이 코드 여기저기로 퍼져 버린다.

190p. 글로벌화의 해악 - 전역데이터를 피하라

→ 생각없이 작성한 전역변수들에 대해 다시 생각해보게 되었다. 사용한 코드들을 다시 보고 정말 전역으로 선언해도 괜찮은 것이었는지 되돌아보았다.

29. 실세계를 갖고 저글링하기

이 파트는 어떤분이 잘 정리해두어서 이를 보면서 많은 도움이 되었다.(링크)

30. 변환 프로그래밍

31. 상속세

상속의 전제가 무너지는 경우가 많다.(비지니스 레벨에서 반드시 ##가 %%야! 라는 경우가 의미가 없거나 없다.) 실제 공통으로 쓸만한 것이 없다. → 그럴바에 다 구현하는게 낫다