Skip to content

Commit

Permalink
docs: 7장 정리
Browse files Browse the repository at this point in the history
  • Loading branch information
gutenLEE committed Sep 2, 2024
1 parent 55a09a1 commit 6ea9780
Showing 1 changed file with 217 additions and 0 deletions.
217 changes: 217 additions & 0 deletions 7장/이유희.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,217 @@

# 7장. 코딩하는 동안

- 실용주의 프로그래머는 모든 코드를 비판적인 시각으로 바라본다
- 테스트는 버그를 찾는 작업이 아니다
- 읽고 분석하기 쉬운 코드를 쓰는 것은 대단히 중요하다

### 파충류의 뇌에 귀 기울이기


##### 백지의 공포

새로 개발하기 전 두려움의 원인은?
1. 모종의 의심. 경험에서 우러나온 직관일 수 있으니 시간을 두고 의심을 구체화하자.
2. 가면 증후군. 내 자신을 믿지 못하는 것.

> 쎄함이나 두려움이 발동되면 계획이나 설계를 잘 정리해서 동료 개발자나 사수에게 피드백을 요청하는 것이 좋을 듯. <br>
> 혼자 고민하고 숨기면 문제만 커질 수 있다.<br>
##### 자신과 싸우기
##### 파충류와 토크

1. 잠시 휴식하기
2. 그래도 안 되면 문제를 표면으로 끄집어 내라. (동료 활용)

##### 놀이 시간
1. 프로토타이핑 해보기
##### 다른 사람의 코드
1. 사람들은 저마다의 다른 본능을 가지고 있으므로 나와는 다른 결정을 내렸을 것이다. 결정의 근거를 코드에서 찾아보라
> 글을 잘 쓰려면 다양한 어휘나 표현을 접해봐야 하듯 다른 사람의 코드도 많이 봐야 한다고 생각합니다. <br>
##### 코드 이외의 것
1. 설계나 요구 사항 등 모든 것에 쎄함이 발동될 수 있다. 본능에 귀 기울이고 문제가 튀어나오기 전에 미리 대처하라.
> 당장 문제가 되지 않으니 외면하는 경우도 있었다. 결국에는 다 터지더라. <br>

### 우연에 맡기는 프로그래밍

##### 구현에서 생기는 우연
구현 과정에서 우연히 잘 동작하는 코드를 맹신하면 안 된다. 루틴을 고치거나 호출 순서를 변경하면 깨질 수 있다. <br>
모듈화, 인터페이스 아래로 구현 숨기기, 문서화, 다른 루틴을 사용할 때는 문서화된 동작에만 의존하라.

##### 비슷하다고 괜찮을 리는 없다
사실 특정한 경우에만 딱 한시간 틀리는 것은 그저 우연이었다. 더 깊고 근본적인 문제는 우연을 커버하려했던 땜빵 코드가 전체로 퍼저나갔다.

##### 유령패턴
가정하지 말라. 증명하라

##### 상황에서 생기는 우연
인터넷 검색으로 찾은 첫 번째 답에서 코드를 복사해 올 때 여러분과 동일한 상황이라고 확신하는가?
잘 되는 듯한 답을 찾는 것과 올바른 답을 찾는 것은 다르다.

##### 암묵적인 가정
테스트가 특히 가짜 원인과 우연한 결과로 가득 영역이다.
확고한 사실에 근거하지 않은 가정은 어떤 프로젝트에서든 재앙의 근원이 된다.

##### 의도적 프로그래밍 체크리스트

- [ ] 더 경험이 적은 프로그래머에게 코드를 설명할 수 있는가?
- [ ] 이것이 왜 동작하는지 아는가?
- [ ] 계획을 세웠는가?
- [ ] 가정을 기록으로 남겼는가?
- [ ] 내가 세운 가정을 테스트 해봤는가?
- [ ] 우선순위를 정했는가?
- [ ] 지금 짜는 코드가 앞으로 짤 코드에 어떻게 영향을 미칠지 생각해봤는가?

