공부하는개미

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

• 동기화하는 부분을 작게 만들어라
  • 자바에서 synchronized 키워드를 사용하면 락을 설정한다.
  • 같은 락으로 감싼 모든 코드 영역은 한 번에 한 스레드만 실행이 가능하다.
    => 락은 스레드를 지연시키고 부하를 가중시킨다.
• 코드가 올바르다고 증명하기는 현실적으로 불가능하다.
  • 테스트가 정확성을 보장하지는 않는다.
    => 그럼에도 충분한 테스트는 위험을 낮춘다.
  • 권장사항: 문제를 노출하는 테스트 케이스를 작성하라.
    프로그램 설정과 시스템 설정과 부하를 바꿔가며 자주 돌려라.
    테스트가 실패하면 원인을 추적하라.
    => 다시 돌렸더니 통과하더라는 이유로 그냥 넘어가면 절대로 안 된다.
    • 말이 안 되는 실패는 잠정적인 스레드 문제로 취급하라.
    • 다중 스레드를 고려하지 않은 순차 코드부터 제대로 돌게 만들자.
    • 다중 스레드를 쓰는 코드 부분을 다양한 환경에 쉽게 끼워 넣을 수 있도록 스레드 코드를 구현하라.
    • 다중 스레드를 쓰는 코드 부분을 상황에 맞춰 조정할 수 있게 작성하라.
    • 프로세서 수보다 많은 스레드를 돌려보라.
    • 다른 플랫폼에서 돌려보라.
    • 코드에 보조 코드(instrument)를 넣어 돌려라. 강제로 실패를 일으키게 해 보라.
• 처음부터 그리고 자주 모든 목표 플랫폼에서 코드를 돌려라.
• 스레드 코드를 테스트할 때는 전적으로 스레드만 테스트한다.

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

1. 멀티 스레드를 구현하는 수많은 개발자의 고통이 느껴졌습니다.
   => 아직 구현을 해보지 못해서 모르지만 수 많은 시행착오가 있다고 책에 나와있습니다.
   => 면접에서 스레드 얘기가 나오면 왜이렇게 면접관들이 질문을 할려고 하는지 알 것 같습니다.

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

• 전반적으로 거의 다 이해가 되지 않았습니다.
  => 이전 글에도 적었지만 스레드에대한 개념과 코드를 구현해보지 못한 것 때문에 이해가 힘든 것 같습니다.
  다음에 조금이라도 구현을 해보고 다시 읽으면 좋을것 같은 파트입니다.

👀 소감 3줄 요약

• 다중 스레드 코드는 올바로 구현하기 어렵다.
• 다중 스레드를 쓰는 코드를 다양한 설정으로 실행하기 쉽게 구현하라. 
• 다중 스레드 코드를 작성한다면 각별히 깨끗하게 코드를 짜야한다.

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

• 동시성은 결합(coupling)을 없애는 전략이다.
  • 즉, 무엇(what)과 언제(when)를 분리하는 전략이다.
  • 스레드가 하나인 프로그램은 무엇과 언제가 서로 밀접하다.
    
    
• 동시성과 관련된 타당한 생각 몇 가지
  
  • 동시성은 다소 부하를 유발한다. 성능 측면에서 부하가 걸리며, 코드도 더 짜야한다.
  • 동시성은 복잡하다. 간단한 문제라도 동시성은 복잡하다.
  • 일반적으로 동시성 버그는 재현하기 어렵다.
    그래서 진짜 결함으로 간주되지 않고 일회성 문제로 여겨 무시하기 쉽다.
  • 동시성을 구현하려면 흔히 근본적인 설계 전략을 재고해야 한다.
• 동기화하는 메서드 사이에 존재하는 의존성을 이해하라.
  • 동기화하는 메서드 사이에 의존성이 존재하면 동시성 코드에 찾아내기 어려운 버그가 생긴다.
  • 자바 언어는 개별 메서드를 보호하는 synchronized라는 개념을 지원한다.

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

