From ab39d6e9a6ac4f2bc5fc92afbc08a141f7c100d4 Mon Sep 17 00:00:00 2001 From: SangBeom Park Date: Sun, 1 Sep 2024 14:07:39 +0900 Subject: [PATCH 1/2] =?UTF-8?q?7=EC=9E=A5=20=EC=A0=95=EB=A6=AC=20(~39)?= 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" | 58 +++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 "7\354\236\245/\354\203\201\353\262\224.md" 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" new file mode 100644 index 0000000..09fbe85 --- /dev/null +++ "b/7\354\236\245/\354\203\201\353\262\224.md" @@ -0,0 +1,58 @@ +# 7장 코딩하는 동안 + +코딩은 기계적인 작업이 아니다. +코딩할 때는 매 순간 결정을 내려야 하는데, 프로그램이 정확하게 생산적으로 작동하며 사려깊은 생각과 판단으로 결정을 내려야 한다. + + +## Topic 37 파충류의 뇌에 귀 기울이기 + +직감이 여러분의 역량에 일조하도록 하라. +직감에 귀를 기울여라. + +> 주로 경험 기반으로 말하는 경향이 있어 공감이 됐다. + +## Topic 38 우연에 맡기는 프로그래밍 + +개발자인 우리들 역시 지뢰밭에서 일한다. +하루에도 수백 개가 넘는 함점이 우리가 빠지기를 기다리고 있다.. + +> 운 좋게 동작하고 있는 코드가 있었다. 시간은 한정적으로 주어진 상황에서 그 코드를 유지보수 해야된다면 리팩토링을 할 것인가? 아니면 요구사항 코드를 어떻게든 동작하도록 욱여넣을 것인가.. +> 리팩토링 한다면 이전에 동작하던 기능들이 사이드이펙트로 인해 동작하지 않을 수 있다. 그렇다고 구덩이를 보고 그냥 지나칠 것인가? 누군가는 밟고 넘어질 수 있다.. 그게 먼 미래의 나일수도 있다.. +> 요구사항 코드를 어떻게든 동작하게 만들고 주석만 달아놓는다면 오랫동안 쳐다보지 않을 확률이 높다.. +> 구덩이를 발견한 사람이 그 구덩이를 메우자.. 보이스카우트 규칙과 비슷 + +### 의도적으로 프로그래밍하기 +- 더 경험이 적은 프로그래머에게 코드를 자세히 설명할 수 있어야 된다. 그렇지 않다면 우연에 기대고 있을 확률이 있다. +> 자세히 설명한 적은 없었고 대부분 간단한 설명과 함께 참고했던 레퍼런스를 공유했었다. 경험이 적을 뿐 대부분 뛰어난 실력을 가지고 계셔서.. +- 자신도 잘 모르는 코드를 만들지 마라. 완전히 파악하지 못한 애플리케이션을 빌드하거나 이해하지 못한 기술을 사용하면 우연의 함정에 빠질 가능성이 높다. +> 가끔씩 마음 급해지면 동작만 했음 좋겠다는 식으로 코드 변경할 때가 있었다.. +- 계획을 세우고 그것을 바탕으로 진행하라. 머릿속에 있는 계획이든, 냅킨이나 화이트보드에 적어 놓은 계획이든 상관없다. +> 간단히 설계 후에 작업하자. +- 신뢰할 수 있는 것에만 기대라. 가정에 의존하지 말라. +> POC를 통해 가설 검증하기, 프로토타이핑을 통해 팀원들에게 좋은 신뢰를 얻을 수 있다 생각 +- 과거의 노예가 되지 말라. +> 언제나 리팩터링할 자세가 되어 있어야 함. 그 전에 일단 유지보수 하기 용이한 코드로 작성해놓자.. 그 당시 이렇게 코드 작성해야 할 이유가 있었다면 주석을 남겨놓기 + + +> **이게 왜 잘 돌아가지? 라고 생각이 든다면.. 그것은 우연이 아닐까 생각해봐야 된다.. 😱** + + +## Topic 39 알고리즘의 속도 + +### 최고라고 언제나 최고는 아니다 +가장 빠른 알고리즘이 언제나 좋은 알고리즘은 아니다. 입력값의 규모가 작다면 단순한 삽입 정렬도 퀵 정렬과 비슷한 성능을 냄 +그니까 '성급한 최적화' 조심하자. 어떤 알고리즘을 개선하느라 우리의 귀중한 시간을 투자하기 전에 그 알고리즘이 정말로 병목인지 먼저 확인하는게 좋다. + +> 코드 리뷰에서 흔히 일어나는 상황이라 생각한다. 이론적으로는 성능상 이점(수행시간 줄어듬)은 있긴한데.. 입력값의 규모가 작아서 눈에 띄는 이점은 없고 오히려 복잡도가 증가하는 경우가 더러 있다.. +> 이런 경우 많지 않나요 + +## Topic 40 리팩터링 + + +## Topic 41 테스트로 코딩하기 + +## Topic 42 속성 기반 테스트 + +## Topic 43 바깥에서는 안전에 주의하라 + +## Topic 44 이름 짓기 From 4852b2d2cc49032fbe6a92e364042ce968a9213d Mon Sep 17 00:00:00 2001 From: SangBeom Park Date: Mon, 2 Sep 2024 00:05:53 +0900 Subject: [PATCH 2/2] =?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) +