> 이 토픽에서는 디테일은 한끗 차이라는 말이 떠올랐다. <br>
> 구현은 누구나 해내지만 완성도는 천지 차이다. 그 차이를 만드는 태도?에 대해서 설명하고 있다고 느꼈다. <br>
> 내가 짠 코드는 믿고 가져다 쓸 수 있다는 피드백을 받는 날이 오길..!
### 알고리즘의 속도

##### 최고라고 언제나 최고는 아니다

적당한 알고리즘을 선택할 때도 실용적이어야 할 필요가 있다.
성급한 최적화를 조심하라. 언제나 어떤 알고리즘을 개선하느라 여러분의 귀중한 시간을 투자하기 전에 알고리즘이 정말로 병복인지 먼저 확인하는 것이 좋다.

> 성급한 최적화 조심!


### 리팩터링

##### 현실 세계의 복잡한 문제들

- 일정의 압박은 리팩터링을 하지 않는 단골 핑계다. 리팩터링이 필요한 코드는 종양이다. 일찍, 자주 하라
- 일정에 리팩터링할 시간을 확실히 포함시켜 두도록 하다.
> 이 부분은 적용하기 어려운 것이 기존 레거시가 크거나 일정이 정말 타이트한 조직에서는 일정에 리팩터링을 포함시키기 어려울 것 같다. <br>
> 어떻게든 설득을 하는 것도 능력인걸까...

##### 리팩터링은 어떻게 하는가?

마틴 파울러의 조언

1. 리패터링과 기능 추가를 동시에 하지 말라
> 리팩터링과 기능 구현을 동시에 해봤는데 버그가 나왔을 때 리팩터링의 영향인지 기능 구현을 잘못한 건지 파악하기 어려웠네요..
2. 리팩터링을 시작하기 전 든든한 테스트가 있는지 확인하라
> 레거시가 크다면 레거시 코드에 성공하는 보호코드부터 작성하라고 배웠다. 그 다음 리팩터링하기!
3. 리팩터링은 작은 단계로 나눠서 진행하라

필드 옮기기, 메서드 쪼개기, 변수명 바꾸기 등. 그리고 단계마다 테스트를 돌려봐라.


### 테스트로 코딩하기

##### 테스트에 대해 생각하기

테스트는 버그를 찾기 위한 것이 아니다!

```text
1차
`return_avid_viewers`는 `database` 의존성이 메서드 내부로 숨겨져 있어 테스트하기 어렵다.
테스트용 가짜 객체를 주입할 방법이 없어 이 테스트를 하려면 데이터베이스도 함께 구동되어야 한다.
def return_avid_viewers do
database.시청자_조회()
end
2차
이번엔 `db`를 주입받아 테스트하기 쉬워졌다. 가짜 객체를 주입하거나 진짜 데이터베이스 인터페이스를 상황에 따라 주입할 수 있게 되었다.
def return_avid_viewers(db) do
db.시청자_조회()
end
3차
`field_name`을 주입받아 테스트하기 쉬워졌다. 테스트 코드에서 `field_name`을 변경하면서 테스트할 수 있다.
def return_avid_viewers(db, field_name) do
db.시청자_조회(field_name)
end
```

> 이 예시를 보면서 테스트를 통해 `테스트 하기 쉬운 코드 = 좋은 설계 도출`, 그리고 요구사항 명확하게 이해하기 두 가지를 얻을 수 있다고 이해했다.
##### 테스트가 코딩을 주도한다

테스트 코드가 첫 번째 사용자다!
다른 코드와 긴밀하게 결합된 함수나 메서드는 테스트하기 힘들다.
메서드를 실행하기도 전에 온갖 환경 구성을 한참 해야 하기 때문이다.

##### 테스트 주도 개발

