Jinho Tech

TIL (Today I Learned)

2022.03.08

오늘 읽은 범위

10장 클래스

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

• 클래스는 작아야 한다! -> 간결한 이름이 떠오르지 않는다면 클래스 필경 클래스 크기가 너무 커서 그렇다 (p.172)
• 단일 책임 원칙(Single Responsibility Principle,  SRP) -> 클래스나 모듈을 변경할 이유는 하나뿐이어야 한다 (p.175)
• 응집도(Cohesion) (p.177)
  클래스는 인스턴스 변수 수가 작아야 한다. 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 한다.
  일반적으로 메서드가 변수를 더 많이 사용할수록 메서드와 클래스는 응집도가 높다. 응집도가 높다는 말은 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다는 의미이기에, 우리는 응집도가 높은 클래스를 선호한다. 
• 함수를 작게, 매개변수 목록을 짧게라는 전략을 따르다 보면 때때로 몇몇 메서드만이 사용하는 인스턴스 변수가
  많아지는데, 이는 새로운 클래스로 쪼개야 한다는 신호이다. 응집도가 높아지도록 변수와 메서드를 적절히 분리해 새로운 클래스 두세 개로 쪼개도록 하자 (p.178)
• 개방-폐쇄 원칙(Open-Closed Principle, OCP) -> 클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다 (p.188)
• 의존관계 역전 원칙(Dependency Inversion Principle, DIP) -> 클래스는 상세한 구현이 아니라 추상화에 의존해야 한다

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

이번 10장은 응집도 관련된 내용을 제일 재미있게 읽었던 것 같다. 변수, 메서드, 클래스의 응집도를 생각하면서

클래스를 구현해본 적도 없었고, 변수와 메서드의 응집도를 높일수록 클래스가 작게 쪼개질 수밖에 없겠구나라는

생각이 들었기 때문이다. 이 책을 읽으면 읽을수록 학습한 내용들을 바탕으로 코드를 짜고 싶다는 생각이 계속 든다.

스프링 공부를 좀 더 빠르게 해서 프로젝트를 진행해봐야겠다. 

TIL (Today I Learned)

2022.03.06

오늘 읽은 범위

9장 단위 테스트

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

• TDD 법칙 세 가지
  - 첫째 법칙: 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
  - 둘째 법칙: 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
  - 셋째 법칙: 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
• 테스트 코드는 실제 코드 못지않게 중요하다 -> 테스트 코드가 복잡할수록 실제 코드를 짜는 시간보다 테스트 케이스를 추가하는 시간이 더 걸리기 십상이다 (p.156)
• 테스트는 유연성, 유지보수성, 재사용성을 제공한다 -> 테스트 케이스가 있으면 변경이 쉬워지기 때문이다 (p.157)
• 테스트 코드도 가독성이 좋아야 한다. 어쩌면 가독성은 실제 코드보다 테스트 코드에 더더욱 중요하다 (p.158)
• 이중 표준 -> 실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있다. 대게 메모리나 CPU 효율과 관련 있는 경우다. 코드의 깨끗함과는 철저히 무관하다 (p.164)
• 개념 당 assert 문 수를 최소로 줄여라 -> 때로는 함수 하나에 여러 assert 문을 넣을 수도 있지만, assert문 개수는 최대한 줄이는 것이 좋다 (p.165)
• 테스트 함수 하나는 개념 하나만 테스트하라 (p.166)
• 깨끗한 테스트는 F.I.R.S.T 규칙을 따르는데
  - 빠르게(Fast): 테스트는 빨라야 한다.
  - 독립적으로(Independent): 각 테스트는 서로 의존하면 안 된다.
  - 반복 가능하게(Repeatable): 테스트는 어떤 환경에서도 반복 가능해야 한다.
  - 자가 검증하는(Self-Validating): 테스트는 부울 값으로 결과를 내야 한다.
  - 적시에(Timely): 테스트는 적시에 작성해야 한다.

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

