generated from muhandojeon/study-template
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
217 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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) | ||
###### 이름 바꾸기는 더 어렵다 | ||
> 완전 경험했다. 이전 회사에서 멘탈 모델에 불일치하는 네이밍인데 이미 오랜 기간 사용되어 문서, 코드, 데이터베이스 모든 곳에 퍼져나가 변경할 수 없었다... |