1. 아직은 지금 이 단계를 깊게 공부할 시기는 아닌 것 같습니다.
2. 스레드를 지금 공부하면 좋겠지만, 아직 13장 전의 내용을 이해해야 할 것 같습니다.

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

• 서블릿이란?
  • 자바를 사용하여 웹을 만들기 위해 필요한 기술입니다.
  • 클라이언트가 어떠한 요청을 하면 그에 대한 결과를 다시 전송해주어야 하는데,
    이러한 역할을 하는 자바 프로그램입니다.
  • 웹 요청과 응답의 흐름을 간단한 메서드 호출만으로 체계적으로 다룰 수 있게 해주는 기술입니다.
• 동기화란?
  • 프로세스 또는 스레드들이 수행되는 시점을 조절하여 서로가 알고 있는 정보가 일치하는 것을 의미합니다.

👀 소감 3줄 요약

• 동시성은 결합(coupling)을 없애는 전략이다.
• 스레드의 개념이 나오니까 엄청 어렵다는 것을 느꼈습니다.
• 읽기만 해서는 이해하기 어려운 파트인 것 같습니다.

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

• 켄트 벡이 제시한 단순한 설계 규칙 네 가지(중요도 순)
  • 모든 테스트를 실행한다.
  • 중복을 없앤다.
  • 프로그래머 의도를 표현한다.
  • 클래스와 메서드 수를 최소로 줄인다.
• 테스트를 철저히 거쳐 모든 테스트 케이스를 통과하는 시스템은 '테스트가 가능한 시스템'이다.
• TEMPLATE METHOD 패턴은 고차원 중복을 제거할 목적으로 자주 사용하는 기법이다.
  
  
• 자신이 이해하는 코드를 짜기는 쉽다.
  => 하지만 나중에 유지보수할 사람이 코드를 짜는 사람만큼이나 문제를 깊이 이해할 가능성은 희박하다.
  
  

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

1. 켄트 벡이 제시한 설계는 결국 지금까지 읽은 클린코드 내용을 지키는 것
2. 테스트 코드의 중요성
   => 테스트가 불가능한 시스템은 검증도 불가능하다.
   => SRP를 준수하는 클래스는 테스트가 훨씬 더 쉽다.
   => 테스트 케이스를 만들기 쉬운 코드는 결국 객체 지향의 목표를 저절로 도달하게 된다.

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

• TEMPLATE METHOD 패턴
  • 전체적으로는 동일하면서 부분적으로는 다른 구문으로 구성된 메서드의 코드 중복을 최소화 할 때 유용하다.
  • 상속을 통해 슈퍼클래스의 기능을 확장할 때 사용하는 가장 대표적인 방법. 변하지 않는 기능은 슈퍼클래스에 
    만들어두고 자주 변경되며 확장할 기능은 서브클래스에서 만들도록 한다. - 토비의 스프링 3.1
• 창발성이란?
  
  • 창발성이란 단순한 결합이 복잡한 결과를 나타내는 것을 의미.
  • 각각의 개미는 집을 지을 능력이 없지만, 작은 개미들의 상호작용을 통해 집이라는 결과물이 나온다.
  • 이처럼 작은 요소들의 상호작용의 반복이 전체 구조에 영향을 미친다.

👀 소감 3줄 요약

• 테스트 코드 그리고 테스트 코드
• 리팩터링을 통한 중복 제거로 객체 지향적 프로그래밍
• 내가 이해하는 코드로만 짜면 결국 나중에 나도 못 알아볼 수 있다.

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

