[tidy first?] 독후감

 

Tidy First? | Kent Beck - 교보문고

 

tidy first를 읽어봤다.

책이 얇고 저자가 하고자하는 말이 명확해서 가볍게 읽을수있었음

 

책에서는 경제적인 용어를 사용해서 여러 논리를 적었는데, 하고자하는말은 명확했다고 생각함!

그래서 결론을 먼저 말해보겠다.

결론

1. 작은단위로 자주 리팩토링을 해라!
2. 결합도와 응집도를 개선하는 방향으로의 작은 리팩토링
3. 아무 이유없이 하던 작업을 이제 논리를 주장하면서 할수있다.

 

사실 책을 읽고 처음에는 내용이 왤케 쉽지..?라고 생각이 들었다.

그런데 사실 이런 사소한 작업들이 코드의 디테일에 많은 영향을 주기때문에, 읽다보니 공감이 가는 부분도 많았다.

그래서 책의 내용 정리라기보다는, 내가 코드를 짜면서 적용해볼수있을법한 부분만 정리해보겠다.

내용

• 소규모 설계
  • 지저분한 코드가 있는데, 이 코드를 바로 변경해야할까? 아님 코드정리를 먼저 해야할까에 대한 고민

---

• 디자인 패턴이나, 리팩터링의 약점은 거대하게 느껴진다는것이다.
• 소프트웨어 설계를 잘 하고싶다면 하루에 여러번 설계고민을 하고 실천을 해봐야한다.

---

• 의미가 잘 전달되는 코드를 작성하려면 코드의 겉모습도 신경써야한다. 알고리즘이 코드의 내용이면, 코드의 겉모습은 곧 형식이다. 이 책은 그런 형식에 대한 책이다.
• 켄트백은 이 책을 통해 코드를 형식적인 측면에서 깔끔하게 작성하는 방법을 알려준다.
• 아주 작은 수준의 리팩터링!
• 컴퓨터 코드의 복잡성은 코드가 부분으로 조직되는 방식, 각 부분 사이의 결합도, 그리고 각 부분들 사이의 응집도에 따라 달라진다.
• 구체적인것에서 출발해 추상적인 것으로 나아가는 학습을 선호

아래부터는 책에 나오는 실제 코드 작성 방식에 대한 정리임

그리고 주석처럼 달린 부분은 이 글을 읽으면서 본인의 코드작성방식에 대해 한번 고민해봤으면 하는 질문을 적어봤습니당

01. 보호구문

• 얼리리턴
• 하나의 루틴에는 하나의 반환문(반환문의 형태를 맞추라는 말인것같다)

하나의 루틴에 하나의 반환을 맞추면서 작성하는지?
반환값의 형태를 맞춰주기!!
반환타입을 미리 정해놓으면 tdd의 효과도 있다

const test = () => {
    if(1) {
    	return {};
	}
    if(2) {
    	return {};
    }
    return {};
}

02. 안쓰는 코드

• 코드를 조금만 삭제해라.
• 예를들어 조건 내용을 정해서 true를 반환할수도있고, 루틴하나, 파일하나, 디렉토리 하나정도로 해나갈수있다.

사용하지않는 코드를 어떻게 처리하는지?

03. 대칭으로 맞추기

• 동일한 액션을 한가지 패턴으로 맞춰서 작성해라
• 하나의 파일에서 다른 팀원이 작성한 함수가 본인의 코딩 스타일과 맞지않아도 스타일을 맞추면서 작성해라

다른 팀원이 작성한 코드의 컨벤션을 맞춰가면서 작성하시나요?

04. 새로운 인터페이스로 기존 루틴 부르기

• 통로 인터페이스
• 루틴을 호출해야하는데, 기존인터페이스때문에 어렵거나 복잡하거나 혼란스러우면 인터페이스를 새롭게 구현해서 호출해라

---

• 거꾸로 코딩하기 : 루틴의 마지막줄부터 시작해봐라. 반환값을 먼저 정하기
• 테스트 우선 코딩 : 테스트부터 작성하여 통과 조건을 정한다.

05. 읽는 순서

• 코드를 읽을때는 독자의 입장이 되어봐라
• 전체 파일의 순서를 바꾸는대신에, 읽는 순서가 영향을 크게주는것부터 바꾸세요

코드 순서 어떻게 정하시는지?!

06. 응집도를 높이는 배치

• 같은 루틴을 가지는 코드가잇으면 근처에둬라. 두 루틴에 결합도가 있으면!!
• 두 파일에 결합도가있으면 같은 디렉토리에 넣어라.
• 일단은 결합도를 제거하는것이 좋긴하다. 만약 결합도를 제거하는것에 대한 부담이있다면, 응집도를 높이는것에 초점을 맞춰봐라

07. 선언과 초기화를 함께 옮기기

