공부하는개미

💗 노개북 최애 틸(TIL)

Flynn(플린님)

• 리팩터링 미션 할 때 플린님의 깨끗한 코드를 참고했습니다.
  덕분에 공부도 많이 되었습니다.
• 플린님 TIL 링크

친슈님

• 3줄 요약과 읽은 소감을 가장 많이 보고 배웠던 TIL입니다.
• 책을 읽으면서 막히는 부분을 가장 많이 참고했던 곳 중 하나입니다.
• 친슈님 TIL 링크

Jz님

• 처음 노개북 작성을 했을 때 어떻게 정리할지 감이 안 잡혔을 때 Jz님 TIL을 보고 큰 도움이 되었습니다.
• 책을 읽으면서 막히는 부분을 가장 많이 참고했던 곳 중 하나입니다.
• Jz님 TIL 링크

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

• 경계 살피고 익히기
  • 우리 자신을 위해 우리가 사용할 코드를 테스트하는 편이 바람직하다.
  • 외부 코드를 곧바로 작성해 외부 코드를 호출하는 대신 먼저 간단한 테스트 케이스를 작성해
    외부 코드를 익히면 어떨까?
    => 짐 뉴커크(Jim Newkirk)는 이를 학습 테스트라 부른다.
• 학습 테스트는 공짜 이상이다.
  • 학습 테스트에 드는 비용은 없다.
  • 학습 테스트는 이해도를 높여주는 정확한 실험이다.
  • 패키지 새 버전이 나온다면 학습 테스트를 돌려 차이가 있는지 확인한다.
  • 학습 테스트는 패키지가 예상대로 도는지 검증한다.
• 경계에 위치하는 코드는 깔끔히 분리한다.
• 통제가 불가능한 외부 패키지에 의존하는 대신 통제가 가능한 우리 코드에 의존하는 편이 훨씬 좋다.
  => 자칫하면 외부 코드에 휘둘리고 만다.
  
  
• 외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하자.
  • 새로운 클래스로 감싸거나 아니면 ADAPTER 패턴을 사용해 우리가 원하는 인터페이스를
    패키지가 제공하는 인터페이스로 변환하자.
  • 어느 방법이든 코드 가독성이 높아지며, 경계 인터페이스를 사용하는 일관성도 높아지며,
    외부 패키지가 변했을 때 변경할 코드도 줄어든다.

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

1. [학습 테스트] 토비의 스프링에서 봤던 내용이 나와서 반가웠습니다.
   => 하지막 실질적으로 활용을 하고 있지 않아서 좀 더 찾아보고 공부해봤습니다.
   => 학습 테스트와 단위 테스트에 대해 잘 정리된 블로그(링크)
   => 학습 테스트의 개념과 장점, 예제가 정리된 블로그(링크)
2. 경계에 위치하는 코드 분리 관련해서는 개방 폐쇄 원칙(OCP)이 생각났다.
   => 객체의 확장은 개방적이지만, 객체의 수정은 폐쇄적으로 대하는 원칙을 말한다.
   => 기능이 변하거나 확장은 가능하지만, 해당 기능의 코드는 수정하면 안 되도록 하는 원칙
   => 만약에 외부 패키지가 수정되면 해당 객체에 의존하는 다른 객체도 줄줄이 고쳐야 하는데
        그런 문제를 방지하기 위해 개방 폐쇄 원칙을 적용한다.(참고 링크)

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

• 외부 코드 사용하기 파트에서 의문 발생(144p)
  
  • IT회사 관련 얘기를 들으면서 하나의 버전으로 프로젝트를 진행하고 버전업을 안 한다는 얘기를 들었습니다.
    그렇다면 책에서 나오는 버전업으로 인한 문제는 직면하기 힘들 수도 있겠다는 생각을 했습니다.
  • 책에서는 예시를 하기 위해 자바 코드 관련을 예시로 들었다고도 생각했습니다.
  • 외부 라이브러리를 가져와서 사용한다면?
    => 책에서 추천하는 학습 테스트 후에 도입하는 방법 진행
    => 기존에 외부 라이브러리를 사용하는 부분을 외부 패키지에 의존성이 높지 않도록 구성

