[FE] 실무에서 바로 쓰는 Frontend Clean Code

 📄 참고자료

토스 실무에서 바로 쓰는 Frontend Clean Code 

https://www.youtube.com/watch?v=edWbHp_k_9Y

---

💬 들어가기전 주저리

기술블로그와 여러 기술 아티클을 탐방할 때, 클린코드(clean code) 란 용어를 자주 본다.

👈 요런, 클린코드 서적을 추천하는 게시글이나 주변 개발자도 봤었다.

그래서 "클린코드" 가 무엇이냐~ 라고 물어본다면, 

 

중복되는 코드 줄이는 방법

가독성이 쉬운 코드를 작성하는 방법

유지보수가 쉬운 코드를 작성하는 방법

이라 할 수 있다.

 

중복,가독성,유지보수.. 멋진 용어다. 이건 클린코드에 대해 검색하면 나오는 정말 군더더기 없는 설명이다.

 

사실, 개인적으로, 내가 느끼는 클린코드에 대한 정의는, 개발자의 원활한 소통과 업무를 위한 도구 라고 생각한다.

 

- 새로운 기능 추가 후 PR 올릴 때

- 기능을 구현하는 도중, 어려움이 생겨 코드 질문을 할 때

- 기능 추가를 위해 기존 코드를 수정할 때

- 유지보수를 위해 기존 코드를 수정할 때

 

.. 등등. 우리는 코드를 작성하면서 동료들과 혹은 선배들과 소통을 한다.

그 소통을 할때 필요한건 코드 인데..

이 코드가 상대방이 이해하기 어렵다거나, 당장 내가 수정을 해야하는 데 코드 파악이 안되면 ... (ㅋㅋ)

미래의 나를 위해, 옆의 동료를 위해 우리는 언제나 클린코드를 염두하며 업무를 하는 것이 좋다.

 

위의 토스영상은 실무에서 프론트앤드 개발자가 클린코드를 지키는 방법에 대해 설명해준다.

그리고 이 게시글은 영상의 내용이 담겨있다.

---

🥇 실무에서 클린코드의 의의

클린코드가 의미있는 이유는 무엇일까?

클린코드가 적용이 안되어있다면 그것은 읽기어려운 코드라 볼 수 있다.

그러한 코드들은,

 

• 코드를 읽고 이해하느라 개발할때 병목이 되고
• 유지보수할때 시간이 오래 걸리며
• 기능추가가 어렵고 성능이 좋지않을 것이다.

 

동료, 과거의 내가 빠르게 이해할 수 있다면

유지보수할 때 드는 개발 시간이 짧아진다.

 

물론, 버그가 났을 때 디버깅 시간도 단축된다.

---

 

🥈 안일한 코드 추가의 함정

물론 처음 코드를 설계하고, 새로운 파일에서 짤땐 코드는 깨끗하다.

만약에 기존 코드에 기능을 추가하는 상황이라면 어떨까?

👈 같은 기능 추가요청이 들어왔다 해보자.

보험에 대한 질문을 입력하는 페이지 이다.

AS-IS

- 보험 질문 입력

- 질문등록 팝업

- 확인

 

TO-BE:

- 보험 질문 입력

- 내 설계사가 있으면? >

- 설계사 사진이 들어간 팝업을 먼저 띄워달라.

 

 

좌측: 기존코드 - 우측: 새 기능 추가

기존 코드에 새로운 기능을 추가하면 어떻게 하면 될까?

질문하기 클릭 함수에, 나의 설계사가 있으면, 팝업을 노출하면 된다!

 

설계대로 코드개발하면 아래와 같다.

나의 설계사가 있으면, popupOpend 가 true  > 연결 전문가 팝업 show ! > 클릭시 > 연결 전문가 질문 전송 !

 

기능추가구현은 완성되었으나.. 

이 코드에는 심각한 함정들이 있다.

 

😞 하나의 목적인 코드가 흩뿌려져 있다.

초록색으로 강조한 코드가 모두 연결중인 전문가 팝업 관련 코드 인데.

목적이 같은 코드들이 한 페이지(한 파일)에 흩뿌려져 있다.

이러한 코드는 나중에  또 기능 추가할 때 스크롤을 위아래로 이동하면서 코드를 이해해야 한다.

 

😞 하나의 함수가 여러가지 일을 하고 있다.

위의 함수는 `handleQuestionSubmit` 으로, 이름만 보면 "질문을 전송하는 submit 핸들러 함수구나 ~" 이해할 수 있다.

하지만, 실제 내부에 세부 구현된 코드를 보면 이름과 다르다.

1. 연결 전문가 정보를 받아오고 > 있으면 팝업을 띄우고
2. 약관 동의를 받아오고 > 약관동의를 안했으면 팝업을 열고
3. 위의 두 단계가 모두 통과가 되어야 ! 질문이 전송

`handleQuestionSubmit` 라는 함수에 실제로, 위의 세가지 기능을 하고 있는 것이다.

즉, 함수 이름뿐만 아니라 세부 구현을 모두 읽어야 함수의 역할을 알게 된다.

 

😞  함수 세부 구현 단계가 제각각이다.

