변수미

7장/변수미.md

@@ -0,0 +1,93 @@
+### 파충류의 뇌에 귀 기울이기
+
+두려움을 느끼는, 이런 문제에는 두 가지 원인이 있다.
+
+- 첫 번째 원인은 **파충류의 뇌가 여러분에게 무언가 할 말이 있어서**다.
+  어떤 것이 문제라고 정확하게 짚지는 못하더라도, 시간을 좀 주면 여러분의 의심은 아마도 좀 더 실체가 있고 대응책을 생각할 수 있는 무엇으로 구체화될 것이다.
+- 두 번째 이유는 그저 실수할까 봐 두려운 것일 수 있다.
+
+그리고 수년 만에 우리는 괜찮은 자기기만 방법을 찾아냈다. 바로 무언가를 프로토타이핑해야 한다고 자신에게 말하는 것이다.
+
+- 포스트잇에 “프로토타이핑 중”이라고 써서 모니터 옆에 붙여라
+- 프로토타이핑은 원래 실패한다고 자신에게 상기시켜라.
+- 텅 빈 에디터 화면에 여러분이 배우고 싶은 것 혹은 하고 싶은 것을 한 문장의 주석으로 표현해 보라
+- 코딩을 시작하라
+- 의심이 들기 시작하면 포스트잇을 보라
+
+### 우연에 맡기는 프로그래밍
+
+우리는 우연에 맡기는 프로그래밍, 곧 행운과 우연한 성공에 의존하는 프로그래밍을 하지 않아야 한다.
+대신 **‘의도적으로 프로그래밍’** 해야 한다.
+
+단순히 코드가 지금 작성된 방식이 그렇기 때문에 생기는 우연한 일들이 있다. 이런 우연에 기대다 보면 결국 문서화되지 않은 에러나 예외적인 경우의 동작에 의존하게 되고 만다.
+
+> “이제 돌아는 가니까, 그대로 놔두는 편이 더 나을 거야…"
+> 이거 내가 맨날 하는 말인데... ...ㅎㅎ
+
+의도적으로 프로그래밍하라.
+
+- **언제나 여러분이 지금 무엇을 하고 있는지 알아야 한다**
+- **자신도 잘 모르는 코드를 만들지 말라**
+- 계획을 세우고 그것을 바탕으로 진행하라
+- 신뢰할 수 있는 것에만 기대라
+- 가정을 기록으로 남겨라
+- 코드뿐 아니라 여러분이 세운 가정도 테스트해 보아야 한다
+- 노력을 기울일 대상의 우선순위를 정하라
+- 과거의 노예가 되지 말라
+
+### 알고리즘의 속도
+
+실용주의 프로그래머가 거의 날마다 하는 또 다른 종류의 추정이 있다.
+바로 알고리즘이 사용하는 자원, 곧 시간, 프로세서, 메모리 등을 추정하는 것이다.
+
+=> 결론, 상황에 맞게 사용해라
+
+### 리팩터링
+
+**밖으로 드러나는 동작은 그대로 유지**한 채 내부 구조를 변경함으로써 이미 존재하는 코드를 재구성하는 체계적 기법
+
+> 밖으로 드러나는 동작은 그대로 유지되어야한다는게 제일 핵심, 핵심이네요
+
+마틴 파울러는 손해 보는 일이 없도록 리팩터링 하는 방법에 대하여 몇 가지 간단한 조언을 해 주었다.
+
+- 리팩터링과 기능 추가를 동시에 하지 말라
+- 리팩터링을 시작하기 전 든든한 테스트가 있는지 먼저 확인하라
+- 단계를 작게 나누어서 신중하게 작업하라
+
+> 리팩터링 작업을 최근에 종종 하고있는데, 명심하고 리팩터링을 해야겠다는 생각이 드네요
+
+### 테스트로 코딩하기
+
+다른 코드와 긴밀하게 결합된 함수나 메서드는 테스트하기 힘들다.
+
+> 테스트 하기 쉬운 함수를 만드는 것이 목표! 그런데 테스트 코드에 대해 고민할 시간이 없네용..
+
+“코끼리를 먹는 방법은 ?”이라는 해묵은 농담이 있다. 답은 “한 번에 한입씩”이고,
+이는 TDD의 장점으로 흔히 언급되곤 한다.
+전체 문제를 완전히 파악하기 힘들 때 한 번에 테스트 하나씩 작은 단계들을 밟는 것이다.
+
+> 저는 결국 "테스트를 하지 않음"을 어쩔 수 없이 선택하게 되는것 같아요 ㅜㅜ
+
+### 속성 기반 테스트
+
+(\_\_\_)pass~
+
+### 바깥에서는 안전에 주의하라
+
+코드를 완성한 이후 코드가 잘못될 수 있는 경우를 찾아봐라. 그리고 각 경우에 대한 단위 테스트를 추가해야한다
+하지만 이렇게 내부 오류를 찾는것만으로는 불충분하다. 외부의 공격에도 대비해야한다
+
+> 가장 중요한 부분은,, 암호학 부분인것 같은데
+
+"암호화의 첫번째이자 가장 중요한 규칙은 **절대 직접 만들지말라**는 것이다. 암호의 세계에서는 사소한 오류가 전체 암호화를 무용지물로 만들 수 있다. 이미 만들어진 프레임워크를 사용하라. (자주 업데이트 되는)"
+
+> 위의 말이 참 중요한것 같아요. 잘 만든거를 써라~
+
+### 이름 짓기
+
+- 코드에서 하는 역할에 따라 이름을 지어야한다.
+- 팀의 모든 사람이 각 단어의 뜻을 알고 일관성 있게 사용해야한다.
+  팀에서 특별한 의미가 있는 단어를 모은 사전을 만들 수도 있다.
+- camelCase나 snake_case도 해당 분야의 문화를 존중해야한다.
+- 이름 바꾸기는 어렵다. 좋은 이름을 짓더라도, 모든 것은 결국 변한다.
+  안좋은 이름이 발견되었다면 즉시 바꿔라. 바꾸기 어렵다면 더 심각한 문제니 그것부터 개선해라.