👀 소감 3줄 요약

• 학습 테스트는 권장이 아닌 필수
• 통제가 불가능한 외부 패키지에 의존하는 대신 통제가 가능한 우리 코드에 의존하는 편이 훨씬 좋다.
• 외부 패키지가 변경되었을 때 내가 작성한 코드가 변경해야 하는 소요를 줄이도록 설계

노개북 13일 차에 7장의 내용을 다 읽고 정리했습니다.

그래서 해당 내용을 바탕으로 제 코드를 리팩터링 하는 걸 정리해봤습니다.

😅 리팩터링(53번째 줄)

문제점

• 53번째 줄을 보면 게시글의 생성날짜가 null이면 그냥 클라이언트 단으로 null을 전달하는 문제가 있습니다.
• null이 전달되면 프론트엔드 개발자가 한번 더 게시글의 작성 날짜 처리를 해야 하는 문제 발생
  *근데 여기서 궁금한거 TimeStamp

😀 리팩터링 후(8번째 줄)

• 8번째 줄
• 우선 LocalDateTime.Now 를 통해 게시글 작성 시간을 리턴해주는 방법 적용
• 하지만 여기서 또 문제점은 DB에 게시글 작성 날짜가 저장되지 않는 문제 발생
  => 게시글을 다시 조회(새로고침)했을 때 게시글 작성 날짜가 안나오는 문제 발생

🤔 리팩터링 후 문제점

• DB에 해당 게시글의 데이터가 저장 되면서 저절로 생성 날짜(CreatedAt)가 저장되도록 Entity를 구성했습니다.
  => 여기서 진짜 만약에 CreateAt이 작동 되지 않을 경우를 대비하기 위해 null을 클라이언트단에 리턴하는 방식
• 이 만약을 위해 게시글의 생성날짜를 해당 Entity에 다시 넣어주고 DB에 저장하는 단계를 거쳐야 하나?
  => Entity 부분에 생성날짜(CreatedAt)을 다시 넣어주고 저장하는 수요 발생
  => 생성날짜를 다시 넣어주고 저장하는 단계에서 SQL문이 추가로 발생하는 번거로움 발생

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

• 깨끗한 코드와 오류 처리는 확실히 연관성이 있다.
  • 오류 처리 코드로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다.
• Try-Catch-Finally 문부터 작성하라.
  • 예외에서 프로그램 안에다 범위를 정의한다는 사실은 매우 흥미롭다.
  • 어떤 면에서 try 블록은 트랜잭션과 비슷하다.
    try 블록에서 무슨 일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야 한다.
    그러므로 예외가 발생할 코드를 짤 때는 try-catch-finally 문으로 시작하는 편이 낫다.
• null을 반환하지 마라
  • null을 반환하는 코드는 일거리를 늘릴 뿐만 아니라 호출자에게 문제를 떠넘긴다.
  • 누구 하나라도 null 확인을 빼먹는다면 애플리케이션이 통제 불능에 빠질지도 모른다.
  • 메서드에서 null을 반환하고픈 유혹이 든다면 그 대신 예외를 던지거나 특수 사례 객체를 반환한다.
  • null을 반환하면 NullPointerException이 발생 할 가능성이 늘어나게 된다.
• null을 전달하지 마라
  • 대다수 프로그래밍 언어는 호출자가 실수로 넘기는 null을 적절히 처리하는 방법이 없다.
    그렇다면 애초에 null을 넘기지 못하도록 금지하는 정책이 합리적이다.
  • 인수로 null이 넘어오면 코드에 문제가 있다는 말이다.
• 깨끗한 코드는 읽기도 좋아야 하지만 안정성도 높아야 한다.
  • 오류 처리를 프로그램 논리와 분리해 독자적인 사안으로 고려하면 튼튼하고 깨끗한 코드를 작성할 수 있다.
  • 오류 처리를 프로그램 논리와 분리하면 독립적인 추론이 가능해지며 코드 유지보수성도 크게 높아진다.

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

