📚노마드 개발자 북클럽 '실용주의 프로그래머'(1기) 과제#12

📌 ASSIGNMENT 12. 22.04.01 FRI - 04.02 SAT (11일차 ‣ 퀴즈)

 

📎 오늘 TIL 3줄 요약

• 코드를 작성할 땐 우연에 의존하지 말고 왜 이렇게 작동하는지 끊임없이 생각해야 한다.
• 외부인의 시선으로 바라보고 테스트가 주도하는 개발을 해야 한다.
• 외부에서 들어오는 공격에 대해서도 방어를 해야 한다.

 

🔖 오늘 읽은 범위

7장. 코딩하는 동안

 

 

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

• 적극적으로 자기 코드에 대해 생각하지 않는 프로그래머는 우연에 맡기는 프로그래밍을 하는 것이다. 코드가 작동하긴 하지만 왜 그렇게 작동하는지 설명은 못한다.
• 실용주의 프로그래머는 모든 코드를 비판적인 시각으로 바라본다. 자기 자신의 코드도 예외가 아니다. 우리는 우리가 만든 프로그램과 설계에서 언제나 개선할 여지를 찾아낸다.
• 테스트의 긍정적인 효과는 대부분 테스트를 수행할 때 나타나는 것이 아니라, 테스트에 대하여 생각할 때 그리고 테스트를 작성할 때 나타난다는 것이다.
• 백지의 공포
  • 파충류의 뇌(본능)가 여러분에게 무언가 할 말이 있는 것
  • 그저 실수할까 봐 두려운 것, 가면 증후군의 요소 또한 있을 것 (자신이 가진 능력이 과대평가를 받앗고 자신은 자격이 없는 사람이라고 생각하면서 불안해 하는 것)
• 코딩이 정말 진전이 없는 날이 있다. 이 땐 어쩌면 구조나 설계가 틀렸을 수도 있고, 엉뚱한 문제를 붙들고 있는 걸 수도 있다. 여러분의 뇌가 정리를 좀 할 수 있도록 약간의 시간과 공간을 확보하라. 
• 잘못된 코드가 있는 채로 화면이 잘 그려지더라도 잘못된 코드는 제거를 해야한다.
• 다른 사람이 호출할 코드를 작성하고 있다면 모듈화를 잘 해야한다.
• 구현은 잘 문서화한 적은 수의 인터페이스 아래에 숨겨야 한다.
• 인터넷 검색으로 찾은 첫 번째 답에서 코드를 복사해 올 때 여러분과 동일한 상황이라고 확신하는가? 아니면 의미는 신경 쓰지 않고 그냥 따라 하는 '화물 숭배' 코드를 만들고 있나? 잘 되는 듯한 답을 찾는 것과 올바른 답을 찾는 것은 다르다.
• 테스트는 가짜 원인과 우연한 결과로 가득 찬 영역이다. X의 원인은 Y라고 가정하기 쉽다. 가정하지 말라. 증명하라.
• 알고리즘의 속도
  • 일반적으로 입력의 크기는 알고리즘에 영향을 준다. 입력의 크기가 클수록 알고리즘의 수행 시간이 길어지거나 사용하는 메모리 양이 늘어난다. 하지만 중요한 알고리즘은 대부분 선형적이지 않다.
  • 가장 빠른 알고리즘이 언제나 가장 좋은 알고리즘은 아니다.
  • '성급한 최적화(premature optimization)'를 조심하라. 언제나 어떤 알고리즘을 개선하느라 여러분의 귀중한 시간을 투자하기 전에 그 알고리즘이 정말로 병목인지 먼저 확인하는 것이 좋다.
  • O() 표기법에서 O는 '...차수로(order of)'를 뜻한다.

    O(1)	상수(배열의 원소 접근, 단순 명령문)
    O(lg n)	로그(이진 검색, 로그의 밑은 중요치 않다 => O(log n)과 동일)
    O(n)	선형(순차 검색)
    O(n lg n)	선형보다는 좋지 않지만, 그래도 그렇게 많이 나쁘지는 않음. (퀵 정렬과 힙 정렬의 평균 수행 시간)
    O(n^2)	제곱(선택 정렬과 삽입 정렬)
    O(n^3)	세제곱(두 n x n 행렬의 곱)
    O(C^n)	지수(여행하는 외판원 문제, 집합 분할 문제)

 

