응집도 / 단일책임 / 추상화

 

실무에서 클린 코드의 의의 = 유지보수 시간의 단축 

시간 = 자원 = 돈

 

클린 코드 != 짧은 코드

== 원하는 로직을 빠르게 찾을 수 있는 코드

 

코드에 살을 붙일 때마다 함정에 빠지기 쉽다.

 

하나의 목적인 코드가 흩뿌려져 있다. (응집도)

하나의 함수가 여러 가지 일을 하고 있다. (단일책임) -> 세부 구현을 모두 읽어야 함수의 역할을 알 수 있게 된다.

함수의 세부구현 단계가 제각각이다. (추상화)

---

응집도

무엇을 뭉쳐야 하는가? -> 당장 몰라도 되는 디테일 

뭉치면 안되는가? -> 코드 파악에 필수적인 핵심 정보 (버튼을 눌렀을 때 무슨 액션이 취해지는가? 같은)

 

읽기 좋게 응집할 수 있는법

남겨도 될 핵심 데이터와 세부 구현을 나눠보기 

ex)  핵심 : 팝업 버튼 클릭 시 액션, 제목, 내용

세부구현 : 팝업 열고 닫을 때 사용하는 상태, 컴포넌트 마크업, 버튼 클릭 시 특정 함수를 호출해야하는 바인딩

=> 훅 안에 전부 숨기지 말기!

==> 선언적 프로그래밍 무엇을 하는 함수인지 빠르게 이해가 가능하다.

==> 명령형 프로그래밍 : 어떻게 해야 할지 하나하나 명령하기 (세부 구현이 모두 노출되어 있어서 이를 커스텀하기는 쉽지만 읽는데 오래 걸리고 재사용이 어려움)

 

선언적 코드가 무조건 좋은 건 아니고 두 방법 모두 유동적으로 사용하면 된다! 

---

단일책임

중요 포인트가 모두 담기지 않은 함수명 > 위험 

기능 추가 시에 함수는 더 복잡해진다. > 함수 이름이랑 기능이랑 점점 멀어진다!

=> 한 가지 일만 하는 함수로 쪼개기

ex) 버튼 클릭 함수에 로그 찍는 함수, api 콜이 섞임 > 로그는 버튼을 감싼 컴포넌트에서 찍고, 버튼 클릭함수에서는 api콜만 신경쓰기.

(조건이 많아지면 한글 이름도 유용하다)

---

추상화

로직에서 핵심 개념을 뽑아내자.

상황에 따라 필요한 만큼 추상화 하기

추상화 수준이 섞여 있으면 코드 파악이 어렵다. -> 추상화 단계를 비슷하게 정리, 수준이 비슷한 것끼리 정리하기

 

---

1. 담대하게 기존 코드 수정하기 / 구조 뜯기를 두려워하지 말기 마더 브랜치 따서 리팩토링 PR 따로 두기

2. 큰 그림 보는 연습하기 / 기능 추가 자체는 클린해도, 전체적으로 어지러울 수 있다.

3. 팀과 함께 공감대 형성하기 

4. 문서로 적어보기 / 향수 어떤 점에서 위험할 수 있는지, 어떻게 개선할 수 있는지 

 

 

유튜브에서 우연히 보게 된 토스의 작년 슬래쉬 영상. 실무에서 어떤 식으로 짜이는지 설명해주시는 부분이 좋았다. 코드를 짜면서 맨날 주먹구구식으로 짰던 내가 생각났다. 사실 가장 먼저 봤어야 할 부분이 클린코드가 아닐까 싶다. 도서관에서 클린 코드 책 빌려와서 봐야지. 🥰