상범 정리

7장/상범.md

@@ -43,16 +43,86 @@
 가장 빠른 알고리즘이 언제나 좋은 알고리즘은 아니다. 입력값의 규모가 작다면 단순한 삽입 정렬도 퀵 정렬과 비슷한 성능을 냄
 그니까 '성급한 최적화' 조심하자. 어떤 알고리즘을 개선하느라 우리의 귀중한 시간을 투자하기 전에 그 알고리즘이 정말로 병목인지 먼저 확인하는게 좋다.
 
-> 코드 리뷰에서 흔히 일어나는 상황이라 생각한다. 이론적으로는 성능상 이점(수행시간 줄어듬)은 있긴한데.. 입력값의 규모가 작아서 눈에 띄는 이점은 없고 오히려 복잡도가 증가하는 경우가 더러 있다..  
-> 이런 경우 많지 않나요
+> 코드 리뷰에서 흔히 일어나는 상황이라 생각한다. 이론적으로는 성능상 이점(수행시간 줄어듬)은 있긴한데.. 입력값의 규모가 작아서 눈에 띄는 이점은 없고 오히려 복잡도가 증가하는 경우가 더러 있다 (이런 경우 있지 않나요..?)
 
 ## Topic 40 리팩터링
+소프트웨어 개발의 비유로 가장 널리 쓰이는 은유 = 건축
+하지만 실제로 소프트웨어 개발은 건축보다는 '정원 가꾸기'처럼 돌아감 (딱딱하기보다는 유기적으로)
+> 프로젝트 초기 세팅할 때 스캐폴딩 이라는 단어를 사용하곤 했었음, 건축으로 비유하니까 전통적인 소프트웨어 설계방식인 워터폴 방식을 고수해야 하는 것처럼 느껴져서 조금 거부감 듦
+
+마틴 파울러가 정의한 리팩터링은 '밖으로 드러나는 동작은 그대로 유지한 채 내부 구조를 변경함으로써 이미 존재하는 코드를 재구성하는 체계적 기법'
+- 밖으로 드러나는 동작이 바뀌지 않는다는 것을 보장하려면 코드의 동작을 검증하는 좋은 자동화된 단위 테스트가 필요!
+
+### 리팩터링은 언제 하는가?
+좋은 테스트가 뒷받침 된 상태서 모든 테스트가 통과 되었을 때! 일찍 그리고 자주 리팩터링 해라
+
+### 어떻게 하는가?
+작게 나누어 신중하게 작업해라
 
 
 ## Topic 41 테스트로 코딩하기
 
+### 테스트의 중요한 가치는 무엇일까? 
+테스트는 버그를 찾기 위한 것이 아니다.. 테스트의 주요한 이득이 테스트를 실행할 때가 아니라 테스트에 대해 생각하고, 작성할 때 생긴다.
+
+테스트를 먼저 생각하는 것의 이점
+- 코드의 결합도는 낮추고 유연성 올릴 수 있다. (매서드를 외부 시선으로 볼 수 있게 됨)
+- 모든 것이 명확해짐 (경계 조건, 오류 처리 등 해야 할 일에 대한 이해도가 높아짐)
+
+테스트를 먼저 생각하는 것의 이점이 많다보니 테스트 먼저 작성하자고 주장하는 TDD라는 기법이 나옴 
+
+### TDD의 기본 주기
+1. 추가하고 싶은 작은 기능 하나 결정
+2. 그 기능이 구현되었을 때 통과하게 될 테스트 하나 작성
+3. 테스트 실행, 다른 테스트는 통과하고 방금 추가한 테스트 하나만 실패해야 됨
+4. 실패하는 테스트를 통과시킬 수 있는 최소한의 코드만 작성하고 모든 테스트가 통과하는지 확인
+5. 코드 리팩토링하고 개선 후에도 테스트가 통과하는지 확인한다.
+
+상향식이나 하향식이 아니라 끝에서 끝까지 만들어라
+
+소프트웨어 테스트 계획에서 선택지는 세개다.
+1. 테스트 먼저
+2. 코드와 테스트를 함께
+3. 나중에 테스트 === 테스트 하지 않음
+
+45년차가 30년동안 테스트 코드를 써왔는데 나중엔 테스트를 쓰지 않고도 테스트에 대해 생각할 수 있게 됨 ㄷ ㄷ
+
 ## Topic 42 속성 기반 테스트
 
+불변식: 함수 실행 전후로 어떤 부분의 상태에 대해 참이 되는 조건 e.g) 리스트 정렬했을 때의 결과는 정렬 전 리스트 원소 수와 같음
+코드에 존재하는 계약과 불변식을 뭉뚱그려서 속성이라고 부름
+속성 기반 테스트로 가정을 검증하라.
+
+속성기반 테스트는 설계에도 도움을 준다.
+
+> 입력을 무작위로 처리하고 검산을 기계 장치로 만들어서 테스트 환경을 자동으로 다양화한다는 접근방법이 매우 흥미로웠음
+> 무엇이 실패했는지 알아내기 까다롭다 => 그러니 실패했을 때의 로그를 잘 찍어봐야 된다
+
 ## Topic 43 바깥에서는 안전에 주의하라
+디버깅 정보는 공격 매개체 될 수 있음
+> 종종 웹사이트에서 브라우저 콘솔에서 데이터 다 보여주는 경우 있음
+
+우리는 지나칠 정도로 의심해야 한다.
+
+단순함을 유지하고 공격 표면을 최소화할 것
+
+최소한의 권한만 짧게 부여할 것
+
+암호화는 절대 직접 만들지 말아라.. 전문가에게 맡겨라
 
 ## Topic 44 이름 짓기
+
+- 프로그래밍에서는 이름이 모든 것이다.
+- 이름 짓기는 무언가 만들 때 마다 잠시 멈춰서 "내가 이걸 왜 만드는거지?" 하고 생각하는 것.
+- 아무리 해도 적절한 이름을 떠올릴 수 없다 => 만들려고 했던 게 말도 안된다는 것
+- 문화를 존중하라
+  - i,j,k 따위의 한 글자 변수명을 짓는것도 문화에 따라선 그럴 수 있다.
+- 일관성
+  - 도메인 지식에 대한 이야기
+  - Order가 쇼핑 프로그램에선 주문이겠지만, 종교 관련 앱이라면 교단을 의미할 것.
+- 이름 바꾸기는 더 어렵다
+  - 좋은 이름을 짓더라도, 모든 것은 결국 변한다.
+  - 안좋은 이름이 발견되었다면 즉시 바꿔라. 바꾸기 어렵다면 더 심각한 문제니 그것부터 개선해라.
+
+![image](https://github.com/user-attachments/assets/36c1da8c-a8ed-4dd6-ab9c-e047278e68ba)
+