제 7장 코딩하는 동안

" 모든 코드를 비판적인 시각으로 바라본다.
자기 자신의 코드도 예외가 아니다. "

TIL (Today I Learn)

• Assignment 12
• 2022-04-01 ~ 2022-04-02

---

오늘 읽은 범위

• 7장 코딩하는 동안
  • Topic 37 파충류의 뇌에 귀 기울이기
  • Topic 38 우연에 맡기는 프로그래밍
  • Topic 39 알고리즘의 속도
  • Topic 40 리팩터링
  • Topic 41 테스트로 코딩하기
  • Topic 42 속성 기반 테스트
  • Topic 43 바깥에서는 안전에 주의하라
  • Topic 44 이름 짓기

 

---

3줄 요약

• 여러문의 내면의 파충류에게 귀 기울여라.
• 하던 일을 멈추고 그 느낌을 분석하라.

---

책에서 기억하고 싶은 내용을 써보세요

코딩할 때는 매 순간 결정을 내려야 하는데, 프로그램이 정확하게 생산적으로 작동하면서 천수를 누리도록 하려면 사려 깊은 생각과 판단으로 결정을 내려야 한다.

 

 

 

Topic 37 파충류의 뇌에 귀 기울이기

" 첫 단계는 산책과 수다, 그리고 휴식이다 "

• 본능이란 우리 뇌의 무의식 속에 채워져 있는 패턴에 대한 단순한 반응이다. 일부는 선천적이고, 나머지는 반복을 통해 습득한다.
  • 모든 본능에는 공통점이 있다. 바로 말로 표현할 수 없다는 것, 생각이 아니라 느낌이라는 점이다. 
  • 해결책은 일단 본능이 반응하고 있음을 인지하는 것이다. 그리고 왜 그런 느낌이 드는지 알아내야 한다.
• 어떤 작업을 앞두고 마음속에 의심이 계속 남아 있거나 왠지 꺼림칙하다면, 여러분의 경험이 여러분에게 말을 거는 중일지도 모른다. 그 느낌을 따라라. 
  
  • 일단, 하고 있는 일을 멈춰라.  생각이 저절로 여러분의 뇌 층층이 스며들도록 놔둬라. 
  • 잘 안되면 문제를 표면으로 끄집어내 보라. 작성하는 코드에 대한 그림을 그려보라. 동료에게 설명해 보라. (고무 오리도 괜찮다)
  • 여전히 막혀 있을 수도있다.  여러분의 뇌에게 여러분이 하려는 일은 별 문제가 없다고 알려줘야 한다. 프로토타이핑을 하면 된다

 

프로토타이핑 하는 법

1. 포스트잇에 “프로토타이핑 중”이라고 써서 모니터 옆에 붙여라.
2. 프로토타이핑은 원래 실패한다고 자신에게 상기시켜라. 실패하지 않더라
도 프로토타입은 버리는 것이라는 점도 함께 상기시켜야 한다. 프로토타이핑으로 손해 볼 일은 없다.
3. 텅 빈 에디터 화면에 여러분이 배우고 싶은 것 혹은 하고 싶은 것을 한 문장의 주석으로 표현해 보라.
4. 코딩을 시작하라.

의심이 들기 시작하면 포스트잇을 보라.

 

 

 

Topic 38 우연에 맡기는 프로그래밍

 

" 왜 코드가 망가졌는지 모르는 까닭은
애초에 코드가 왜 잘 돌아가는지도 몰랐기 때문이다. "

 

• 다른 사람이 호출할 코드를 작성하고 있다면 모듈화를 잘하는 것, 그리고 잘 문서화한 적은 수의 인터페이스 아래에 구현을 숨기는 것 같은 기본 원칙들이 모두 도움이 된다.
• 다른 루틴을 호출할 때도 문서화된 동작에만 의존하라. 어떤 이유로든 그럴 수 없다면 추측을 문서로 상세히 남겨라.
• 비슷하다고 괜찮을 리는 없다
• 가정하지 말라. 증명하라.
• 의도적으로 프로그래밍해야 한다.
  • 언제나 여러분이 지금 무엇을 하고 있는지 알아야 한다.
  • 자신도 잘 모르는 코드를 만들지 말라.
  • 획을 세우고 그것을 바탕으로 진행하라. 
  • 가정을 기록으로 남겨라.
    • 가정도 테스트해 보아야 한다.
  • 추측만 하지 말고 실제로 시험해 보라. 여러분의 가정을 시험할 수 있는 단정문을 작성하라
