[실용주의 프로그래머] TIL (2022.04.02) 7장. 코딩하는 동안

실용주의 프로그래머 (The Pragmatic Programmer)

오늘 TIL 3줄 요약

• 알고리즘
• 리팩터링
• 테스트, 설계, 코딩 이 모든 것이 프로그래밍이다.

TIL (Today I Learned) 날짜

2022.04.02

오늘 읽은 범위

7장. 코딩하는 동안

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

대부분은 반복적인 일이지만 정신을 늘 기민하게 유지하면 재앙을 막을 수 있다. (p.275)

백지의 공포 (새로운 시작을 미루는 것)의 해결방법
-> 여러분의 본능, 여러분의 무의식, 파충류의 뇌에게 귀를 기울이고 또 기울이기 바란다. (p.278)

그래도 안되면, 프로토타이핑
이미 존재하는 코드 위에서 작업하고 있어서 기존 코드 때문에 문제 해결이 여의치 않다면, 기존 코드를 잠시 다른 곳으로 밀어 두고 비슷한 것을 대신 프로토타이핑으로 만들어라

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

가정하지 마라. 증명하라. (p.286)

잘 되는 듯한 답을 찾는 것과 올바른 답을 찾는 것은 다르다. (p.287)

확고한 사실에 근거하지 않은 가정은 어떤 프로젝트에서든 재앙의 근원이 된다. (p.287)

• 언제나 여러분이 지금 무엇을 하고 있는지 알아야한다.
• 더 경험이 적은 프로그래머에게 코드를 상세히 설명할 수 있는가?
• 자신도 잘 모르는 코드를 만들지 말라.
• 계획을 세우고 그것을 바탕으로 진행하라.
• 신뢰할 수 있는 것에만 기대라.
• 가정을 기록으로 남겨라.
• 코드뿐 아니라 여러분이 세운 가정도 테스트해 보아야한다. 가정을 시험할 수 있는 단정문을 작성하라.
• 노력을 기울일 대상의 우선순위를 정하라. 중요한 것에 먼저 시간을 투자하라.
• 과거의 노예가 되지 말라.
  (p.299-289)

---

대문자 $O$ 표기법 Big $O$ notation
근삿값을 다루는 수학적 방법으로 $O()$와 같이 표기한다.
어떤 정렬 루틴이 원소 $n$개를 정렬하는데 $O(n^2)$ 시간이 걸린다고 말할 때, 이는 그저 최악의 경우에 걸리는 시간이 $n$의 제곱에 비례하여 늘어난다고 얘기하는 것이다.
(p.292)

-	알고리즘 차수	예시
단순 반복문	$O(n)$	소진 탐색, 배열에서 최대값 찾기, 체크섬 생성하기 등
중첩 반복문	$O(n^2)$	버블정렬, 정렬알고리즘
반씩 자르기	$O(lgn)$	이진검색, 이진트리의 탐색, 정수의 2진수 표현에서 첫 번째인 1비트를 찾는 문제 등
분할 정복	$O(nlgn)$	퀵 정렬
조합적		순열, 여행 외판원 문제, 상자에 물건을 최적으로 집어넣는 문제 등

(p.296-296)

정확하게 시간을 재는 일이 어렵다면 '코드 프로파일러'를 사용하여 알고리즘이 돌아갈 때 각 단계의 실행 횟수를 센 다음 입력값 크기별로 실행 횟수를 그래프로 그려보라. (p.297)

---

소프트웨어 개발은 건축보다 정원 가꾸기에 더 가깝다.

무엇인가 잘못되었다는 생각이 들 때가 있을 것이다. 주저하지 말고 변경하라. 언제나 바로 지금이 최적기다. 코드를 리팩터링할 이유는 아주 많다. (p.302)

• 중복
• 직교적이지 않은 설계
• 더 이상 유효하지 않은 지식
• 사용 사례
• 성능
• 테스트 통과
  (p.303)

리펙터링에 대한 조언

• 리페터링과 기능 추가를 동시에 하지말라.
• 테스트가 있는지 확인하라.
• 단계를 작게 나누어서 신중하게 작업하라.
  (p.305)

---

테스트가 코드의 첫 번째 사용자다. 테스트는 우리의 코딩을 인도하는 필수 피드백이다. (p.309)

무언가 테스트하려면 그것을 이해해야만 한다.

테스트 주도 개발 Test driven development TDD

• 추가하고 싶은 작은 기능 하나를 결정한다.
• 그 기능이 구현되었을 때 통과하게 될 테스트를 하나 작성한다.
• 테스트를 실행한다. 다른 테스트는 통과하고 방금 추가한 테스트 딱 하나만 실패해야 한다.
• 실패하는 테스트를 통과시킬 수 있는 최소한의 코드만 작성한다. 그리고 모든 테스트가 통과하는지 확인
• 코드를 리펙터링하고 개선할 부분이 있는지 확인한다. 개선한 후에도 통과하는지 확인한다.

하지만, 테스트 통과에 중독되는 것은 주의하라.
(p.311)

하드웨어와 마찬가지로 소프트웨어를 만들 땐 맨 처음부터 테스트가 가능하도록 만들고, 코드들을 서로 연결하기 전에 코드를 하나하나 철저하게 테스트해야만 한다. (p.314)

---

기본 보안 원칙

• 공격 표면을 최소화하라.
• 최소 권한 원칙
• 안전한 기본값
• 민감 정보를 암호화하라.
• 보안 업데이트를 적용하라.
  (p.332)

암호화 Cryptography 에 있어서 가장 중요한 규칙
절대 직접 만들지 말라!
(p.340)

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

이번 장은 클린코드와도 많은 부분이 겹치고, 정말 중요한 것 같다!

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

Topic 39. 알고리즘의 속도는 다시 정리해 볼 필요가 있을 것 같다.

Donald Knuth - The Art of Computer Programming

오늘 읽은 다른사람의 TIL