• 순수 자바 AOP 프레임워크
  • 순수 자바 관점을 구현하는 스프링 AOP, JBoss AOP 등과 같은 여러 자바 프레임워크는
    내부적으로 프록시를 사용한다.
    * '순수 자바' 란 AspectJ를 사용하지 않는다는 뜻이다.
  • 스프링은 비즈니스 논리를 POJO로 구현한다.
  • POJO는 순수하게 도메인에 초점이 맞춘다.
  • POJO는 엔터프라이즈 프레임워크에 (그리고 다른 도메인에도) 의존하지 않는다.
    따라서 테스트가 개념적으로 더 쉽고 간단하다.
  • 상대적으로 단순하기 때문에 사용자 스토리를 올바로 구현하기 쉬우며 미래 스토리에 맞춰
    코드를 보수하고 개선하기 편하다.
• 애플리케이션 도메인 논리를 POJO로 작성할 수 있다면, 즉 코드 수준에서 아키텍처 관심사를 분리할 수 있다면,
  진정한 테스트 주도 아키텍처 구축이 가능해진다.
• 초창기 EJB 아키텍처는 기술을 너무 많이 넣느라 관심사를 제대로 분리하지 못했던 유명한 API 중 하나다.
  • 좋은 API는 걸리적거리지 않아야 한다. 그래야 팀이 창의적인 노력을 사용자 스토리에 집중한다.
    그리하지 않으면 아키텍처에 발이 묶여 고객에게 최적의 가치를 효율적으로 제공하지 못한다.
• 도메인 논리가 흐려지면 제품 품질이 떨어진다.
  • 버그가 숨어들기 쉬워지고, 스토리를 구현하기 어려워지는 탓이다.
  • 기민성이 떨어지면 생산성이 낮아져 TDD가 제공하는 장점이 사라진다.
• 모든 추상화 단계에서 의도는 명확히 표현해야 한다.
  • 그러려면 POJO를 작성하고 관점 혹은 관점과 유사한 메커니즘을 사용해 각 구현 관심사를 분리해야 한다.

시스템을 설계하든 개별 모듈을 설계하든,
실제로 돌아가는 가장 단순한 수단을 사용해야 한다는 사실을 명심하자.

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

1. 도메인 설계를 왜 POJO로 하는지 개념이 확실하게 잡히지 않았었습니다.
   => 이번 챕터를 읽으면서 그 이유에 대해서 알 수 있었습니다.
2. 설계가 잘못되면 테스트가 힘들다는 것은 알고 있었는데 정확한 이유를 몰랐었습니다.
   => 도메인 논리를 POJO로 작성하면서 관심사 분리할 수 있다는 이점이 있었습니다.

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

• 횡단 관심사란?
  • 핵심적인 기능이 아닌 중간중간 삽입되어야 할 기능들 관심들을 횡단관심사라고 한다.
    ex) 로깅, 보안, 트랜잭션 처리 등 비즈니스 핵심적인 기능이 아닌 다양한 횡단 관심이 발생할 수 있다.
  • 다른 관심사에 영향을 미치는 프로그램의 Aspect이다. 이 관심사들은 디자인과 구현 면에서 시스템의 나머지 부분으로부터 깨끗이 분해되지 못하는 경우가 있을 수 있으며 분산(코드 중복)되거나 얽히는(시스템 간의 상단한 의존성 존재) 일이 일어날 수 있다. - 위키백과 -
  • 여러 비즈니스 로직이 수행될 때 서로 중복되는 로직이 존재하는지에 대한 관심사.

• 영속성(persistence) 정보란?
  
  • 영속성은 데이터를 생성한 프로그램의 실행이 종료되더라도 사라지지 않는 데이터의 특성을 의미한다.
  • 영속성은 파일 시스템, 관계형 데이터베이스 혹은 객체 데이터베이스 등을 활용하여 구현한다.
  • 영속성을 갖지 않는 데이터는 단지 메모리에서만 존재하기 때문에 프로그램을 종료하면 모두 잃어버리게 된다.
  • 영속성은 특정 데이터 구조를 이전 상태로 복원할 수 있게 해주어 프로그램의 종료와 재개를 자유롭게 해준다.