1. 어디서 들은지 모르겠지만, null처리를 잘 해줘야 한다는 얘기를 들었었습니다.
   하지만 프로젝트에 작성한 코드에서 null을 그냥 반환해주는 경우도 있었던 것 같습니다.
2. 책을 읽으면서 아직 이해가 안되는 부분이 많았습니다.
   => 한번 더 읽고 생각을 할 예정입니다.
3. 팀 프로젝트에서 예외처리를 잘 못해서 문제가 생겼던 적이 있었습니다.
   이 때는 예외처리를 안 넣어서 문제가 생긴게 아니라 적절한 예외처리를 넣지 못했기 때문이였습니다.
   => 굳이 넣지 말아야 할 예외처리를 넣어서 문제 발생

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

• Try-Catch-Finally 보다는 예외를 강제로 발생시키는 방법을 사용하고 있는데 어떤게 맞는지 궁금합니다.
  
  • Try-Catch-Finally는 예외를 명시하기 힘들기 때문에 직접 예외를 throw 해주는 방식을 사용하고 있었습니다.
  • 직접 예외를 throw 하면서 고민 되었던 것은 프로그래머가 생각하는 예외에만 처리가 가능하다는 점입니다.
    그에 반대로 Try-Catch-Finally 는 다양한 예외를 처리가 가능하다는 점이였습니다.
  • Try-Catch-Finally를 사용하면 코드를 깔끔하게 작성하는게 정말 힘들다고 느꼈습니다.
  • Try-Catch-Finally를 사용해야 한다면 어느 부분에 사용해야 할 지 아직은 감이 안잡힙니다.

👀 소감 3줄 요약

• Try-Catch-Finally 문부터 작성하라
• null은 반환하지도 전달하지도 마라! (NullPointerException 발생)
• 깨끗한 코드는 읽기도 좋아야 하지만 안정성도 높아야 한다.

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

• 변수를 비공개(private)로 정의하는 이유가 있다.
  => 남들이 변수에 의존하지 않게 만들고 싶어서다.
  => 충동이든 변덕이든, 변수 타입이나 구현을 맘대로 바꾸고 싶어서다.
  
  
• 자료 추상화
  => 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다.
  => 자료를 세세하게 공개하기보다는 추상적인 개념으로 표현하는 편이 좋다.
  => 인터페이스나 조회/설정 함수만으로는 추상화가 이뤄지지 않는다.
  => 개발자는 객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 한다.
  아무 생각 없이 조회/설정 함수를 추가하는 방법이 가장 나쁘다.
  
  
• 자료/객체 비대칭
  

  객체: 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개한다.
  자료 구조: 자료를 그대로 공개하며 별다른 함수는 제공하지 않는다.​

  => 절차적인 코드는 기존 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉽다.
       반면, 객체 지향 코드는 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다.
  => 절차적인 코드는 새로운 자료 구조를 추가하기 어렵다. 그러려면 모든 함수를 고쳐야 한다.
       객체 지향 코드는 새로운 함수를 추가하기 어렵다. 그러려면 모든 클래스를 고쳐야 한다.
• 분별 있는 프로그래머는 모든 것이 객체라는 생각이 미신임을 잘 안다.
  때로는 단순한 자료 구조와 절차적인 코드가 가장 적합한 상황도 있다.
  
  
• 디미터 법칙
  => 디미터 법칙은 잘 알려진 휴리스틱(heuristic)으로, 모듈은 자신이 조작하는 객체의 속사정을
       몰라야 한다는 법칙이다.
  
  => 기차 충돌 코드
  

  final String = outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();​

   리팩터링 전 기차 충돌 코드(위)
  
  

  Options opts = ctxt.getOptions();
  File scratchDir = opts.getScratchDir();
  final String outputDir = scratchDir.getAbsolutePath();​

  리팩터링 후(위)
  
  
• 자료 전달 객체(DTO)
  => 자료 구조체의 전형적인 형태는 공개 변수만 있고 함수가 없는 클래스다.
       이런 자료 구조체를 때로는 자료 전달 객체(Data Transfer Object, DTO)라 한다.
  => DTO는 데이터베이스에 저장된 가공되지 않은 정보를 애플리케이션 코드에서 사용할 객체로
       변환하는 일련의 단계에서 가장 처음으로 사용하는 구조체다.
  
  