파란색 노란색 부분은 모두 이벤트 핸들링 함수로, 이름이 비슷하다.

`handleQuestionSubmit`

`handleMyExpertQuestionSubmit`

 

심지어, 파란색은 질문전송 외에도 여러가지 일을 하고 있어 읽을때 이해하기 어렵다는 단점이 있다.

 

 

..이렇게, 깔끔했던 코드가 작은 기능 하나를 추가했더니 어지러운 코드가 되어 버렸다.

자 이제 리팩토링을 해보자.

---

🥉 리팩토링 할까요?

먼저 함수의 세부 구현 단계 통일해보자.

함수이름을 통일감있게 바꿔보자.

`handleQuestionSubmit` 👉  `handleNewExpertQuestionSubmit`

 

그리고, 팝업관련 코드를 하나로 뭉쳐보자.

 

함수 하나에서 기능별로 쪼개서 함수를 호출해보자.

함수 하나에서 하나의 일만 쪼갰다. 

 

=> 코드가 처음보다 길어졌는데 이게 클린코드인가요? 

네!

명심해야 할 것은, 클린코드는 짧은 코드가 아니다.

원하는 로직을 빠르게 찾을 수 있는 코드이다.

 

---

👐 로직을 빠르게 찾을 수 있는 코드

1. 응집도

같은 목적인 코드는 뭉쳐주자.

 

아래와 같은 기능을 뭉친다고 생각해보자.

연결 전문가가 있으면,
전문가의 정보를 팝업으로 띄어주고,
그 전문가에게 질문을 전송할 수 있으며,
팝업을 닫을 수 있다.

custom hook을 사용해 한군데로 뭉쳐보자! 했는데,

오히려 코드파악이 어려워졌다 왜일까?

 

어떤 내용의 팝업을 띄우는지, 어떤액션을 하는지 전혀 알 수 없다.

모두 hook 속에 가려져서 알 수 없게 되었다. 모든 구현로직들이 숨겨진 것이다.

👉 대표적인 custom hook의 안티패턴이라 볼 수 있다.

 

그럼 무엇을 뭉쳐야 할까?

당장 몰라도 되는 디테일을 뭉치자.

명심해야 할 것은, 뭉쳐서 짧은 코드로 만든다고 코드가 깨끗해지는게 아니다 !

 코드 파악에 필수적인 핵심 정보를 뭉치면 안된다 !

 

핵심데이터: 팝업 클릭시 수행하는 액션 / 팝업제목 / 팝업 내용

세부구현: 팝업 열고닫을때 / 액션을 어떻게 수행하는지 / 팝업의 모습

 

`openPopup` 이라는 custom hook 안에 모든 코드를 다 숨기는 것이 아닌,

세부 구현만 숨겨놓고, 핵심데이터 (팝업, 제목, 내용, 액션)은 바깥에서 넘기도록 했다.

 

우리는 이러한 프로그래밍 기법을 선언적 프로그래밍 기법이라고 한다.

💬 " 제목은 A고, 내용은 B고, 확인버튼을 누르면 C가 실행되는 팝업을 띄어줘!" 

핵심데이터만 넘기면, 세부구현을 모르더라도 ,  무엇을 하는 함수인지 빠른 이해가 가능하다.

 

무엇을 해야 할 지만 넘기는 방식

 

세부구현을 뭉치지 않고, 하나하나 작성한 방식은 명령형 프로그래밍 이라 한다

 

사실 선언적 프로그래밍도 까보면 명령형이다. 

 

그래서, 선언적 프로그래밍이 더 좋은건가?

아니다! 두 방법 모두 의미가 있다.

 

2. 단일책임

함수는 오로지 하나의 일을 하도록 하자.

그리고 함수의 이름을 뚜렷하게 짓자.

 

이벤트 핸들러 함수 이름을 지어보자.

함수안에 약관동의도 받아오고, 팝업도 열고, 질문전송도 하는데 함수이름이 `질문제출` 일 수 있을까? 

 

내부 구현의 중요 포인트가 이름에 모두 담겨있지 않다면 위험하다.

 

리액트 코드로도 단일책임 분리가 가능하다.

이전에는 버튼클릭함수에 로그찍는 기능과, API 콜 두가지가 있었는데,

After 에는 로그는 로그, 버튼은 API 콜만 신경쓰도록 할 수 있다.

 

3. 추상화

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

 

 

추상화의 개념은 다양하게 뽑아낼 수 있다.

 

정답은 없다.

상황에따라 필요한 만큼한 추상화하면 된다.

 

만약, 코드에 추상화 수준이 섞여있다면 어떨까 ?

추상화 수준이 섞여있다면, 전체적으로 코드를 보았을 때, 어떤 수준으로 구체적으로 기술된 것인지 파악하기 어렵다.

추상화 단계를 비슷한 것 들 끼리 모으는 것이 좋다.

 

✨ 액션아이템

담대하게 기존 코드 수정하기

구조뜯기를 두려워하면 실무코드 유지가 불가능하다.

 

큰 그림 보는 연습하기

그때는 맞고 지금은 틀릴 수 있다.

처음 코드를 짤 때 부터 여러 생각들을 하자.

 

팀과 함께 공감대 형성하기

코드에 정답은 없다