[박상범] 7장: 코딩하는 동안

7장/상범.md

@@ -0,0 +1,128 @@
+# 7장 코딩하는 동안
+
+코딩은 기계적인 작업이 아니다.
+코딩할 때는 매 순간 결정을 내려야 하는데, 프로그램이 정확하게 생산적으로 작동하며 사려깊은 생각과 판단으로 결정을 내려야 한다.
+
+
+## Topic 37 파충류의 뇌에 귀 기울이기
+
+직감이 여러분의 역량에 일조하도록 하라.
+직감에 귀를 기울여라.
+
+> 주로 경험 기반으로 말하는 경향이 있어 공감이 됐다.
+
+## Topic 38 우연에 맡기는 프로그래밍
+
+개발자인 우리들 역시 지뢰밭에서 일한다.
+하루에도 수백 개가 넘는 함점이 우리가 빠지기를 기다리고 있다..
+
+> 운 좋게 동작하고 있는 코드가 있었다. 시간은 한정적으로 주어진 상황에서 그 코드를 유지보수 해야된다면 리팩토링을 할 것인가? 아니면 요구사항 코드를 어떻게든 동작하도록 욱여넣을 것인가..  
+> 리팩토링 한다면 이전에 동작하던 기능들이 사이드이펙트로 인해 동작하지 않을 수 있다. 그렇다고 구덩이를 보고 그냥 지나칠 것인가? 누군가는 밟고 넘어질 수 있다.. 그게 먼 미래의 나일수도 있다..  
+> 요구사항 코드를 어떻게든 동작하게 만들고 주석만 달아놓는다면 오랫동안 쳐다보지 않을 확률이 높다..  
+> 구덩이를 발견한 사람이 그 구덩이를 메우자.. 보이스카우트 규칙과 비슷
+
+### 의도적으로 프로그래밍하기
+- 더 경험이 적은 프로그래머에게 코드를 자세히 설명할 수 있어야 된다. 그렇지 않다면 우연에 기대고 있을 확률이 있다.
+> 자세히 설명한 적은 없었고 대부분 간단한 설명과 함께 참고했던 레퍼런스를 공유했었다. 경험이 적을 뿐 대부분 뛰어난 실력을 가지고 계셔서..
+- 자신도 잘 모르는 코드를 만들지 마라. 완전히 파악하지 못한 애플리케이션을 빌드하거나 이해하지 못한 기술을 사용하면 우연의 함정에 빠질 가능성이 높다.
+> 가끔씩 마음 급해지면 동작만 했음 좋겠다는 식으로 코드 변경할 때가 있었다..
+- 계획을 세우고 그것을 바탕으로 진행하라. 머릿속에 있는 계획이든, 냅킨이나 화이트보드에 적어 놓은 계획이든 상관없다.
+> 간단히 설계 후에 작업하자.
+- 신뢰할 수 있는 것에만 기대라. 가정에 의존하지 말라.
+> POC를 통해 가설 검증하기, 프로토타이핑을 통해 팀원들에게 좋은 신뢰를 얻을 수 있다 생각
+- 과거의 노예가 되지 말라.
+> 언제나 리팩터링할 자세가 되어 있어야 함. 그 전에 일단 유지보수 하기 용이한 코드로 작성해놓자.. 그 당시 이렇게 코드 작성해야 할 이유가 있었다면 주석을 남겨놓기
+
+
+> **이게 왜 잘 돌아가지? 라고 생각이 든다면.. 그것은 우연이 아닐까 생각해봐야 된다.. 😱**
+
+
+## Topic 39 알고리즘의 속도
+
+### 최고라고 언제나 최고는 아니다
+가장 빠른 알고리즘이 언제나 좋은 알고리즘은 아니다. 입력값의 규모가 작다면 단순한 삽입 정렬도 퀵 정렬과 비슷한 성능을 냄
+그니까 '성급한 최적화' 조심하자. 어떤 알고리즘을 개선하느라 우리의 귀중한 시간을 투자하기 전에 그 알고리즘이 정말로 병목인지 먼저 확인하는게 좋다.
+
+> 코드 리뷰에서 흔히 일어나는 상황이라 생각한다. 이론적으로는 성능상 이점(수행시간 줄어듬)은 있긴한데.. 입력값의 규모가 작아서 눈에 띄는 이점은 없고 오히려 복잡도가 증가하는 경우가 더러 있다 (이런 경우 있지 않나요..?)
+
+## 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)
+