• 리팩터링은 잡초 제거나 갈퀴질처럼 위험하지 않는 작은 단계들을 밟는 일상 활동이다. 무질서하게 대규모로 코드를 다시 쓰는 것이 아니라, 정확한 목적을 가지고 정밀하게 접근하는 활동이다. 그래서 코드를 바꾸기 쉽게 유지하는 것이다.
• 코드를 리팩터링할 이유 - 중복, 직교적이지 않은 설계, 더 이상 유효하지 않은 지식, 사용 사례(실사용을 하며 생기는 개선 사항), 성능 개선, 테스트 통과
• 리팩터링을 하는 방법
  1. 리팩터링과 기능 추가를 동시에 하지 말라.
  2. 리팩터링을 시작하기 전 든든한 테스트가 있는지 먼저 확인하라.
  3. 단계를 작게 나누어서 신중하게 작업하라.
• 테스트 주도 개발(TDD test-driven development / test-first development)
  • 우리의 메서드의 테스트 작성에 대해 생각함으로써 코드의 작성자가 아니라 사용자인 것처럼 메서드를 외부의 시선으로 보게 되었다. 테스트가 코드의 첫 번째 사용자다.
  • 무언가를 테스트하기 좋게 만들면 결합도도 낮아진다.
  • 테스트 주도 개발 방법 
    1. 추가하고 싶은 작은 기능 하나를 결정한다.
    2. 그 기능이 구현되었을 때 통과하게 될 테스트를 하나 작성한다.
    3. 테스트를 실행한다. 다른 테스트는 통과하고 방금 추가한 테스트 딱 하나만 실패해야 한다.
    4. 실패하는 테스트를 통과시킬 수 있는 최소한의 코드만 작성한다. 그리고 이제는 모든 테스트가 통과하는지 확인한다.
    5. 코드를 리팩터링한다. 방금 작성한 테스트나 함수를 개선할 수 있는 부분이 없는지 살펴본다. 개선한 후에도 테스트가 계속 통과하는지 확인한다.
• 회귀 테스트(regression testing) - 동일한 테스트를 코드 수정 후 다시 돌려보는 것
• 속성 기반 테스트(property-based testing) (속성 - 코드에 존재하는 계약과 불변식(함수 실행 전후로 계속 어떤 부분의 상태에 대하여 참이 되는 조건)을 뭉뚱그려서 부르는 것)
  
  • 장점 - 속성 기반 테스트가 강력한 까닭은 그저 입력을 생성하는 규칙과 출력을 검증하는 단정문만 설정한 채 제멋대로 작동하도록 놔두기 때문
  • 단점 - 정확히 무엇이 실패했는지 찾아내기 까다로울 수도 있다는 것. 속성 기반 테스트가 실패했다면 테스트 함수가 어떤 매개 변수를 사용했는지 알아낸 다음 그 값을 이용하여 별도의 단위 테스트를 정식으로 추가하는 것이 좋다. 이 단위 테스트는 하위의 두가지 역할을 한다.
    • 속성 기반 테스트의 여러 가지 다른 수행 결과와 상관없이 문제가 발생하는 상황에 집중할 수 있게 해 준다
    • 단위 테스트가 회귀 테스트 역할을 한다
• 외부 보안
  • 공격 표면을 최소화하라 - 단순하고 작은 코드가 더 낫다. 코드가 적으면 버그도 적고, 심각한 보안 구멍을 만들 확률도 줄어든다. 
  • 최소 권한 원칙 - 최소한의 권한만을 꼭 필요한 시간만큼만 제일 짧게 부여하라
  • 안전한 기본값 - 사용자의 기본 설정은 가장 안전한 값이어야 한다.
  • 민감 정보 암호화 - 키나 암호는 버전 관리 시스템이 아닌 빌드나 배포 프로세스 내에서 설정 파일이나 환경 변수로 관리해야 한다.
  • 보안 업데이트
  • 상식 대 암호 - 암호는 절대 직접 만들지 말라
• 이름을 지을 때는 여러분이 표현하고 싶은 것을 더 명확하게 다듬기 위해 끊임없이 노력해야 한다. 이렇게 명확하게 다듬는 작업이 여러분이 코드를 작성할 때 코드를 더 잘 이해할 수 있도록 도울 것이다.

💬 오늘 소감은? 떠오르는 소감을 간단하게 적어보세요

• 개발할 때 내가 쓰는 코드가 정확히 어떤 역할을 하고 이게 왜 정상작동하는지 이해하지 않고 넘어가는 일이 종종 있었다. 앞으로는 우연에 맡기지 말고 정확히 짚고 넘어가야겠다.
• 테스트 주도 개발이라는 개념을 처음 알게 됐다. 실제로 이 방법을 사용하는 경우를 보고 싶다. 개념으로만 읽으면 확실하게 감이 안온다.
• 변수명, 함수명을 지을 땐 언제나 고민이다. 이름 짓기와 관련된 강의가 있다는 것도 봤던 것 같은데 한번 살펴봐야겠다.