From 4852b2d2cc49032fbe6a92e364042ce968a9213d Mon Sep 17 00:00:00 2001 From: SangBeom Park Date: Mon, 2 Sep 2024 00:05:53 +0900 Subject: [PATCH] =?UTF-8?q?=EC=83=81=EB=B2=94=20=EC=A0=95=EB=A6=AC?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- "7\354\236\245/\354\203\201\353\262\224.md" | 74 ++++++++++++++++++++- 1 file changed, 72 insertions(+), 2 deletions(-) diff --git "a/7\354\236\245/\354\203\201\353\262\224.md" "b/7\354\236\245/\354\203\201\353\262\224.md" index 09fbe85..56987a2 100644 --- "a/7\354\236\245/\354\203\201\353\262\224.md" +++ "b/7\354\236\245/\354\203\201\353\262\224.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) +