계획
코딩 테스트 문제 풀이
- 오늘의 과제 여러가지 방식으로 풀기
- 키패드 문제 리팩토링
Facts
도메인 주도 설계 읽기
- 엔티티와 식별성
- 동일성 연산이 식별성을 보장해주지는 않는다.
속성과 식별성.
3 진법 뒤집기 풀이
그림으로 배우는 HTTP 스터디
- 헤더 필드
- 일반 헤더 필드
- 리퀘스트 헤더 필드
- 리스폰스 헤더 필드
일반 헤더 필드에서 캐시 필드를 지정해주었다. 일반 헤더 필드는 리퀘스트와 리스폰스 메시지 모두에서 쓰일 수 있으나 그 의미가 다르다. 따라서 메세지 송신 주체에 따라서 어떤 의미를 갖는지 다르게 파악해야 한다.
캐시 필드에 따라 실제로 캐시전략을 다르게 수행하는 주체는 캐시 서버이다. 캐시 서버에서는 캐시를 저장하거나 캐시를 클라이언트에 돌려주는 역할을 한다.
리퀘스트 헤더 필드와 리스폰스 헤더 필드는 각각 송신자의 상태를 나타내는 역할을 한다. 예를 들어, user-agent 라는 헤더 필드를 통해서 서버는 클라이언트의 운영체제와 브라우저 종류등을 알수있게 된다. 이외에도 메시지 처리를 어떻게 하면 좋을지에대한 정보도 제공한다. 예를들어, accept, content-type 등은 엔티티에 대한 메타정보를 주어서 어떻게 처리해야 할지에 대한 정보를 알려준다.
프로그래머스 <후보키> 문제풀이
문제: https://programmers.co.kr/learn/courses/30/lessons/42890
풀이: https://github.com/gringrape/daily_coding_dojo/tree/main/20210701/python
풀이가 엉망이었다. 엉망이라고 한 이유에는 여러가지가 있다. 일단, 피드백 주기가 길었다. 그리고 피드백 내용도 혼란의 여지가 있었다. 기능을 추가하면 목표한 기능이 잘 동작하는지를 확인해야 하는데, 테스트로 종료시점을 못박아두지 않아서, 계속 진행했다. 중간에 한번씩 콘솔로그를 찍거나 REPL 을 통해 구현상황을 체크해주기는 했으나, 이때에도 무엇을 확인할지 미리 선언해두지 않아서 머리가 복잡해졌다.
두번째로 리팩토링할 여력이 없었다. 구현과 구현결과확인이라는 두가지 작업에 뇌 용량을 다 쓰다보니 학습해서 더 낫게 고치려는 시도를 하기 어려웠다. 아니다. 좀 더 정확한 진단은, 테스트 범위가 넓은 것이다. 전체 리팩토링이란 것은 허상이다. 목적이 분명한 특정부분을 똑같이 목적달성하면서 더 낫게 고치는 것이 리팩토링이다. 따라서, 그 부분을 검증하는 테스트가 필수이다.
고쳐야할것들은 다음과 같다.
- 테스트 케이스를 일단 통제 불가능하게 잡지 않는다. 샘플 케이스는 말 그대로 샘플이며, 거기서 먼저 구현할 부분을 강조하고 나머지는 버린다. 나중에 추가한다.
- 문제 도메인을 함축적으로 나타내는 몇가지 단어의 목록(e.g. 키, 유일성, 최소성, 후보키)을 항상 옆에두고 코딩한다.
- 의도를 먼저 드러낸다. 테스트를 쓰는 것이 가장좋다. 쓰는쪽부터 작성하는것도 좋다. 목적지를 정해놓지 않은 상태로 시작하지 말라.
- 결과의 검증은 가급적 자동으로 이루어지도록 해라. 구현이 잘 동작하는지 검증하느라 귀중한 뇌의 자원을 소모하지 말라.
Findings
김교수의 세가지
- 순간의 생각들을 누적하고 다시 꺼내는 연습을 하는 것이 중요하다.
- 어떤 내용이든 자신만의 방법으로 받아들이고 정리하는 것이 몸에 익어야 하고, 이것을 자기화라고 한다.
Affirmation
- 나는 실천력있는 사람이다.
- 나는 문제에 직면하는 사람이다.