👀 소감 3줄 요약

• 도메인 논리를 POJO로 작성하고, 코드 수준에서 아키텍처 관심사를 분리할 수 있다면,
  진정한 테스트 주도 아키텍처 구축이 가능해진다.
• 도메인 논리가 흐려지면 제품 품질이 떨어진다.
• 모든 추상화 단계에서 의도는 명확히 표현해야 한다. 

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

• 깨끗한 코드를 구현하면 낮은 추상화 수준에서 관심사를 분리하기 쉬워진다.
  
  
• 시스템 제작과 시스템 사용을 분리하라.
  
  • 우선 제작(construction)은 사용(use)과 아주 다르다는 사실을 명심한다.
  • 시작 단계는 모든 애플리케이션이 풀어야 할 관심사(concern)다.
    => 관심사 분리는 우리 분야에서 가장 오래되고 가장 중요한 설계 기법 중 하나다.
• 의존성 주입(Dependency Injection, DI)
  
  • 사용과 제작을 분리하는 강력한 메커니즘 하나가 의존성 주입이다.
  • 의존성 주입은 제어 역전(IoC)기법을 의존성 관리에 적용한 메커니즘이다.
    => 한 객체가 맡은 보조 책임을 새로운 객체에게 전적으로 떠넘긴다.
    => 새로운 객체는 넘겨받은 책임만 맡으므로 단일 책임 원칙(SRP)을 지키게 된다.
• AOP(Aspect-Oriented Programming, AOP)
  • 횡단 관심사에 대처해 모듈성을 확보하는 일반적인 방법론이다.
  • 특정 관심사를 지원하려면 시스템에서 특정 지점들이 동작하는 방식을 일관성 있게 바꿔야 한다.

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

1. 많이 봤던 단어들이지만 이것에 대한 개념을 이해하기는 어려웠습니다.
2. 자바 스프링관련 책에서 나오는 것들과 겹치는 게 많아서 꾸준히 읽어보면 좋을 것 같다고 느꼈습니다.

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

• 전체적으로 이해하는데 어려웠습니다.
  => 클린코드 책을 여러 번 읽어보면서 이해를 해야 할 것 같습니다.
  => 아직 앞 부분의 내용을 전부 이해하지 못해서 뒷부분이 어려운 것 같습니다.

👀 소감 3줄 요약

• 깨끗한 코드를 구현하면 낮은 추상화 수준에서 관심사를 분리하기 쉬워진다.
• 시작 단계는 모든 애플리케이션이 풀어야 할 관심사(concern)다.
• 사용과 제작을 분리하는 강력한 매커니즘 하나가 의존성 주입이다.

🤢 리팩터링 전 코드

• 문제 라인 -> 7번째
• 클린코드 140p. [null을 전달하지마라]를 바탕으로 리팩터링 했습니다.
• null을 전달하면 NullPointerException이 발생한다.
  => null 처리를 if문으로 하기는 했지만 Optional로 처리를 하면 더 클린 하게 할 수 있다.

😄 [1차 리팩토링 후] 진리 1. null을 전달하지마라

• 여전히 코드가 더럽기는 하지만 우선 null을 그냥 넘겨주는 것을 Optional이라는 함수로 처리했습니다.
  => 만약에 찾는 레스토랑이 null이면 Exception 강제 발생
  => 아니라면 찾은 레스토랑의 정보를 바탕으로 다른 Exception 처리
• 하지만 여기서 28번째 라인을 보면 레스토랑 내 음식 중복검사까지 하는 걸 볼 수 있습니다.
  => 하나의 함수에 2 가지 이상의 로직 처리를 하는 소요 발생
  => 리팩터링 2차 진행!

😄 [2차 리팩터링 후] 진리 2. 한 가지만 해라!