• 우수한 소프트웨어 개발자는 편견 없이 이 사실을 이해해 직면한 문제에 최적인 해결책을 선택한다.
  => 새로운 자료 타입을 추가하는 유연성이 필요하면 객체가 더 적합하다.
  => 새로운 동작을 추가하는 유연성이 필요하면 자료 구조와 절차적인 코드가 더 적합하다.

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

1. 롬복(Lombok)이라는 라이브러리가 있는데 @Data를 엔티티에 무분별하게 사용하는 코드를 봤었다.
   => @Data는 getter, setter 등 반복적인 것을 추가하는 번거로움을 줄여주는 어노테이션이다.
   하지만 이 책을 읽고 이것을 무분별하게 사용하면 독이 된다는 것을 알게 되었습니다.
   => 책에서 나오는 '아무 생각 없이 조회(Getter) / 설정(Setter)를 추가하는 방법이 가장 나쁘다' 부분에 해당
   
   
2. 혹시 내 코드가 잡종 구조?
   => 새로운 함수는 물론이고 새로운 자료 구조도 추가하기 어렵다고 한다.
   => 양쪽 세상에서 단점만 모아놓은 구조라고 한다.
   => 우선 강의에 나오는 패턴을 거의 비슷하게 따라하면서 작성을 해서 설계를 크게 고려하지 않았기 때문이다.
   
   
3. 기차 충돌코드 어디서 본 것 같은데?
   

           if (!userDetails.getUsername().equals(dictQuestion.getUser().getUsername())) {
               throw new IllegalArgumentException(NOT_MY_QUESTION);
           }​

   => 웹사이트에 접속해 로그인한 유저와 질문 게시글 작성자의 아이디가 같은지 확인하는 if문 입니다.
   => dictQuestion.getUser().getUsername()이 예시로 보여준 기차 충돌코드와 똑같다.
   => 우선 엔티티 설계가 이렇게 되어 있어서 이 부분을 어떻게 수정 해야 할 지 지금은 감이 안잡힌다.
        다음에 엔티티를 설계 할 때는 이런 문제가 발생하지 않도록 해야겠다.
   
   

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

• 6장은 객체와 자료구조에 대해 알고 있는 게 적어서 다른 분이 작성한 것을 참고했습니다.
  => 객체지향 파트는 어느정도 읽기는 할 수 있었는데 자료구조라는 파트가 어려웠습니다.
  => 객체지향과 절차지향의 차이를 설명하는 것 같았습니다.
  
  

👀 소감 3줄 요약

• 객체지향을 예전에 책으로 공부 했지만 아직도 한참 부족하다는 걸 느꼈습니다.
• 객체는 동작을 공개하고 자료를 숨긴다.
• 자료 구조는 별다른 동작 없이 자료를 노출한다.

💩 리팩터링 전

🥰 리팩터링 후

🤔 느낀 점

• 자바스크립트에서 시간관련 함수가 있나 검색하는 시간이 꽤 길었습니다.
  => 결론은 시간 관련 함수 없이 예시로 나온 로직으로 리팩터링 하는 것이였습니다.
  => 생각해보니 로직을 변경하면 리팩터링이라고 하기 좀 뭐한 것 같습니다.
• 어떻게 해야할지 고민하다가 잘 작성하신분 코드를 참고했습니다.
  => 갓갓갓 플린님 링크
  => 타입스크립트로 리팩터링 하신 분
  => 개인적으로 되게 깔끔하다고 느낀 코드
• 확실히 어떤 코드가 깨끗한 코드이고 더려운 코드인지 판단 할 수 있게 된것 같습니다.

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

• 코드 형식은 의사소통의 일환이다.
  => 의사소통은 전문 개발자의 일차적인 의무다.
  => 오늘 구현한 코드의 가동성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다.
  
  