아직 자바로 테스트를 해본 적이 없어서 이해가 잘 되지는 않았다만, 다음에 테스트를 공부하게 된다면 지금 본 

내용이 학습에 큰 도움이 될 것 같다는 생각이 들었다.

TIL (Today I Learned)

2022.03.04

오늘 읽은 범위

7장 오류 처리

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

• 오류 코드보다 예외를 사용하라 -> 논리가 오류 처리 코드와 뒤썩이지 않으므로 호출자 코드가 깔끔해진다 (p.130)
• Try-Catch-Finally 문부터 작성하라 -> try블록에서 무슨 일이 생기든 호출자가 기대하는 상태를 정의하기 쉬어진다(p.132)
• 미확인(unchecked) 예외를 사용하라 -> 확인된 예외를 사용할 경우, 하위 단계에서 코드를 변경하면 상위 단계 메서드 선언부를 전부 고쳐야 하는 경우가 생길 수도 있다 (p.133)
• 예외에 의미를 제공하라 (p.135)
• 특수 사례 패턴 -> 클래스를 만들거나 객체를 조작해 특수 사례를 처리하는 방식 -> 클래스가 예외적인 상황을 캡슐화해서 처리하므로, 클라이언트 코드가 예외적인 상황을 처리할 필요가 없어진다 (p.137)
• null을 반환하지 마라 -> 메서드에서 null을 반환하고픈 유혹이 든다면 그 대신 예외를 던지거나 특수 사례 객체를 반환하는 것이 좋다. (p.137)
• null을 전달하지 마라 -> 정상적인 인수로 null을 기대하는 API가 아니라면 메서드로 null을 전달하는 코드는 최대한 피한다 -> 대다수 프로그래밍 언어는 호출자가 실수로 넘기는 null을 적절히 처리하는 방법이 없다. 그러니까 애초에 null을 전달하지 말도록 하자 (p.140)
• 오류 처리를 프로그램 논리와 분리하면 독립적인 추론이 가능해지며 코드 유지보수성도 크게 높아진다 (p.142)

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

여태까지 오류를 처리할만한 코드를 작성해본 적이 없었던 것 같은데, 타이밍 좋게 잘 읽은 것 같다.

다음에 프로젝트를 하게 된다면 오늘 읽은 내용을 생각하면서 오류를 잘 분리하여 처리해봐야겠다.

TIL (Today I Learned)

2022.03.01

오늘 읽은 범위

6장 객체와 자료구조

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

• 변수 사이에 함수라는 계층을 넣는다고 구현이 감춰지지는 않는다. 구현을 감추려면 추상화가 필요하다 (p.119)
• 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다 (p.119)
• 디미터 법칙 -> 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다 (p.123)
• 잡종 구조 -> 절반은 객체, 절반은 자료 구조인 구조 -> 함수나 타입을 보호할지 공개할지 확신하지 못해서 나오는 어중간한 설계인데, 되도록 피하도록 하자
• 새로운 자료 타입을 추가하는 유연성이 필요하면 객체, 새로운 동작을 추가하는 유연성이 필요하면 자료구조와 절차적인 코드가 더 적합하다 (p.128)

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

최근에 자바 공부를 시작했었는데 이렇게 객체 지향 관련 글은 보니 복습이 된 것 같다. 하지만 다시 봐도 꽤 어렵게

느껴진다. 실제로 프로젝트를 해서 뭔가를 좀 만들어봐야 감을 잡을 수 있을 것 같다. 

제일 기억에 남는 말은 우수한 소프트웨어 개발자는 편견 없이 직면한 문제에 최적인 해결책을 선택한다이다.

결국 개발자가 해야 하는 것이 문제 해결인데 그에 딱 맞는 말인 것 같다. 

TIL (Today I Learned)

2022.02.28

오늘 읽은 범위

5장 형식 맞추기

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