• 클린코드 44p. [한 가지만 해라!]를 바탕으로 리팩터링 했습니다.
• 레스토랑에 등록하려는 음식에 중복되는 음식이 있는지 확인하는 함수를 따로 분리했습니다.
• 하지만 여전히 하나의 함수에 20줄이 넘고 난잡한 코드인 것을 볼 수 있습니다.
  => 3차 리팩터링 진행!

😄 [3차 리팩터링 후] 진리 3. (함수)작게 만들어라

• 클린코드 42p. [작게 만들어라]를 바탕으로 리팩터링 했습니다.
• 하나의 함수를 20라인 내외로 줄였습니다.
• 그만큼 함수가 많이 생기긴 했지만 훨씬 보기 편해지고 깨끗한 코드가 되었습니다.

👀 소감 3줄 요약

• 처음에 코드를 작성할 때 깨끗하게 작성했으면 이런 소요가 없었을 것 같습니다.
• 예전에 작성한 코드를 리팩터링 하면서 방청소를 하는 기분을 느꼈습니다.(힘들지만 뿌듯)
• 깨끗한 코드에 대해 끊임없는 고민이 필요한 것 같습니다.

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

• 변경하기 쉬운 클래스
  • 깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춘다.
• OCP(Open-Closed Principle)
  • 클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다는 객체 지향 설계에서 핵심 원칙
  • 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지는 않는다.
• 변경으로부터 격리
  • 요구사항은 변하기 마련이다. 따라서 코드도 변하기 마련이다.
  • 상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험에 빠진다.
    그래서 우리는 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리한다.
  • 상세한 구현에 의존하는 코드는 테스트가 어렵다.
  • 시스템의 결합도를 낮추면 유연성과 재사용성도 더욱 높아진다.
  • 결합도가 낮다는 소리는 각 시스템 요소가 다른 요소로부터 그리고 변경으로부터 잘 격리되어 있다는 의미다.
  • 시스템 요소가 서로 잘 격리되어 있으면 각 요소를 이해하기도 더 쉬워진다.
• DIP(Dependency Inversion Principle)
  • 클래스가 상세한 구현이 아니라 추상화에 의존해야 한다는 원칙이다.

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

1. OCP, DIP 등 객체지향 선계의 핵심 원칙을 단순히 개념만 공부하는 정도로 했다는 걸 느꼈습니다.
   => "OCP는 이거다!"라는 개념이 아니라 빌드업 형식으로 책에서 설명해 이해에 도움되었습니다.
   
   
2. 강한 결합도의 코드를 짜서 프로젝트의 방향성이 조금만 바뀌어도 프로젝트가 흔들린 경험이 있습니다.
   => '위와 같은 개념을 알고 있었다면 프로젝트에서 어떻게 적용했을까?'라는 생각을 했습니다.
   => 당장 적용하는 것은 힘들겠지만, 코드를 작성하고 리팩터링 하면서 배워야겠다고 느꼈습니다.

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

• 이런 원칙을 지키기 위해서는 어떻게 해야 할까?
  • 직접 더러운 코드를 작성해보고 잘 작성한 사람의 코드를 봐야 된다고 생각합니다.
  • 좋은 책을 쓰기 위해서는 잘 작성한 사람의 책을 보고 분석하는 것과 비슷한 것 같습니다.

👀 소감 3줄 요약

• OCP -> 클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다.
• 시스템의 결합도를 낮추면 유연성과 재사용성도 더욱 높아진다.
• DIP -> 클래스가 상세한 구현이 아니라 추상화에 의존해야 한다.

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

• 클래스는 작아야 한다!
  
  • 함수는 물리적인 행 수로 크기를 측정했다. 클래스는 다른 척도로 사용한다.
    클래스가 맡은 책임을 센다.
  • 클래스 이름은 해당 클래스 책임을 기술해야 한다.
    실제로 작명은 클래스 크기를 줄이는 첫 번째 관문이다.
  • 클래스 설명은 만일("if"), 그리고("and"), -(하)며("or"), 하지만("but")을 사용하지 않고서
    25 단어 내외로 가능해야 한다.