• 신문 기사처럼 작성하라
  => 이름은 간단하면서도 설명이 가능하게 짓는다.
  => 이름만 보고도 올바른 모듈을 살펴보고 있는지 아닌지를 판단할 정도로 신경 써서 짓는다.
  => 소스 파일 첫 부분은 고차원 개념과 알고리즘을 설명한다.
  => 아래로 내려갈수록 의도를 세세하게 묘사한다.
  => 마지막에는 가장 저 차원 함수와 세부 내역이 나온다.
• 변수 선언
  => 우리가 만든 함수는 매우 짧으므로 지역 변수는 각 함수 맨 처음에 선언한다.
  => 루프를 제어하는 변수는 흔히 루프 문 내부에 선언한다.    ex) for (Test each : tests)
• 인스턴스 변수
  => 인스턴스 변수는 클래스 맨 처음에 선언한다.
  => C++에서는 모든 인스턴스 변수를 클래스 마지막에 선언하는 가위 규칙을 적용한다고 한다.
  => 자바는 보통 클래스 맨 처음에 인스턴스 변수를 선언한다.
• 종속 함수
  => 한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치한다.
  => 또한 가능하다면 호출하는 함수를 호출되는 함수보다 먼저 배치한다.
  => 첫째 함수에서 가장 먼저 호출하는 함수가 바로 아래 정의된다.
       다음으로 호출하는 함수는 그 아래에 정의된다. (호출되는 함수를 찾기가 쉬워져 가독성이 높아진다.)

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

1. 프로젝트를 진행하면서 더 짧은 코드에 집중했던 적이 있었습니다.
   => 지금 생각해보면 코드가 짧은 것보다는 가독성을 중시해야 했다는 것을 알게 되었습니다.
   => 가독성을 고려해서 작성하다가 코드가 길어지면 함수로 분리를 해야겠습니다.
2. 신문기사처럼 작성하라 부분이 인상적이었습니다.
   => 저자가 처음에 얘기한 책처럼 잘 읽히는 코드를 작성해야 한다고 했었습니다.
        그 부분을 더 명확하게 제시해주는 내용이었습니다.
   => 단순히 코드에서만 해당 내용을 적용하는 게 아니라 글을 작성할 때도 위 방법을 사용해 보고 싶습니다.

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

• 적절한 행 길이를 유지하라(96p)
  => 이 부분은 전체적으로 이해가 가지 않습니다.
  => '일반적으로 큰 파일보다 작은 파일이 이해하기 쉽다' 이 부분만 눈에 들어왔습니다.
  => 200줄 정도인 파일로도 커다란 시스템을 구축할 수 있다고 저자는 얘기합니다.
• 현업에서는 더욱 자세하게 코딩 컨벤션을 정하는지 궁금합니다.
  => 프로젝트를 하면서 아쉬웠던 부분이었습니다.
       소통이 많이 부족해서 코딩 컨벤션을 정하는 시간이 거의 없었습니다.

👀 소감 3줄 요약

• 코드의 형식을 정하는 것은 개발자끼리 의사소통의 근간이다.
• 각 언어마다 코딩 형식이 다르기 때문에 그에 맞춰서 형식을 정해야 한다.
• 결국 형식을 정하는 것은 잘 읽히기 위해 정하는 것이다.

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

• 함수나 변수로 표현할 수 있다면 주석을 달지 마라
  => 함수나 변수에 정보를 담자는 것에 한 단계 더 세밀한 내용이라고 생각합니다.
  => 함수나 변수에 뚜렷한 정보를 담았다면 주석을 추가할 필요가 없다.
• 공로를 돌리거나 저자를 표시하는 주석(Bad case)
  => 코드를 작성한 사람의 이름을 작성하는 것
  => 예전에 한번 사용해볼까도 했던 부분인데 생각해보면 시간이 지나면 거짓된 정보가 될 수 있다.
  => 리팩터링을 꾸준히 거치고 다양한 사람의 손에 의해 수정된다면 저자는 필요 없을 것 같다.
  => 차라리 이런 정보는 주석이 아니라 블로그에 처음 작성했던 코드를 같이 작성하면 어떨까 싶다.
