오늘 TIL 3줄 요약

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

• 그러기 위해선 테스트가 중요하다. (TDD가 나올정도로)

• 그러면서도 알고리즘의 개선(Big-O표기법)과 리팩토링을 지향하자.

TIL (Today I Learned) 날짜

2022-05-28

오늘 읽은 범위

7장. 코딩하는 동안

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

파충류 뇌에 귀 기울이기 - 본능과 무의식적 생각을 더 활용

우연을 맡기는 프로그래밍 - 더 적극적으로 행동하는 방법

알고리즘의 속도 코드 속도를 추정하는 방법을 논의

리팩터링 - 기존코드의 개선

테스트로 코딩하기

상속기반 테스트 - 컴퓨터에게 넓은 범위의 테스트를 시킬 수 있을지 버그 대처 방법

바깥에서는 안전에 주의하라

이름 짓기 - 가장 어려운 작업

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

본능 무의식에 귀 기울이고 또 기울인다. 하던 일을 멈추고 뇌가 정리할 시간과 공간을 확보하라.

억지로 할 필요가 없다.

문제를 표면으로 끄집어내 보라.

정 풀리지 않는다면, 행동할 타이밍이다. → 프로토타이핑

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

행운과 우연에 의존하는 프로그래밍을 지양한다. → 의도적 프로그래밍

암묵적인 가정 - 우연은 여러 단계에서 우리를 오도 하게 만든다.

Topic 39. 알고리즘의 속도

Big-O 표기법 - 알고리즘이 사용하는 자원 시간 프로세서 메모리의 추정

• 우리가 측정하는 값-시간,메모리 등의 상한을 기술하는 표기법 n2의 시간이 걸린다 하면, 함수가 실행되는데 걸리는 시간의 최댓값이 n2보다 더 빨리 늘어나지 않는다 는 뜻이다.

• 그저 입력의 크기가 바뀜에 따라 값이 어떻게 바뀔지 알려줄뿐, 시간이나 메모리에 대한 실제 숫자를 알려주지는 않는다.

O(1) - 상수
O(n) - 선형(순차 검색)
O(lg n) - 로그(이진검색)
O(n lg n) -선형보다 좋지 않지만 나쁘지 않은 퀵정렬 힙정렬의 수행시간
O(n^2) - 제곱
O(n^3) -세제곱
상식으로 추정하기

단순반복 - n

중첩 반복 - n^2

반씩 자르기 - lg n 

분할 정복 - n lg n 

조합적알고리즘  …

• 실전에서의 알고리즘 속도 - 사용하는 알고리즘의 차수를 추정하라.

• 이론적인 요인과 실무적인 요인을 모두 고려하도록 노력해보라

  • 우리의 코드를 혹은 추정을 테스트 하라.

  • 성급한 최적화 조심하라

  ---

Topic 40. 리팩토링

• 코드 수정은 지극히 자연스러운 과정

• 코드는 발전해야 한다.

• 코드 고쳐쓰기, 다시 작업하기, 다시 아키텍쳐 만들기 → 재구성(리팩토링)

<aside> 🔥 마틴파울러 - 리팩토링 밖으로 드러나는 동작은 그대로 유지한 채 내부 구조를 변경함으로써 이미 존재하는 코드를 재구성하는 체계적인 기법.

</aside>

1. 이 활동은 체계적이다. 아무렇게나 하는 것이 아니다.

2. 밖으로 드러나는 동작은 바뀌지 않는다. 기능을 추가하는 작업이 아니다.

→ 좋은 자동화된 단위 테스트가 선필요.

• 리팩토링은 그럼 언제 하는가?

  • 무언가를 더 많이 알게되었을때.

  • 중복 DRY 원칙 위반

  • 직교적이지 않는 설계

  • 더 이상유효하지 않는 지식

  • 지식은 늘 변할수 있다.

  • 사용사례

  • 성능

  • 테스트 통과 - 모든 테스트가 뒷받침되어야 한다.

• 고통 관리의 실천……

• 일찍 리팩토링하고 자주 리팩토링하라.

• 리팩토링할 시간을 과하지 않지만 확실히 포함시켜 두도록한다.