• 단일 책임 원칙(Single Responsibility Principle, SRP)
  • 클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙이다.
  • SRP는 '책임'이라는 개념을 정의하며 적절한 클래스 크기를 제시한다.
    => 클래스는 책임, 즉 변경할 이유가 하나여야 한다는 의미다.
  • 큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다.
• 응집도(Cohesion)
  • 클래스는 인스턴스 변수 수가 작아야 한다.
  • 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 한다.
  • 모든 인스턴스 변수를 메서드마다 사용하는 클래스는 응집도가 가장 높다.
  • 클래스가 응집력을 잃는다면 쪼개라!

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

1. SRP에 대한 개념은 책으로 한번 봤었는데 이해가 전혀 안되었습니다.
   => 이번에 클린코드를 읽으면서 좀 더 명확하게 이해를 하게 되었습니다.
   => 예시가 너무 잘 나와있어서 이해에 큰 도움이 되었습니다.
   => 아직 제가 진행한 프로젝트가 규모가 너무 작아서 클래스가 복잡해지는 경우가 적은 것 같습니다.
   => 이론으로 공부 하는 것보다는 실질적으로 코드를 보고 타이핑 해보는게 도움이 될 것 같습니다.

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

• 응집도에 대한 부분이 전반적으로 이해가 되지 않았습니다.
  
  • 클래스는 적은 인스턴스 변수를 가져야 한다.
  • 응집도가 높다는 것은 클래스의 모든 메소드들에 대하여 인스턴스 변수를
    사용하는 비율이 높다는 것이다.
  • 응집도가 낮다는 것은 메소드와 변수의 논리적 연결이 약하므로 클래스를
    더욱 분리 할 수 있음을 암시한다.

👀 소감 3줄 요약

• 클래스는 작아야 한다!
• 클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다
• 클래스가 응집력을 잃는다면 쪼개라!

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

• 이중 표준
  
  • 실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있다.
    => 대게 메모리나 CPU 효율과 관련 있는 경우다.
    => 코드의 깨끗함과는 철저히 무관하다.
    
    
• 테스트 당 assert 하나
  • assert 문이 단 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽고 빠르다.
  • 독자적인 테스트 클래스를 만들어 @Before 함수에 given/when 부분을 넣고
    @Test 함수에 then 부분을 넣어도 된다.
  • assert 문 개수는 최대한 줄여야 좋다.
    
    
• 테스트 당 개념 하나
  • 테스트 함수마다 한 개념만 테스트하라
  • 이것저것 잡다한 개념을 연속으로 테스트하는 긴 함수는 피한다.
    
    
• F.I.R.S.T
  • 빠르게(Fast)
    => 테스트가 느리면 자주 돌릴 엄두를 못 낸다.
    => 자주 돌리지 않으면 초반에 문제를 찾아내 고치지 못한다.
    
    
  • 독립적으로(Independent)
    => 각 테스트는 서로 의존하면 안 된다.
    => 한 테스트가 다음 테스트가 실행될 환경을 준비해서는 안 된다.
    => 각 테스트는 독립적으로 그리고 어떤 순서로 실행해도 괜찮아야 한다.
    => 테스트가 서로 의존하면 하나가 실패할 때 나머지도 잇달아 실패해 원인을 진단하기 어렵다.
  • 반복 가능하게(Repeatable)
    => 테스트는 어떤 환경에서도 반복 가능해야 한다.(실제 환경, QA 환경, 집에 있는 노트북 등)
    => 테스트가 돌아가지 않는 환경이 하나라도 있다면 테스트가 실패한 이유를 둘러댈 변경이 생긴다.
    
    
  • 자가 검증하는(Self-Validating)
    => 테스트는 부울(bool) 값으로 결과를 내야 한다.(성공 아니면 실패)
    => 통과 여부를 알려고 로그 파일을 읽게 만들어서는 안 된다.
    
    
  • 적시에(Timely)
    => 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.
    => 테스트가 불가능하도록 실제 코드를 설계할지도 모른다.

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

