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

DAY 15, 16 오늘 읽은 범위: 7장. 코딩하는 동안

📚 책에서 기억하고 싶은 내용?

---

• 적극적으로 자기 코드에 대해 생각하지 않는 프로그래머는 우연에 맡기는 프로그래밍을 하는 것이다.

여러분 내면의 파충류에게 귀 기울여라.

• 잠깐 일에서 손을 떼고 프로토타입을 만들어보자.

우연에 맡기는 프로그래밍을 하지 말라.

• 다른 루틴을 호출할 때도 문서화된 동작에만 의존하라. 어떤 이유로든 그럴 수 없다면 추측을 문서로 상세히 남겨라.
• 가정하지 말라, 증명하라.
• 체크해봐야 할 사안들
  1. 다른 프로그래머에게 코드를 상세히 설명할 수 있는가?
  2. 자시도 잘 모르는 코드를 만들지 말라.
  3. 계획을 세우고 그것을 바탕으로 진행하라.
  4. 신뢰할 수 있는 것에 기대라. 가정의 의존하지 말라.
  5. 가정을 기록으로 남겨라.
  6. 추측하지 말라고 실제로 시험해 보라.
  7. 우선순위를 정하라.
  8. 기존 코드가 앞으로 짤 코드를 지배하도록 놓아두지 말라. 적절한 코드가 아니라면 언제라도 교제할 수 있어야 한다. 리팩토링

사용하는 알고리즘의 차수를 추정하라.

• 실용주의 프로그래머는 날마다 알고리즘이 사용하는 자원, 곧 시간, 프로세서, 메모리 등을 추정한다.
• 알고리즘은 대부분 선형적이지 않다.
• 대문자 O 표기법
  O(n)은 이 함수가 실행되는데 걸리는 시간의 최대값이 n보다 더 빨리 늘어나지 않는다는 뜻이다.

• 코드 프로파일러를 사용하여 알고리즘이 돌아갈 때 각 단계의 실행 횟수를 센 다음 입력값 크기별 실행 횟수를 그래프로 그려 보라.
• 성급한 최적화를 조심하라. 입력 데이터의 규모가 작으면 오히려 데이터를 준비하는 데 걸리는 시간이 더 길어질 수도 있다.

일찍 리팩터링하고, 자주 리팩터링하라.

• SW개발은 정원 가꾸기에 가까운 유기적인 활동이다.
• 리팩터링이란 밖으로 드러나는 동작은 그대로 유지한 채 내부 구조를 변경함으로써 이미 존재하는 코드를 재구성하는 체계적인 기법.
• 리팩터링 하는 방법에 대한 조언
  1. 리팩터링과 기능 추가를 동시에 하지 말라.
  2. 리팩터링을 시작하기 전 든든한 테스트가 있는지 먼저 확인하라. 할 수 있는 한 자주 테스트를 돌려보라.
  3. 단계를 작게 나누어서 신중하게 작업하라. 클래스의 필드 하나를 다른 클래스로 옮기기, 메서드 하나 쪼개기, 변수명 하나 바꾸기 같이 작은 단위로 작업해야 한다.

테스트는 버그를 찾기 위한 것이 아니다.

• 테스트의 주요한 이득이 테스트를 실행할 때가 아니라 테스트에 대해 생각하고, 테스트를 작성할 때 생긴다고 믿는다.
• 테스트가 코드의 첫 번째 사용자다.
• 테스트 주도 개발 TDD
  1. 추가하고 싶은 작은 기능 하나를 결정한다.
  2. 그 기능이 구현되었을 때 통과하게 될 테스트를 하나 작성한다.
  3. 테스트를 실행한다. 다른 테스트는 통과하고 방금 추가한 테스트 딱 하나만 실패해야 한다.
  4. 실패하는 테스트를 통과시킬 수 있는 최소한의 코드만 작성한다.
  5. 코드를 리팩터링한다.
• TDD의 노예가 되진 말자. ← 중복X, 100% 통과X
• 상향식이나 하향식이 아니라 끝에서 끝까지 만들어라.
• 단위테스트 = 계약을 잘 지키는지 보는 테스트
  임시테스트도 단위 테스트에 합류시켜라.

속성기반 테스크로 가정을 검증하라.

def order(warehouse, item, quantity):
    if warehouse.in_stock(item, quantity):
    	warehouse.take_from_stock(item, quantity)
        return ("완료", item, quantity)
    else:
    	return ("재고 없음", item, quantity)

• 문제가 발생하는 상황에 집중하게 해준다.
• 단위 테스트가 '희귀 테스트' 역할을 한다.

실용주의 프로그래머는 건전한 정도의 편집증을 갖고 있다.

• 공격 표면을 최소화하라.
  단순하고 작은 코드가 더 낫다.
  외부의 데이터를 절대 신뢰하지 마라.
  인증이 없는 서비스는 전 세계 누구든지 호출할 수 있고, DoS가 가능해진다.
  인증 받은 사용자의 수를 언제나 최소로 유지하라.
  디버깅 정보는 공격 매개체다.
  ▶ 단순함을 유지하고 공격표면을 최소화하라.
• 최소 권한 원칙
  최소 권한을 제일 짧게 부여하자.
  시스템의 모든 프로그램과 모든 특수 권한 사용자는 과업을 마치기 위해 필요한 최소한의 권한만을 사용하여 운용해야 한다.
• 안전한 기본값
• 민감 정보를 암호화하라
• 보안 업데이트를 적용하라

이름을 잘 지어라. 필요하면 이름을 바꿔라.

• 그렇지 않으면 팀에 새로운 사람이 올 때마다 시치미를 뚝 떼고 getData가 사실은 데이터를 파일에 쓴다는 것을 설명해야 할 것이다.

 

🤩 오늘 읽은 소감?

---

이 책을 읽으면서 가장 와닿고 기억해야할 부분이 바로 이 챕터인 것 같다는 생각이 들었다. 테스트코드 작성에 대한 부분은 현재 공부하고 있는 부분과도 겹쳐서 그런 것이 아닐까 싶다.

 

잘못된 비밀번호 사례를 읽었을 때 가장 의외라는 생각이 들었다.

까다로운 비밀번호 정책은 오히려 보안 수준을 낮춘다는 말이었다.
당신의 첫 번째 애완동물 이름은 무엇인가요 같은 특정 정보를 물어보지 말고, 다른 이유없이 일정 기간이 지났다는 이유만으로 사용자에게 비밀번호를 바꾸라고 요구하지 말라는 글이다.

그럼 대부분의 웹에서 사용하는 비밀번호 정책이 잘못되었다는 말인가 생각해보게 되는 글이었다. 내 지난 프로젝트에서도 기간 지남에 따른 비밀번호 변경을 유도하는 것을 만든 적이 있었다.

이런 인위적인 제약을 걸면 무작위도를 낮추고 나쁜 비밀번호 습관을 부추겨서 사용자 계정 탈취를 도와주는 꼴이 될 뿐이라고 한다.

 

❓ 궁금한 점이나 잘 이해되지 않는 내용

---

• 로버드 세지윅, 도널드 커누스의 알고리즘 서적
  저자가 서재에 놓고 반드시 읽기를 추천한다는 책이니 한 번 기회가 있을 때 읽어봐야 겠다.
• 테스트코드와 관련해서는 지금 따로 학습중인 내용을 공부하고 다시 보면 좋을 것 같다!

 

 

실용주의 프로그래머 - 교보문고