• 전역 정보와 너무 많은 정보
  => 주석을 달아야 한다면 근처에 있는 코드만 기술하라.
  => 시스템의 전반적인 정보를 기술하지 마라
  => 주석에다 흥미로운 역사나 관련 없는 정보를 장황하게 늘어놓지 마라

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

1. 주석이 소중한 정보가 될 수도 있지만, 쓸모없는 잡음 혹은 거짓된 정보가 될 가능성이 높다.
   => 위치를 표시하는 주석, 닫는 괄호에 다는 주석, 의미없이 다는 주석 등등
2. 코드에 자신이 없어서 주석으로 설명을 보충하기 위해 작성 했던 경우가 많았습니다.
   => 어떤 주석을 추가해야 할까 라는 고민보다는 코드에 어떻게 정보를 담을까를 고민해야겠습니다.
   => 예제 코드를 보면서 제가 작성했던 코드와 비슷한게 꽤 많았습니다.
   클린 코드를 보면서 해당 코드를 리팩터링 하면 재미있을 것 같습니다.

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

• 주석을 다는 것도 팀원들과 맞춰야 된다는 걸 알게 되었습니다.
  그런데 어떻게 정해야 할까 고민이 됩니다.
  => 아무래도 주석까지 팀원들과 맞춘다고는 생각을 안 할 것 같기도 합니다.
  => 현업에서는 주석까지 맞추는지 궁금합니다.
  => 저자가 작성한 마지막 예시를 보면 주석도 각 프로그래머마다 생각하는 것들이 다르다는 것을 느꼈습니다.

👀 소감 3줄 요약

• 함수와 변수에 정보를 담고 주석은 줄이자.
• 주석은 내가 작성한 코드에 자신이 없을 때 추가하는 경우가 많다.
• 우선 지울 주석부터 생각하자.

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

• 주석은 나쁜 코드를 보완하지 못한다
  => 나쁜 코드에 주석을 달지 마라. 새로 짜라 - 브라이언 W. 커니핸, P.J. 플라우거 -
  => 경솔하고 근거 없는 주석은 코드를 이해하기 어렵게 만든다.
  => 오래되고 조잡한 주석은 거짓과 잘못된 정보를 퍼뜨려 해악을 미친다.
• 주석은 오래될수록 완전히 그릇될 가능성도 커진다.
  => 프로그래머들이 주석을 유지하고 보수하기란 현실적으로 불가능하다.
• 주석을 달기로 결정했다면 충분한 시간을 들여 최고의 주석을 달도록 노력한다.

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

1. TODO 주석은 니꼬쌤의 강의에서 작성한걸 한번 보고 자주 사용하고있습니다.
   => 자주는 아니더라도 조금씩 사용하고 있던걸 봐서 내심 기분이 좋았습니다.
   => 인텔리제이에서도 TODO 주석을 검색 할 수 있다는 걸 처음 알았습니다. -> 참고 링크
2. 주석을 달면서 확실히 예전에 달았던 주석을 잘 안보게 된다는 것을 인지하게 되었습니다.

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

• 어떻게 주석을 최소화 할까?
  => 저자는 코드에 정보를 담으라고 권한다.
  => 중복되는 정보를 주는 주석은 제거
• 현재 진행했던 프로젝트는 공부를 위해 대부분의 코드에 주석이 달려있는 상태
  => 주석을 하나씩 지워 나가면서 코드명에 정보를 담는 연습 진행 예정
  => 중복되는 주석은 지워 나가기

👀 소감 3줄 요약

• 주석은 최소하 하자!
• 주석은 오래 될수록 거짓된 정보로 남게 된다.
• 리팩터링을 할 때 주석을 수정하는건 거의 불가능에 가깝다.

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

• 함수 인수 3개는 가능한 피하는게 좋고, 4개 이상은 특별한 이유가 필요하다(특별한 이유가 있어도 X).
• 함수 이름에 키워드를 추가하는 형식.
  => 즉, 함수 이름에 인수 이름을 넣는다.
  => assertEquals보다 assertExpectedEqualsActual(expected, actual)이 더 좋다.
  => 인수 순서를 기억할 필요가 없어진다.