1. given-when-then이라는 관례를 함수명에 넣은 것은 처음 봤습니다.
   => 제가 작성했던 코드에는 주석을 달아서 명시해줬었습니다.
   => 보통 서비스 로직에 있는 메서드를 가져와서 테스트를 했기 때문에 이 방법을 적용하기 힘들 것 같습니다.
   
   
2. 단위 테스트를 먼저 구현하고 실제 코드를 작성한다는 부분이 흥미로웠습니다.
   => 프로젝트를 하면서 한번 해보고 싶었지만, 같은 팀원이 테스트에 부정적이라 적용이 힘들었습니다.
   => 테스트를 먼저 작성한다면 그것을 어떻게 구상할지 생각해봐야겠다고 생각했습니다.
   => 확실히 이미 구현된 실제 코드를 단위 테스트로 구현하는건 제한 사항이 있었습니다.
       * 코드 커버리지를 올리기 정말 힘들었습니다.

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

• 테스트를 빨리 돌리는 부분에서 어떻게 해야 할지 감이 안 잡힙니다.
  => 제가 진행했던 프로젝트에서는 규모가 커질수록 테스트가 엄청 오래 걸렸습니다.
  => 좋은 단위 테스트는 속도가 빠르다는 게 이 부분을 개선하도록 해봐야겠습니다.

👀 소감 3줄 요약

• 테스트 하나 당 개념 하나!
• 테스트는 빠르게 자주 돌릴 수 있도록!
• 모든 환경에서 돌아갈 수 있도록!

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

• TDD 법칙 세 가지
  • 첫째: 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
  • 둘째: 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
  • 셋째: 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
• 테스트는 유연성, 유지보수성, 재사용성을 제공한다
  
  • 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트다.
    => 이유는 테스트 케이스가 있으면 변경이 두렵지 않으니까!
    => 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다.
  • 테스트 커버리지가 높을수록 공포는 줄어든다.
  • 테스트 코드가 지저분할수록 실제 코드도 지저분해진다.
    => 결국 테스트 코드를 잃어버리고 실제 코드도 망가진다.
• 깨끗한 테스트 코드
  • 가독성은 실제 코드보다 테스트 코드에 더더욱 중요하다.
  • 테스트 코드에 가독성을 높이려면 명료성, 단숭성, 풍부한 표현력이 필요하다.
    => 테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다.

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

1. BUILD-OPERATE-CHECK 패턴
   => 제가 배운 방식은 Given-When-Then 패턴을 사용했었는데 의미는 같은것 같습니다.
2. 팀 프로젝트를 하면서 팀원이 테스트 코드에 부정적인 생각을 가지고 있었습니다.
   그 팀원을 설득하기 위해 테스트코드를 작성해서 팀원의 코드에서 버그를 발견해 수정했습니다.
3. 프로젝트를 진행하면서 내가 작성하는 테스트코드가 맞는 방식인지 고민이 되었었습니다.
   => 클린코드의 잘 작성된 테스트코드 예시를 보면서 잘 작성하고 있었다는 것을 알게 되었습니다.

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

• 마지막 프로젝트에서 테스트코드 커버리지는 61퍼 정도까지 완료했습니다.
  어떻게하면 더욱 높일 수 있을지 고민입니다.
  
  
• 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
  => 위 내용이 감이 잡히지 않습니다.
  => 실패의 기준을 잘 모르겠습니다.

👀 소감 3줄 요약

• 테스트는 유연성, 유지보수성, 재사용성을 제공한다
• 테스트 코드도 가독성, 가독성, 가독성!
• BUILD-OPERATE-CHECK 패턴을 사용한 테스트 코드 정리