TDD: 목표가 어디인지 알아야 한다.
> 테스트 코드를 배워나가는 과도기 때 흔히 하는 실수 같다.<br>
> 검증해야 될 것이 뭔지 몰라서 단순히 통과하는 테스트를 만든다거나... **테스트를 위한** 코드가 남발된다거나.. 나도 그랬다...
##### 단위 테스트

하나의 단위가 잘 동작하는지 검증하기 위해 다른 것들로부터 분리시켜 놓고 테스트를 수행한다.
하나의 단위 차원에서는 어떤 것을 테스트할지 결정해야 한다.

<img src="https://academy.pega.com/sites/default/files/styles/1024/public/media/images/2021-08/Image%201.png?itok=vG451TAt">

> 단위 테스트가 풍부하다는 것은 일반적으로 코드의 모듈화가 잘 되어 있고, 객체가 작은 단위로 나눠져 있을 가능성이 크다. <br>
##### 계약을 지키는지 테스트하기

- 선행 조건, 후행 조건 검증하기
- 여러 모듈에 의존하고 있다면 의존 방향의 역순으로 검증하기

##### 테스트 접점 만들기

- 어떤 모듈의 내부 상태를 디버거 없이도 볼 수 있는 방법 고민하기 <br>
ex) 로그 메세지에 의미있는 정보 담기

##### 테스트 문화

여러분의 팀이 테스트하지 않으면 결과적으로 사용자들이 테스트하게 된다.
> 완전 공감...
테스트 먼저, 코드와 테스트를 함께, 테스트하지 않음
> 다음 회사는 어떤 문화일까...

### 속성 기반 테스트

##### 계약, 불변식, 속성

`불변식`: 함수 실행 전후로 어떤 상태에 대하여 항상 참이 되는 조건

코드에 존재하는 계약과 불변식을 뭉뚱그려서 속성(property)라고 부른다.
속성을 기반으로 테스하는 것이 속성 기반 테스트다.

##### 잘못된 가정 찾기, 속성 기반 테스트는 우리를 자주 놀래킨다, 속성 기반 테스트는 설계에 도움을 준다

> 비즈니스 불변식을 도출해 내는게 핵심인 것 같다. <br>
> DDD (도메인 주도 개발)이 생각났다.
> <br>
> https://happy-coding-day.tistory.com/277

### 바깥에서는 안전에 주의하라

> 작은 규모나 신생 개발 조직이라면 가장 놓치는 부분이 보안인 것 같다.<br>
> 우선순위에서 밀리니 정보보호법을 안 지키거나... 보안 장치가 미흡하거나...
> 그러다 데이터데이스 털리는 경우도 꽤나 있다네요
>
> 이 책 번역가분이 소개해주신 자료에 보안 관련 법도 있어서 아주 좋은 자료 같습니다.<br>
> https://www.kisa.or.kr/2060305/form?postSeq=7&lang_type=KO&page=#fndoDocumentPreview <br>

### 이름 짓기

###### 문화를 존중
###### 일관성
> 구성원이 합의된 언어로 소통하기!<br>
> 이벤트 스토밍이라는 도메인을 도출 기법을 실습해본 적이 있는데, 어떤 액션에 대해 참여자 6명 모두가 생각한 단어가 달랐습니다...<br>
> 이때 경험으로 구성원 모두가 합의된 보편 언어를 정립하는 것이 매우 중요하다고 느꼈습니다.<br>
>
> [이벤트 스토밍 인 액션: 이벤트 스토밍 소개와 적용 방법](https://www.youtube.com/watch?v=gihxS6eE1DM)
###### 이름 바꾸기는 더 어렵다
> 완전 경험했다. 이전 회사에서 멘탈 모델에 불일치하는 네이밍인데 이미 오랜 기간 사용되어 문서, 코드, 데이터베이스 모든 곳에 퍼져나가 변경할 수 없었다...

0 comments on commit 6ea9780

Please sign in to comment.