• 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다 (p.96)
• 신문 기사처럼 작성하라(고차원 개념과 알고리즘에서 저차원 함수와 세부 내역 순서로 묘사하자) (p.97)
• 줄 바꿈이 개념을 분리한다면 세로 밀집도는 연관성을 의미함 -> 밀접한 코드는 세로로 가까이 놓여야 함 (p.100)
• 변수는 사용하는 위치에 최대한 가까이 선언, 인스턴스 변수는 클래스 맨 처음에 선언 (p.101, 103)
• 한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치 -> 가능하면 호출하는 함수를 위로 배치 (p.103)
• 개념적인 친화도가 높을수록 코드를 가까이 배치한다 (p.106)
• 코드 스타일은 일관적이고 매끄러워야 한다. 한 소스 파일에서 봤던 형식이 다른 소스 파일에도 쓰이리라는 신뢰감을 독자에게 줘야 한다 (p.114)

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

5장은 코드 형식에 대한 이야기를 하고 있다. 전에 42 Seoul에 참여할 때 코드 형식 때문에 고민했던 일이 기억나서 

그런지 되게 재미있게 읽었다. 제일 기억에 남는 말은 신문 기사처럼 작성하라이다. 아래로 내려갈수록 의도를 세세하게

묘사하라는 의미인데, 어떤 느낌인지 확 이해가 돼서 그런지 기억에서 잊혀지 것 같지가 않다.   

TIL (Today I Learned)

2022.02.27

오늘 읽은 범위

4장 주석

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

• 코드만이 자기가 하는 일을 진실되게 말한다 (p.69)
• 주석은 나쁜 코드를 보완하지 못한다 -> 주석을 가능한 줄이도록 꾸준히 노력해야 한다 (p.69)
• 코드로 의도를 표현하라 (p.70)
• 이해가 안 되어 다른 모듈까지 뒤져야 하는 주석은 독자와 제대로 소통하지 못하는 주석이다 (p.76)
• 주석으로 처리한 코드는 밉상이다 -> 웬만하면 지우자 (p.86)

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

4장은 주석을 만약 쓰게 된다면 이런 경우에 사용하자라는 내용을 담고 있다. 법적 정보, 기본적 정보 제공, 의도 설명, 

경고, TODO, 강조 등등이 좋은 주석이고 나머지는 안 좋은 주석이다. 이런 것들은 코드에 대한 설명보다는 정보를 

제공하는 것이라 꼭 필요한 것 같다. 

제일 인상 깊었던 말은 주석은 나쁜 코드를 보완하지 못한다이다. 항상 정보를 제공하기 위한 주석보다는 내 코드에

대한 부연설명을 하기 위해 주석을 많이 썼던 것 같은데, 앞으로는 의식하면서 주석을 줄여나가야겠다.

이 책을 안 읽었으면 이런 생각을 못했을 것 같기에 읽기 잘했다는 생각이 들었다! 

TIL (Today I Learned)

2022.02.22

오늘 읽은 범위

3장 함수

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

• 작게 만들어라! -> 중첩 구조가 생길 만큼 함수가 커져서는 안 된다 (p.42, 44)
• 함수는 한 가지를 해야 한다. 그 한 가지를 잘해야 한다. 그 한 가지만을 해야 한다 (p.44)
• 함수당 추상화 수준은 하나로! -> 일련의 TO 문단을 읽듯이 프로그램이 읽혀야 한다 (p.45, 46)
• 서술적인 이름을 사용하라! (p.49)
• 함수 인수 -> 인수는 개념을 이해하기 어렵게 만든다 -> 3개 이상부터는 좀... 그렇다 (p.50)
• 명령과 조회를 분리하라! (p.56)
• 오류 코드보다 예외를 사용하라! -> try / catch 블록을 별도 함수로 뽑아내는 편이 좋다. (p.57, 58)
• 반복하지 마라! -> 중복은 소프트웨어에서 모든 악의 근원이다. 많은 원칙과 기법이 중복을 없애거나 제어할 목적으로 나왔다 (p.60)

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

