실무에서 바로 쓰는 Frontend Clean Code
SLASH 21 실무에서 바로 쓰는 Frontend Clean Code 세션의 내용을 정리한 글입니다.
올해 4월 말에 토스에서 'SLASH 21' 라는 개발자 컨퍼런스를 진행했다.
내가 이전에 참여한 컨퍼런스 내용들은 당장엔 쓰지 않는 막연하게 좋은 내용(?)이였기 때문에, 당시에는 이 컨퍼런스에 흥미가 없었다.
최근에 서비스 개발 업무를 하면서, 단순히 동작하는 코드를 넘어서 좋은 코드를 작성하는 법에 관해 관심이 생겼고 유튜브 검색을 통해 'SLASH 21' 영상을 접할 수 있었다.
그 중 '바로 쓰는' 이라는 워딩에 끌린 클린 코드 세션을 보게 되었고, 세션 내용이 유익해서 내 나름대로 정리 해보려고한다.
1. 실무에서 클린 코드의 의의
우리는 우리의 코드에서 어렵지 않게 지뢰코드를 찾을 수 있다.
여기서 지뢰 코드란 흐름 파악이 어렵고 도메인 맥락 표현이 안 되어 동료에게 물어봐야 알 수 있는 코드다.
이 지뢰 코드는 개발할 때는 병목, 유지보수할 때는 시간이 오래 걸리게 하며, 심하면 기능 추가가 불가능하게 한다.
성능도 안 좋은 경우가 많아 개발자와 유저, 모두에게 유쾌하지 못하다.
하지만 클린하게 코드를 작성한다면 위 문제가 해결할 수 있다.
동료나 과거의 내가 짠 코드를 빠르게 이해한다면 코드 파악, 디버깅, 리뷰 시간이 단축되어 개발 시간이 짧아진다.
자본주의 사회에서 시간 = 자원 = 돈이기 때문에,
실무에서 클린 코드는 서비스 운영에 필요한 비용을 절감하는 방법이 될 수 있다.
2. 안일한 코드 추가의 함정
안일하게 코드를 추가하게 되면 나쁜 코드가 되기 쉽다.
하나의 목적인 코드가 흩뿌려져 있거나,
하나의 함수가 여러 가지 일을 하거나,
함수의 세부 구현 단계가 제각각이게 된다.
나쁜 코드는 리팩토링을 통해 개선할 수 있다.
순서는 다음과 같다.
- 함수 세부 구현 단계 통일한다.
- 함수 이름을 각각 지어주어 로직을 구분할 수 있다.
- 하나의 목적인 코드는 뭉쳐 둔다.
- 함수가 한 가지 일만 하도록 쪼갠다.
리팩토링 이후에 오히려 코드 길이가 길어질 수 있다.
하지만 클린코드는 짧은 코드가 아니다.
클린코드는 원하는 로직을 빠르게 찾을 수 있는 코드다.
3. 로직을 빠르게 찾을 수 있는 코드
로직을 빠르게 찾을 수 있는 코드를 작성하기 위해 어떻게 해야 할까?
세션에서는 응집도, 단일 책임, 추상화 의 원칙을 지켜야 한다고 말한다.
1) 응집도
당장 몰라도 되는 디테일는 뭉치고, 코드 파악에 필수적인 정보는 표시하자.
팝업을 띄우는 이벤트가 있는 페이지가 있다.
어떤 내용의 팝업을 띄우는지, 팝업에서 버튼을 눌렀을 때 어떤 액션을 하는지가 이 페이지에서 가장 중요한 포인트다.
훅을 사용하게 되면 중요한 내용이 모두 훅 속에 가려져서 알 수 없다.
커스텀 훅에 대표적인 안티 패턴이다.
- 필수
- 팝업 버튼 클릭 시 액션, 제목, 내용
- 세부 구현
- 열고 닫을 때 사용하는 형태, 컴포넌트 마크업(버튼 클릭 시 함수를 호출해야 한다 = 바인딩)
핵심 데이터는 밖에서 전달하도록 한다.
여기서 핵심 데이터만 전달받고 세부 구현은 뭉쳐 숨겨 두는 개발 스타일을 선언적 프로그래밍이라고 한다.
선언적 프로그래밍은 무엇을 하는 함수인지 빠르게 이해가 가능하다는 장점이 있다.
세부 구현을 뭉치지 않고 하나하나 작성한 방식은 명령형 프로그래밍 이라고 한다.
세부 구현이 모두 노출되어있어 커스텀하기 쉽지만 읽는데 오래걸리고 재사용하기 어렵다는 단점이 있습니다.
선언적 프로그래밍도 내부는 명령형 프로그래밍으로 작성되어 있다.
그렇다고 선언적 프로그래밍이 무조건 좋은 것은 아니다.
JSX문법에서 HTML에도 선언적 프로그래밍 사용할 수 있는데, props로 어떤 걸 해야 하는지 넘기는 경우에는 명령형 설계도 필요하다.
2) 단일 책임
하나의 일을 하는 뚜렷한 이름의 함수를 만들자.
중요 포인트가 모두 담겨 있지 않은 함수명은 읽는 이가 예상한 대로 동작하지 않으며,
코드 신뢰 하락으로 이어져 함수명을 믿지 못하고 세부 구현을 모두 의심하는 상황을 일으킨다.
-
한 가지 일만 하는, 명확한 이름의 함수
-
한 가지 일만 하는, 기능성 컴포넌트
- 버튼 onClick에 log랑 API콜이 같이 있을 경우에 logClick이라는 컴포넌트를 만들어 버튼을 감싸는 형식으로 리팩토링한다
-
조건이 많아지면 한글 이름도 유용하다
3) 추상화
핵심 개념을 뽑아내자.
Frontend 코드의 추상화는 컴포넌트다.
함수로 추상화할 경우 중요 개념을 함수 이름에 담아 추상화한다.
정답은 없다. 상황에 따라 필요한 만큼만 추상화한다.
추상화 수준이 섞여 있으면 코드 파악이 어렵다.
실제로는 엄청 복잡한 코드를 충분히 구체적으로 작성되어있다고 잘못 판단할 수 있다.
그러므로, 코드 읽을 때 사고가 널뛰지 않게 한 레벨에 추상화 수준을 비슷하게 한다.
4. 액션 아이템
1) 담대하게 기존 코드 수정하기
2) 큰 그림 보는 연습하기
기능 추가 자체는 클린해도, 전체적으로 어지러울 수 있다.
3) 팀과 함께 공감대 형성
코드에 정답은 없으므로 팀원들과 함께 명시적으로 이야기하는 시간이 필요하다.
집단 지성을 발휘해보자.
4) 문서로 적어보기
클린 코드는 모호한 개념이다.
향후 어떤 점에서 위험할 수 있는지, 어떻게 개선할 수 있는지 글로 적어보자.
코드 작성하는 일은 글쓰기와 비슷하다는 생각이 든다.
세션을 통해 알게된 응집도, 단일 책임, 추상화 원칙을 통해 좋은 코드를 작성하기 위해 노력하겠다.
