실무에서 클린코드의 의의
코드 파악, 디버깅 , 리뷰 => 유지보수 시간의 단축💥
시간 = 자원 = 돈
처음엔 클린했지만 기존 코드에 기능을 추가하는 상황이라면? 자칫 잘못하면 지뢰코드를 만들어 버릴 수 있다.
지뢰코드란?
흐름 파악이 어렵고 도메인 맥락 표현이 안 되어 동료에게 물어봐야 알 수 있는 코드
안일한 코드 추가의 함정
원하는 로직을 빠르게 찾으려면?
하나의 목적인 코드가 흩뿌려져 있다 => 응집도를 높이자
하나의 함수가 여러 가지 일을 하고 있다. => 단일책임으로!
함수의 세부 구현 단계가 제각각이다. => 추상화!
클린 코드 == 로직을 빠르게 찾을 수 있는 코드
1. 응집도 - 같은 목적의 코드는 뭉쳐두자
흩뿌려져 있는 코드는 파악도 한 번에 안되고 버그 발생 위험도 높다.
but 무조건 뭉치기만 한다면?
=> 오히려 어려워진 코드파악. 커스텀훅의 안티패턴
무엇을 뭉쳐야 하는가?
뭉치면 쾌적 => 당장 몰라도 되는 디테일
뭉치면 답답 => 코드 파악에 필수적인 핵심 정보
클린 코드 != 짧은 코드
클린 코드 == 찾고 싶은 로직을 빠르게 찾을 수 있는 코드
코드 응집 Tip : 핵심 데이터와 세부 구현 나누기
=> 핵심 데이터는 밖에서 전달, 나머지는 뭉친다.
선언적 프로그래밍
- 핵심 데이터만 전달받고 세부 구현은 뭉쳐 숨겨 두는 개발 스타일
- 특징 : 무엇을 하는 함수인지 빠르게 이해가 가능하다는 것
세부 구현은 안쪽에 뭉쳐두어서 신경 쓸 필요가 없다는 것
그리고 무엇만 바꿔서 쉽게 재사용할 수 있다는 점
뭉치지 않았다면? 명령형 프로그래밍
어떻게 해야 할지 하나하나 명령하기
읽는데 오래걸리고 재사용하기 어렵다는 단점
선언적인 코드가 무조건 좋은가?
No. 두 방법 모두 유동적으로 사용하여야 한다.
2. 단일책임 - 하나의 일을 하는 뚜렷한 이름의 함수를 만들자
중요 포인트가 모두 담겨 있지 않은 함수명 => 위험
기능 추가 시 함수는 더욱 잡탕이 되어버린다.
이러한 기능 추가가 반복될 시 지뢰코드가 되어버린다.
리팩토링 Tip
- 한 가지 일만 하는, 명확한 이름의 함수
- 한 가지 일만 하는, 기능성 컴포넌트
- 조건이 많아지면 한글 이름도 유용
3. 추상화 - 핵심 개념을 뽑아내자
프론트엔드 코드의 추상화 : 컴포넌트, 함수
얼마나 추상화할 것인가?
답은 없다. 상황에 따라 필요한 만큼 추상화하면 된다.
추상화 수준이 섞여 있으면 코드 파악이 어렵다.
=> 한 레벨의 코드 안에 추상화 수준이 섞여 있으면 코드 파악이 어렵다. 추상화 단계를 비슷하게 정리 추상화 수준이 높은 것끼리, 또 낮은 것끼리 모은다.
4. 액션 아이템
1. 담대하게 기존 코드 수정하기
두려워하지 말고 기존 코드를 씹고 뜯고 맛보고 즐기자
2. 큰 그림 보는 연습하기
그 때는 맞고 지금은 틀리다. 기능 추가 자체는 클린해도, 전체적으로는 어지러울 수 있다.
3. 팀과 함께 공감대 형성하기
코드에 정답은 없다. 명시적으로 이야기를 하는 시간이 필요하다.
4. 문서로 적어 보기
글로 적어야 명확해진다.
향후 어떤점에서 위험할 수 있는지? 어떻게 개선할 수 있는지?
토스ㅣSLASH 21 - 실무에서 바로 쓰는 Frontend Clean Code
https://youtu.be/edWbHp_k_9Y
개발을 시작한지 얼마 되지 않은 나에게 어떻게 보면 먼 얘기처럼 들릴 수 있는 이야기이지만 내가 목표로 하는 함께 일하고 싶은 개발자, 좋은 코드를 만들고 싶은 개발자가 되기 위해서는 절대 놓칠 수 없는 내용이기에 기록해두고 두고두고 보려고 한다💥💥💥
