동료들과 실용주의 프로그래머라는 책을 같이 읽고 있습니다. 공부하면서 정리한 내용을 블로그에도 남겨볼까 합니다. 아직 못 읽은 부분은 계속 업데이트하려고 합니다.

2장. 실용주의 접근법

새로운 아이디어에 전력투구하기 전에 먼저 아이디어를 검증하고 피드백을 받아 보는 것이 매우 중요하다.

Topic8 좋은 설계의 핵심

좋은 설계는 나쁜 설계보다 바꾸기 쉽다.

ETC(Easier to Change)

‘내가 방금 한 일이 전체 시스템을 바꾸기 쉽게 만들었을까, 어렵게 만들었을까?’ → 파일 저장, 테스트 작성, 버그 수정시에 물어보기

코드의 결합도를 낮추고 응집도를 높인다.

컴포넌트 개발할 때 신경쓰고 있지만 정말 어렵다. 버튼 등 간단한 컴포넌트는 원칙을 지키기 비교적 쉬우나, 여러 개의 컴포넌트를 같이 쓰는 등의 컴포넌트는 결합도가 높으면 사용하기는 쉬워지나, 유지보수가 안 좋음. 디자인 시스템을 개발할 때 처음에는 바뀔일이 없던 컴포넌트도 나중에는 바뀌기 시작하고, 그래서 컴포넌트를 미리 넣어놓기 보다는 위치 정도만 잡아두고, 사용할 때 그 위치에 컴포넌트를 넣는 식으로 구현

도전해 볼 것

• 일상적으로 사용하는 설계 원칙
  • DRY…
• ETC를 따르는 코드를 작성할 때 큰 도움을 주거나 걸림돌이 되는 부분?
• 에디터에 “ETC?” 기능을 설정해 볼 것
  • webstorm file watcher → 되나?

FileWatcher는 컴파일러 같은건 할 수 있는데 메시지 띄우는건 못할 듯.

Topic9 DRY: 중복의 해악

모든 지식은 시스템 내에서 단 한 번만, 애매하지 않고, 권위 있게 표현되어야 한다.

주석을 달기 전에 먼저 코드에 의도를 드러낼 것.

모듈이 자료 구조를 노출하면 언제나 모듈의 구현과 그 자료 구조를 사용하는 코드 사이에 결합이 생긴다. 가능하다면 언제나 객체의 속성을 읽고 쓸 때 접근자 함수를 사용할 것.

개발자 간의 중복 → 적극적이고 빈번한 소통

개발자 간의 중복은 엄청 공감됨. 이번에 만든 기능이 다른 분이 먼저 개발했었던 경우가 많음. 이런걸 찾기가 굉장히 힘듦. 그래서 요즘에는 다른 분들에게 먼저 물어보고 시작함.

Topic10 직교성

하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다.

우리가 설계하고 싶은 것은 자족적인(단일하고 잘 정의된 목적을 가진) 독립적인 컴포넌트

직교적인 컴포넌트들을 결합함으로써 단위 노력당 더 많은 기능을 얻을 수 있다.(M x N)

‘특정 기능에 대한 요구 사항을 대폭 변경하는 경우 몇 개의 모듈이 영향을 받는가?’ → 한개여야 한다.

불필요한 것은 다른 모듈에 보여 주지 않으며, 다른 모듈의 구현에 의존하지 않는 코드를 작성할 것.(shy)

직교적으로 설계하고 구현한 시스템 → 테스트하기 더 쉽다

모듈 수준의 테스트나 단위 테스트가 통합 테스트보다 테스트 케이스를 만들고 수행하기 훨씬 쉽다.

단위 테스트를 작성하는 행위는 직교성을 테스트해 볼 수 있는 기회

도전해 볼 것

• GUI가 있는 경우 여러 기능을 묶어서 사용하거나 할 때에는 수동으로 해야 함. 셸 프롬프트에서는 그걸 묶은 새로운 명령어를 만들어서 사용 가능.

연습 문제 1

• Split2가 직교적이라고 생각. Split1에는 다음 줄로 이동하는 역할이 포함. 하지만 바로 다음 줄이 아니라 한 줄씩 건너뛰는 등 요구사항이 변경되면 readNextLine을 변경해야 함.

Topic11 가역성

되돌릴 수 없는 결정을 최대한 줄인다. → 우리의 선택은 최선이 아닐 수 있다.

새로운 프로젝트의 백엔드 서버(파일 업로드가 있는)를 람다로 올렸다가 request size 제한이 있다는 걸 알아서 옮겼던 기억이…

컴포넌트 설계할 때도 어렵다. 어느 정도의 미래까지 대비해야 할지

Topic12 예광탄

요구 사항으로부터 최종 시스템의 일부 측면까지 빨리, 눈에 보이게, 반복적으로 도달하게 해 줄 무언가가 있어야 한다.

요구 사항에서 의문이 드는 부분이나 가장 위험이 커 보이는 곳의 코드를 가장 먼저 작성

시스템을 구성하는 요소를 모두 연결해 놓은 후라면 목표물에 얼마나 근접했는지 확인할 수 있고, 조정이 가능하다.

목표물에 맞을 때까지 조준을 옮겨야 한다.

• 예광탄 코드
  • 기능은 별로 없지만 완결된 코드
  • 최종 시스템 골격 중 일부가 된다.
• 프로토타입
  • 예광탄을 발사하기 전에 수행하는 정찰 단계

한 사이클을 한 기능에서 쭉 돌아보는 방식. 배포 환경에서 발견되는 문제점을 미리 발견할 수 있음. 가장 큰 위험 요소를 빨리 파악할수록 고치는데 필요한 비용은 줄어든다고 생각.