그렇다면 리팩토링은 어떻게 하는가?

• 본질은 재설계이다. 천천히 신중하게 조심스럽게 진행하는 작업.

• 마틴파울러의 간단한 조언 몇가지

1. 리팩토링과 기능추가를 동시에 하지 말라.
2. 리팩터링 시작하기전 든든한 테스트가 있는지 확인하라.
 - 또 자주, 테스트 하라
3. 단계를 작게 나누어서 신중하게 작업하라.

-> 탄탄한 회귀 테스트를 유지하는 것이야말로 안전한 리팩토링의 비결

Topic 41. 테스트로 코딩하기

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

  • 주요 이득은 테스트를 생각하고 작성함으로써 생긴다고 믿자.

  • 테스트가 코드의 첫번째 사용자이다.

• 테스트 주도 개발

  • 추가하고 싶은 작은 기능하나를 결정

  • 그 기능 구현되었을떄의 테스트 하나 작성

  • 테스트 실행 다른 테스트는 통과하고 방금 추가한 테스트 딱 하나만 실패해야됌.

  • 실패하는 테스트를 통과할수있는 최소한의 코드를 작성 → 모든 테스트 통과 확인

  • 코드 리팩토링

  • 단, 테스트 개발 주도의 노예가 되지 말자. (과도한 투자와 중복)

• TDD 의 명백한 목표설정이 필요.

• 여러분의 소프트웨어를 테스트 하라. 그렇지않으면 사용자가 테스트 하게 된다.

• 테스트 설계 코딩 이모든 것이 프로그래밍이다.

Topic 42. 속성기반 테스트

• 컴퓨터에게 테스트를 맡긴다.

• 계약을 코드에 포함하자고 이야기했다. 불변식은 함수 실행 전후로 어떤 부분에 대하여 참이 되는 조건.

• 계약 + 불변식 = 속성으로 부르고 속성기반의 테스트할 수 있다.

from hypothesis import given
import hypothesis.strategies as some
-> 랜덤 테스트 데이터 생성서

• 입력을 생성하는 규칙과 출력을 검증하는 단정문만 설정한채 작동되기 때문에 속성기반 테스트의 위력은 강력하다.

Topic 43. 바깥에서는 안전에 주의하라.

• 기본 보안 원칙

  1. 공격 표면을 최소화하라.

     • 입력 데이터는 공격 매개체이다.

     • 코드의 복잡성은 공격 매개체를 유발한다.

     • 인증이 없는 서비스는 공격 매개체이다.

  2. 최소 권한 원칙.

  3. 안전한 기본값.

  4. 민감 정보를 암호화하라.

  5. 보안 업데이트를 적용하라.

• 암호화는 직접 만들지 말라.

  • 외부의 인증서비스를 사용.

Topic 44. 이름 짓기

• 우리의 뇌는 단어를 꼭 지켜야 하는 것으로 인식한다.

• 문화를 존중하라. → 다른 개발자들과의 소통

• 각 단어의 뜻을 알고 일관성있게 사용해야 된다.

• 많은 의사소통이 전제되어야 할 것이다.

• 이름 바꾸기는 더욱 어렵다.

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

• 다음책은 마틴파울러의 리팩토링을 읽을 생각이다.

• 테스트는 참 중요한 것은 말해 무엇하랴. 실무에서도 완벽한 테스트를 했다고 하지만서도, 늘 이슈는 나기 마련이다. 내가 테스트가 제대로 진행되지 않는다면 사용자가 테스트를 진행하게 된다고 한 문구가 생각난다.

• 개발자는 늘 더 좋은 설계를 염두해 리팩토링하여야한다. 요구사항은 늘 변하고 변하는 요구사항을 수용하기 위한 더 나은 설계(개방폐쇄 원칙)를 지속적으로 고민 ,탐구해야한다.

• 테스트를 위한 정형화된 청사진을 만들어놔야한다.(TDD가 됐든, 단위테스트가 됐든) 그 시기를 늦추면 테스트의 부채는 이자에 이자를 낳아. 더이상 손쓸수 없는 "파산" 상태가 되곤 한다.

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

오늘 읽은 다른사람의 TIL