• 노력을 기울일 대상의 우선순위를 정하라. 
• 과거의 노예가 되지 말라. 
  • 기존 코드가 앞으로 짤 코드를 지배하도록 놓아두지 말라. 
  • 더는 적절한 코드가 아니다 싶으면 어떤 코드라도 교체할 수 있다. 

 

 

Topic 39 알고리즘의 속도   

* 책에서의 대문자 O가 아닌 빅오 표기법이라 표기함

 

• 빅오(O) 표기법
  • 우리가 측정하는 값―시간, 메모리 등―의 상한을 기술하는 표기법이다.
  • 수행 시간이든 메모리든, 아니면 다른 무엇을 나타내든 실제 숫자를 알려주지 않는다. 그저 입력의 크기가 바뀜에 따라 이 값이 어떻게 바뀔지를 알려줄 뿐이다
  • 시간에만 국한되지 않는다. 알고리즘이 사용하는 어떤 리소스든 O() 표기법으로 표현할 수 있다. 
• 사용하는 알고리즘의 차수를 추정하라.
• O(n^2) 알고리즘이 있다면 분할 정복을 사용하여 O(nlgn)으로 줄일 수 없는지 시도해 보라. 
•   예시) 분할 정복. 입력 데이터를 둘로 나눠서 각각 독립적으로 작업한 다음, 결과를 합치는 알고리즘은 O(nlgn)일 수 있다. 퀵 정렬quicksort이 전형적인 예로, 퀵 정렬은 데이터를 반으로 나누고 각 반쪽에서 재귀적으로 정렬을 수행한다.이미 정렬된 입력값이 들어올 때는 성능이 떨어지기 때문에 엄밀하게는O(n^2)이지만, 퀵 정렬의 평균 수행 시간은 O(nlgn)이다.
• 이론적 요인과 실무적 요인을 모두 고려하려고 노력하라. 
• 실제 서비스에서 실제 데이터로 돌아가는 코드의 수행 시간만이 정말로 의미 있는 수치다.
  • 즉, 여러분의 추정을 테스트하라
• ‘성급한 최적화premature optimization’를 조심하라.
  • 어떤 알고리즘을 개선하느라 여러분의 귀중한 시간을 투자하기 전에 그 알고리즘이 정말로 병목인지 먼저 확인하는 것이 좋다.

 

 

Topic 40 리팩터링

// 추가 업데이트.....

 

 

---

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• 실제로 무언가 문제에 대해 고민하다가 동료에게 의견을 구하기 위해 질문을 정리하는 과정에서 스스로 깨닫는 경우가 꽤 많았다. 메신저로 질문을 던지고 부연 설명하는 과정에서 혼자 깨닫고 독백하게 되는 그 우스운 상황이란...
• 문서화의 중요성을 많이 느낀다. 진행하고 있는 프로젝트에서 API 열어두고 외부 호출을 받아들이는 과정에 유관 부서와 협의하고 기능을 명확히 끊어내는 부분이 생각보다 까다롭더라. 비동기 프로그래밍은 어려워...
• 리팩토링을 하다보면 가장 고민되는 순간이 기존 코드를 재활용 할지 아님 새로운 로직을 대체할지 였던 것 같다. 한 번 건드리면 일이 너무 커지는 부분이라 순간 타협을 해버릴까 유혹도 있지만 싹 갈아엎기 시작해서 지금은 많이 안정되게 자리 잡았다. 이전 코드에 맞추기 위해 새롭게 잘 짜인 코드를 수정하는 일은 없게 해야할 것이다.

 

---

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요

• O(lgn) 로그 시간에서 '로그'를 왜 log n 이 아니라 lgn 으로 표기하는 걸까. 그새 표기법이 바뀌었는지...