Topic13 프로토타입과 포스트잇

프로토타입은 위험 요소를 분석하고 노출 시킨 후, 매우 저렴한 비용으로 바로잡을 기회를 얻는 것

당장 중요하지 않은 세부 사항이라면 일단 무시하면서 코딩할 수 있다.

프로토타이핑의 대상은 위험을 수반하는 모든 것 → 이를 통해 배우는 교훈이 가치가 있다.

• 아키텍처
• 추가 기능
• 외부 데이터 구조 혹은 내용
• 외부 도구나 컴포넌트
• 성능
• 사용자 인터페이스

무시해도 좋을 것들

• 정확성
  • 더미 데이터 사용
• 완전성
  • 입력 데이터 하나와 한 가지 메뉴 항목만 작동해도 됨
• 안정성
  • 오류 검사는 빼먹거나 무시
• 스타일
  • 주석이나 문서가 많지 않아야 한다.
  • 프로토타입 결과를 문서로 많이 작성할 것

규명할 만한 사항

• 주요 영역의 책임이 잘 정의되었고 적절한지
• 주요 컴포넌트 간의 협력 관계가 잘 정의됐는지
• 결합도는 최소화했는지
• 중복이 발생할 만한 곳이 있는지
• 정의된 인터페이스와 제약 사항을 수용할만 한지
• 각 모듈이 실행 중에 필요한 데이터에 접근할 수 있는 경로를 갖고 있는지
• 모듈에 데이터가 필요한 시점에 데이터 접근이 가능한지

프론트 단에는 데이터 별로 필요한 시점이 있는데 개발하다 보면 필요한데 아직 못 불러오거나 하는 경우가 있음.

이번에 게시판에 대댓글을 추가하는데 (댓글까지 있었음) 저와 백엔드 개발자님은 현재 디비로 충분히 대댓글까지 커버할 수 있을거라고 생각했었는데, 만들고보니 현재 구조에서는 따로 분리하는 편이 더 나을 거 같다는 판단을 함.

이것도 UI를 만들어놓고 api 연동을 했었는데, UI는 텍스트만 나와도 되니까 api 연동을 맨 먼저 해보는 것이 어땠을까 하는 생각이 듦.

프로토타입을 코드로 만들 때는 시작하기 전에 항상 모든 사람에게 폐기 처분할 코드임을 밝혀야 한다.

연습 문제 3

1. 디자인 팀에게 피그마로 만들어줄 것을 요청
2. react, vue

Topic17. 셸 가지고 놀기

GUI 환경의 기능은 설계자가 의도한 범위를 넘어설 수 없다.

도커로 서버를 켜는 명령어는 만들어놓고 유용하게 쓰고 있다. 하지만 그 이상의 활용은 못 해봄.

도전해보기

1. 가르쳐 줘 본 적 없음. 알아서 잘함. 자동화 할만한건 아직 없음

셸을 사용할 일이 많이 없어서 와닿지는 않지만 저자의 의도는 알겠음.

Topic18. 파워 에디팅

유창해지는 것의 가장 큰 이점은 사용법을 생각하지 않아도 된다는 것. 속도가 빨라지면 이점이 있음

1. 텍스트 편집 시 문자, 단어, 줄, 문단 단위로 커서를 이동하거나 내용 선택
2. 반대쪽 괄호로 이동 → control + M
3. control + option + [] ⇒ navigate between code blocks
4. option + command + L ⇒ reformat code
5. command + shift + / ⇒ 여러줄 주석
6. shift + command + z ⇒ redo
7. shift + command + [] ⇒ move between tabs
8. command + L ⇒ go to line number
9. search “sort lines” on command panel

트랙패드없이 작업을 해봐야겠다. 분명히 생산성 향상에 큰 도움이 될 거 같다.

Topic19. 버전 관리

1. 롤백하기 → revert commit
2. 신입이 들어왔을 때 초기 세팅을 하나의 셸 스크립트로 퉁칠 수 있을까? 있다면 편하긴 하겠다.
3. 다른데는 깃허브에서 어떤 기능까지 쓰는지 궁금. discussion도 쓰나? 이슈는?

Topic20. 디버깅

1. 비난 대신 문제를 해결할 것. 어쨌든 해결해야 한다.
2. “그건 불가능해”라는 반응하지 말 것. 실제로 일어난 일이니까.
3. 표면에 보이는 증상만 해결하려고 하지 말고 문제의 근본 원인을 고민할 것
4. 코드를 고치기 전에 실패하는 테스트부터 한다. → ‘명령 하나’로 버그를 재현하기 위해
5. “select”는 망가지지 않았다. 컴퓨터는 거짓말하지 않는다. 시스템 탓을 하지 말 것
6. 가정하지 말고 증명하라.
7. 버그를 미리 잡을 순 없는지 계속 고민해볼 것

프론트는 사용자의 환경이 매우 다양하다. 값을 참조하는 것도 그 구문을 실제로 호출하는 시점에 따라 에러가 날 수 있음.

Topic21. 텍스트 처리

기본적인 도구만으로는 해내기 힘든 종류의 변환 작업이 있을 수 있고, 이를 위해 텍스트 처리 도구가 필요하다. ex) json -> yaml 변환기

Topic22. 엔지니어링 일지

파일이나 위키말고 종이를 사용해볼 것

1. 기억보다 믿을 만하다.
2. 진행 중인 작업과 관련없는 발상을 일단 쌓아놓을 수 있다.
3. 고무 오리와 같은 역할

개발자는 노트북에 적는게 편하겠지만 항상 들고 다닐 수 있는가? 라고 물어본다면 No인 거 같다.