• 명령과 조회를 분리하라!
  => 함수는 뭔가를 수행하거나 뭔가에 답하거나 둘 중 하나만 해야한다. 둘 다 하면 안된다.
  => 객체 상태를 변경하거나 아니면 객체 정보를 반환하거나 둘 중 하나다.

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

1. 이항 함수 assertEquals(expected, actual)의 문제
   => 프로젝트를 하면서 각 인수의 순서가 햇갈려서 잘못 적은 적이 많다.
   => 인수의 순서를 기억해야 하는 소요가 발생했다.
   => 저자는 이런 문제를 줄이기 위해 단항 함수로 바꾸도록 애써야 한다고 한다.
2. 아직 프로젝트 코드를 자세히 보지는 않았지만 한 함수에 명령과 조회를 같이 사용한 것 같다.
   => CRUD를 하는 기능을 제외한 부가적인 기능에서 아마 이런 경우가 있을 것 같다.

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

• 플래그 인수란?
  => 플래그 인수는 bool 인수를 말한다.
  ex> render(bool isTest); 

👀 소감 3줄 요약

• 규칙을 알고 짜는 것과 모르고 짜는 것은 차이가 많이 날 것 같다고 느꼈습니다.
• assertEquals의 예시는 실제 경험해 본 것 이라 크게 공감되었다.
• 함수는 뭔가를 수행하거나 뭔가에 답하거나 둘 중 하나만 해야한다.

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

• 함수를 작게 만들어라
  => 100줄을 넘어서는 절대 안 되고, 20줄도 길다.
  => 3000줄이나 되는 끔찍한 함수를 만들지 말자.
  => if 문/else 문/while 문 등에 들어가는 블록은 한 줄이어야 한다.
  => 중첩 구조가 생길 만큼 함수가 커져서는 안 된다. 그래야 함수는 읽고 이해하기 쉬워진다.
  
  
• 한 가지만 해라!
  => 함수는 한 가지를 해야 한다. 그 한 가지를 잘해야 한다. 그 한 가지만을 해야 한다.
  => 단순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면
       그 함수는 여러 작업을 하는 셈이다.
  
  
• 코드는 위에서 아래로 이야기처럼 읽혀야 좋다.
  => 한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다.
  
  
• 서술적인 이름을 사용하라!
  => 길고 서술적인 이름이 짧고 어려운 이름보다 좋다.

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

1. 함수를 작게 만들어야 하는 것은 많이 들어봤지만 20줄도 길다는 얘기는 조금 충격적이었습니다.
   => 잘게 나누고 명확할수록 더 읽기 좋다는 것을 알게 되었습니다.
   => if 문 안에 들어가는 로직도 함수로 뺄 수 있으면 빼봐야겠습니다.
2. 함수가 한 가지 일만 하도록 하는 것이 의미 있는 이름을 짓는데 큰 도움이 될 것 같습니다.
3. 코드를 위에서 아래로 이야기처럼 읽히도록 한다는 게 마치 처음에 나왔던 책과 비슷하다는 내용이 생각납니다.

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

• 이런 규칙을 정할 때 가장 고민이 되는 것은 같은 팀원분들과 어떻게 타협점을 잡을지입니다.
  만약에 팀원들이 이런 방식을 싫어한다면 어떻게 이해시키고 실행할지 고민됩니다.
• 회사에 입사해서 클린 코드에 나오는 방식을 사용하지 않으면 어떡할까 라는 고민도 같이 됩니다.

👀 소감 3줄 요약

• 저자가 정말 명확하게 방법을 제시해줘서 리팩터링에 큰 도움이 될 것 같습니다.
• 깨끗한 코드는 끊임없는 관심 속에 만들어진다는 것을 느꼈습니다.
• 어제도 내가 작성한 코드를 리팩터링 하지 않았는데 오늘은 명확하게 목표를 설정해야겠습니다.
  => 지금 프로젝트에서 하루에 함수 한 개 리팩터링 해보기