제일 인상 깊었던 글은 반복하지 마라이다. 앞에서 나온 작게 만들어라, 한 가지만 잘 돌아가게 해라, 추상화 수준을

하나로 해라 등등이 다 포함하는 내용이라고 생각하기 때문이다. 그리고 인수 관련된 내용도 참 좋았는데 평소에

함수에 인수를 3, 4개씩 박았던 기억이 있어서 앞으로는 주의해야겠다는 생각이 들었다.

TIL (Today I Learned)

2022.02.20

오늘 읽은 범위

2장 의미 있는 이름 

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

• 의도를 분명히 밝혀라 -> 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다 (p.22)
• 그릇된 정보를 피하라 -> 일관성이 떨어지는 표기법은 그릇된 정보다 (p.24, 25)
• 의미 있게 구분하라 -> 읽는 사람이 차이를 알도록 이름을 지어라 (p.25, 27)
• 검색하기 쉬운 이름을 사용하라, 긴 이름이 짧은 이름보다, 검색하기 쉬운 이름이 상수보다 좋다 (p.28)
• 단 이름 길이는 범위 크기에 비례해야 한다 (p.28)
• 클래스 이름 -> 명사, 명사구(Customer, Account), 메서드 이름 -> 동사, 동사구(postPayment, deletePage) (p.32)
• 한 개념에 한 단어를 사용하라 -> 메서드 이름은 독자적이고 일관적이어야 한다 (p.33)
• 의미 있는 맥락을 추가하라 -> 맥락만 개선해도 함수 쪼개기가 쉬워지고 알고리즘도 좀 더 명확해진다 (p.35)

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

변수나 함수, 클래스의 이름을 고민하는 것은 코딩 공부를 해본 사람이라면 모두가 공감할 내용인 것 같다.

나는 그럴 때마다 깊게 고민하지 않고 당장 납득이 가는 이름? 정도로 타협해서 구현만 했었던 것 같다.

이렇게 짠 코드는 시간이 지나고 봤을 때 정확하게 무슨 동작을 하는 코드였는지 기억이 안나는 경우가 대부분이었다. 

내 코드도 다시 해석해야 되는데 다른 사람이 보기에는 얼마나 답답했을까라는 생각이 처음으로 들었다.

오늘 제일 기억에 남는 글은 의도를 분명히 밝혀라이다. 생각해보면 함수나 클래스의 의도가 확실하지 않을수록 내

주석이 길어졌던 것 같다. 주석이 필요 없는 코드가 1장에서 말했던 아름다운, 읽는 재미가 있는 코드가 아닐까 싶다!  

TIL (Today I Learned)

2022.02.19

오늘 읽은 범위

1장 깨끗한 코드 

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

• 깨끗한 코드는 ‘보기에 즐거운’ 코드다. (p.9)
• 깨끗한 코드는 잘 쓴 문장처럼 읽힌다. 깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다. (p.10)
• 깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다. (p.11)
• 깨끗한 코드는 주의 깊게 작성한 코드다. (p.12)
• 중복을 피하라. 한 기능만 수행하라. 제대로 표현하라. 작게 추상화하라. (p.14)
• 새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다. 비율이 이렇게 높으므로 읽기 쉬운 코드가 매우 중요하다. (p.18)
• 보이스카우트 규칙: 캠핑장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라. (p.19)

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

말그대로 클린코드, 깨끗한 코드란 무엇일까에 대해 설명하는 챕터이다. 제일 와닿았던 설명은 "깨끗한 코드는 보기에 즐겁고, 잘 쓴

문장처럼 읽힌다" 였던 것 같다. 평소에 코드를 짤 때 구현만 하고 리팩토링을 안 해본 나로선 배울 수 있는 것이 엄청 많을 책인 것 같고, 

나중에 직장 동료들이 내 코드를 봤을 때 짜증나고 답답하기보다는 즐거운 게 좋지 않을까라는 생각도 들었다.

클린코드 책 인증~