• 변수선언과 초기화 위치는 종종 서로 떨어져있다.
• 변수 초기화는 이름이 주는 의미를 더 강화한다.
• 만약 선언과 초기화가 떨어져있다면 변수가 어떤 맥락에서 선언되었는지 잊어버릴지도 모른다.
• 작은 수준의 코드 정리를 시작해봐라.

저는 리액트를 주로 쓰는데, state를 비동기적으로 초기화를 해야하는경우에 useState, useEffect 코드를 커스텀훅으로 빼기도함
state+effect 코드가 파일내부에 3쌍 이상 생기면 코드가 너무 길어지기도하고, 코드안에 여러 역할이생긴다고 생각해서 가독성이 안좋아진다고 생각해서 분리하는 편

08. 설명하는 변수

• 코드의 표현식이 너무 장황해지면 중간중간에 변수에 할당해 맥락파악에 용이하도록 수정한다.

// 장황
const result = pipe(arr, A.filter, arr,A.map, O.fromEntires,O.keys);


// 중간중간에 문맥 끊어주기
const arr = pipe(arr, A.filter, A.map);
const obj = pip(arr, O.fromEntires,O.keys);

09. 설명하는 상수

• 상징적인 상수를 만들어라. 리터럴 상수로 사용된곳은 상징적인 상수로 바꿔라.

리터럴 값은 무조건 상수로 선언해서 쓰시나요?

const ONE_HOUR = 1_000 * 6_000

11. 비슷한 코드끼리

• 코드의 문맥이 다를땐 두 코드사이에 빈 줄을 넣는것부터 시작해볼수있다. 간단한것부터 시작!
• 소프트웨어 설계가 큰일이 되면, 설계 작업을 아예 그만두고싶은 위험에 직면한다. 그러나 적절한 소프트웨어 설계는 변화를 가능하게한다. 작은 소프트웨어 설계로 변화를 좀 더 쉽게 만들수있다
• 제대로 된 소프트웨어 설계는 유연성을 확보하지만, 그렇지못한 경우는 변화자체를 망각하고 소프트웨어 설계의 소용돌이에 빠질수 있다.

12. 도우미 추출

• 코드를 보다가 루틴 속 코드중에서 목적이 분명하고 나머지 코드와는 상호작용이 적은 코드 블록을 만날때가 있다.
• 그 코드 블록을 추려내고, helper 도우미로 추출한 후에 이름을 붙인다.
• 메서드 추출 리팩토링

13. 하나의 더미

• 코드를 만드는데, 가장 큰 비용이 들어가는 일은 코드 작성이 아니라 읽고 이해하는 데 드는 비용입니다.
• 때로는 코드가 여러개의 작은 조각으로 나뉘어져있기도한데, 흩어져있으면 전체적으로 이해하기 어렵다. 필요한만큼의 코드를 하나의 더미처럼 느껴질때까지 흩어진 코드를 모아라.
• 명확성을 찾으려면 먼저 코드를 한데 모아서 이해하기 어려운 부분은 추출해서 새롭게 정리해야한다. > 이것도 좋은방법이라고 생각함!!

14. 설명하는 주석

• 코드에서 명확하지 않은 내용만 골라 적어라.
• 다른 사람의 관점에서 생각하고 예상되는 질문을 선제적으로 언급하려고 노력해야한다.

15. 불필요한 주석 지우기

• 코드만으로 내용을 모두 이해할수있다면 주석은 모두 제거해라.
• 코드를 작성하는 목적은 다른 프로그래머에게 컴퓨터가 해야할 일을 설명하는데있다.
  • 코드는 컴퓨터에게 지시하는 용도가 1차 목표이지만, 코드를 정리해서 읽는 사람도 이해하기쉽게 하는일이 결국 설계행위라는 생각에 바탕을 둠

16. 코드 정리 구분

• 코드 정리는 별도의 PR로 만들고, 가급적 PR당 몇개의 코드정리만 넣는다.
• 코드 리뷰받을때 범위가 너무 넓어지기때문에 코드정리와 동작변경은 다른 PR로 분리한다.
• 코드 정리와 동작 변경을 섞지않아야한다.

18. 코드 정리의 일괄 처리량

• 코드 정리는 먼 미래를 바라보는것이 아니기때문에 즉각적인 필요를 다뤄야한다.
• 저자는 코드를 먼저 정리하는것을 선호하지만, 정리 그 자체를 목적으로 삼지않도록 경계해야한다.

 

 

 

감상평

1. 책을읽고 당장 개발할때 적용할수있을법한 내용이 많아서 좋았음
2. 리팩토링이라는것이 크게만 느껴졌었는데, 정말 일을하면서 잠깐 몇분씩만 쓰면서 작업할수있을법한 내용이 많아서 리팩토링에 대한 부담을 많이 줄여준다
3. 리팩토링에 경제학의 관점을 도입해서 설명한게 인상적이었다. 개발에 경제적 가치를 두면서 생각해본적은 없는데, 색다른 관점이기도했고 흥미로운 내용이었음!