📄 참고자료
토스 실무에서 바로 쓰는 Frontend Clean Code
https://www.youtube.com/watch?v=edWbHp_k_9Y
💬 들어가기전 주저리
기술블로그와 여러 기술 아티클을 탐방할 때, 클린코드(clean code) 란 용어를 자주 본다.
👈 요런, 클린코드 서적을 추천하는 게시글이나 주변 개발자도 봤었다.
그래서 "클린코드" 가 무엇이냐~ 라고 물어본다면,
중복되는 코드 줄이는 방법
가독성이 쉬운 코드를 작성하는 방법
유지보수가 쉬운 코드를 작성하는 방법
이라 할 수 있다.
중복,가독성,유지보수.. 멋진 용어다. 이건 클린코드에 대해 검색하면 나오는 정말 군더더기 없는 설명이다.
사실, 개인적으로, 내가 느끼는 클린코드에 대한 정의는, 개발자의 원활한 소통과 업무를 위한 도구 라고 생각한다.
- 새로운 기능 추가 후 PR 올릴 때
- 기능을 구현하는 도중, 어려움이 생겨 코드 질문을 할 때
- 기능 추가를 위해 기존 코드를 수정할 때
- 유지보수를 위해 기존 코드를 수정할 때
.. 등등. 우리는 코드를 작성하면서 동료들과 혹은 선배들과 소통을 한다.
그 소통을 할때 필요한건 코드 인데..
이 코드가 상대방이 이해하기 어렵다거나, 당장 내가 수정을 해야하는 데 코드 파악이 안되면 ... (ㅋㅋ)
미래의 나를 위해, 옆의 동료를 위해 우리는 언제나 클린코드를 염두하며 업무를 하는 것이 좋다.
위의 토스영상은 실무에서 프론트앤드 개발자가 클린코드를 지키는 방법에 대해 설명해준다.
그리고 이 게시글은 영상의 내용이 담겨있다.
🥇 실무에서 클린코드의 의의
클린코드가 의미있는 이유는 무엇일까?
클린코드가 적용이 안되어있다면 그것은 읽기어려운 코드라 볼 수 있다.
그러한 코드들은,
- 코드를 읽고 이해하느라 개발할때 병목이 되고
- 유지보수할때 시간이 오래 걸리며
- 기능추가가 어렵고 성능이 좋지않을 것이다.
동료, 과거의 내가 빠르게 이해할 수 있다면
유지보수할 때 드는 개발 시간이 짧아진다.
물론, 버그가 났을 때 디버깅 시간도 단축된다.
🥈 안일한 코드 추가의 함정
물론 처음 코드를 설계하고, 새로운 파일에서 짤땐 코드는 깨끗하다.
만약에 기존 코드에 기능을 추가하는 상황이라면 어떨까?
👈 같은 기능 추가요청이 들어왔다 해보자.
보험에 대한 질문을 입력하는 페이지 이다.
AS-IS
- 보험 질문 입력
- 질문등록 팝업
- 확인
TO-BE:
- 보험 질문 입력
- 내 설계사가 있으면? >
- 설계사 사진이 들어간 팝업을 먼저 띄워달라.
기존 코드에 새로운 기능을 추가하면 어떻게 하면 될까?
질문하기 클릭 함수에, 나의 설계사가 있으면, 팝업을 노출하면 된다!
설계대로 코드개발하면 아래와 같다.
나의 설계사가 있으면, popupOpend 가 true > 연결 전문가 팝업 show ! > 클릭시 > 연결 전문가 질문 전송 !
기능추가구현은 완성되었으나..
이 코드에는 심각한 함정들이 있다.
😞 하나의 목적인 코드가 흩뿌려져 있다.
초록색으로 강조한 코드가 모두 연결중인 전문가 팝업 관련 코드 인데.
목적이 같은 코드들이 한 페이지(한 파일)에 흩뿌려져 있다.
이러한 코드는 나중에 또 기능 추가할 때 스크롤을 위아래로 이동하면서 코드를 이해해야 한다.
😞 하나의 함수가 여러가지 일을 하고 있다.
위의 함수는 `handleQuestionSubmit` 으로, 이름만 보면 "질문을 전송하는 submit 핸들러 함수구나 ~" 이해할 수 있다.
하지만, 실제 내부에 세부 구현된 코드를 보면 이름과 다르다.
- 연결 전문가 정보를 받아오고 > 있으면 팝업을 띄우고
- 약관 동의를 받아오고 > 약관동의를 안했으면 팝업을 열고
- 위의 두 단계가 모두 통과가 되어야 ! 질문이 전송
`handleQuestionSubmit` 라는 함수에 실제로, 위의 세가지 기능을 하고 있는 것이다.
즉, 함수 이름뿐만 아니라 세부 구현을 모두 읽어야 함수의 역할을 알게 된다.
😞 함수 세부 구현 단계가 제각각이다.
파란색 노란색 부분은 모두 이벤트 핸들링 함수로, 이름이 비슷하다.
`handleQuestionSubmit`
`handleMyExpertQuestionSubmit`
심지어, 파란색은 질문전송 외에도 여러가지 일을 하고 있어 읽을때 이해하기 어렵다는 단점이 있다.
..이렇게, 깔끔했던 코드가 작은 기능 하나를 추가했더니 어지러운 코드가 되어 버렸다.
자 이제 리팩토링을 해보자.
🥉 리팩토링 할까요?
먼저 함수의 세부 구현 단계 통일해보자.
함수이름을 통일감있게 바꿔보자.
`handleQuestionSubmit` 👉 `handleNewExpertQuestionSubmit`
그리고, 팝업관련 코드를 하나로 뭉쳐보자.
함수 하나에서 기능별로 쪼개서 함수를 호출해보자.
함수 하나에서 하나의 일만 쪼갰다.
=> 코드가 처음보다 길어졌는데 이게 클린코드인가요?
네!
명심해야 할 것은, 클린코드는 짧은 코드가 아니다.
원하는 로직을 빠르게 찾을 수 있는 코드이다.
👐 로직을 빠르게 찾을 수 있는 코드
1. 응집도
같은 목적인 코드는 뭉쳐주자.
아래와 같은 기능을 뭉친다고 생각해보자.
연결 전문가가 있으면,
전문가의 정보를 팝업으로 띄어주고,
그 전문가에게 질문을 전송할 수 있으며,
팝업을 닫을 수 있다.
custom hook을 사용해 한군데로 뭉쳐보자! 했는데,
오히려 코드파악이 어려워졌다 왜일까?
어떤 내용의 팝업을 띄우는지, 어떤액션을 하는지 전혀 알 수 없다.
모두 hook 속에 가려져서 알 수 없게 되었다. 모든 구현로직들이 숨겨진 것이다.
👉 대표적인 custom hook의 안티패턴이라 볼 수 있다.
그럼 무엇을 뭉쳐야 할까?
당장 몰라도 되는 디테일을 뭉치자.
명심해야 할 것은, 뭉쳐서 짧은 코드로 만든다고 코드가 깨끗해지는게 아니다 !
코드 파악에 필수적인 핵심 정보를 뭉치면 안된다 !
핵심데이터: 팝업 클릭시 수행하는 액션 / 팝업제목 / 팝업 내용
세부구현: 팝업 열고닫을때 / 액션을 어떻게 수행하는지 / 팝업의 모습
`openPopup` 이라는 custom hook 안에 모든 코드를 다 숨기는 것이 아닌,
세부 구현만 숨겨놓고, 핵심데이터 (팝업, 제목, 내용, 액션)은 바깥에서 넘기도록 했다.
우리는 이러한 프로그래밍 기법을 선언적 프로그래밍 기법이라고 한다.
💬 " 제목은 A고, 내용은 B고, 확인버튼을 누르면 C가 실행되는 팝업을 띄어줘!"
핵심데이터만 넘기면, 세부구현을 모르더라도 , 무엇을 하는 함수인지 빠른 이해가 가능하다.
무엇을 해야 할 지만 넘기는 방식
세부구현을 뭉치지 않고, 하나하나 작성한 방식은 명령형 프로그래밍 이라 한다
사실 선언적 프로그래밍도 까보면 명령형이다.
그래서, 선언적 프로그래밍이 더 좋은건가?
아니다! 두 방법 모두 의미가 있다.
2. 단일책임
함수는 오로지 하나의 일을 하도록 하자.
그리고 함수의 이름을 뚜렷하게 짓자.
이벤트 핸들러 함수 이름을 지어보자.
함수안에 약관동의도 받아오고, 팝업도 열고, 질문전송도 하는데 함수이름이 `질문제출` 일 수 있을까?
내부 구현의 중요 포인트가 이름에 모두 담겨있지 않다면 위험하다.
리액트 코드로도 단일책임 분리가 가능하다.
이전에는 버튼클릭함수에 로그찍는 기능과, API 콜 두가지가 있었는데,
After 에는 로그는 로그, 버튼은 API 콜만 신경쓰도록 할 수 있다.
3. 추상화
로직에서 핵심 개념을 뽑아내자.
추상화의 개념은 다양하게 뽑아낼 수 있다.
정답은 없다.
상황에따라 필요한 만큼한 추상화하면 된다.
만약, 코드에 추상화 수준이 섞여있다면 어떨까 ?
추상화 수준이 섞여있다면, 전체적으로 코드를 보았을 때, 어떤 수준으로 구체적으로 기술된 것인지 파악하기 어렵다.
추상화 단계를 비슷한 것 들 끼리 모으는 것이 좋다.
✨ 액션아이템
담대하게 기존 코드 수정하기
구조뜯기를 두려워하면 실무코드 유지가 불가능하다.
큰 그림 보는 연습하기
그때는 맞고 지금은 틀릴 수 있다.
처음 코드를 짤 때 부터 여러 생각들을 하자.
팀과 함께 공감대 형성하기
코드에 정답은 없다
'🌳Frontend > etc' 카테고리의 다른 글
| [FE] Next.js SSR 환경에서 흔히 겪는 에러 Server Error XXX is not defined. This error happened while generating the page. (0) | 2023.09.04 |
|---|---|
| [FE] 토스가 정의하는 컴포넌트의 역할과 분리 기준 (0) | 2023.09.03 |
| 프론트엔드 성능 최적화 (0) | 2023.07.05 |
| package.json 의 version 과 틸드 tilde(~) 그리고 캐럿 caret(^) (0) | 2023.06.15 |
| 포커스된 요소의 부모요소에 스타일링 (2) | 2023.06.15 |
📄 참고자료
토스 실무에서 바로 쓰는 Frontend Clean Code
https://www.youtube.com/watch?v=edWbHp_k_9Y
💬 들어가기전 주저리
기술블로그와 여러 기술 아티클을 탐방할 때, 클린코드(clean code) 란 용어를 자주 본다.
👈 요런, 클린코드 서적을 추천하는 게시글이나 주변 개발자도 봤었다.
그래서 "클린코드" 가 무엇이냐~ 라고 물어본다면,
중복되는 코드 줄이는 방법
가독성이 쉬운 코드를 작성하는 방법
유지보수가 쉬운 코드를 작성하는 방법
이라 할 수 있다.
중복,가독성,유지보수.. 멋진 용어다. 이건 클린코드에 대해 검색하면 나오는 정말 군더더기 없는 설명이다.
사실, 개인적으로, 내가 느끼는 클린코드에 대한 정의는, 개발자의 원활한 소통과 업무를 위한 도구 라고 생각한다.
- 새로운 기능 추가 후 PR 올릴 때
- 기능을 구현하는 도중, 어려움이 생겨 코드 질문을 할 때
- 기능 추가를 위해 기존 코드를 수정할 때
- 유지보수를 위해 기존 코드를 수정할 때
.. 등등. 우리는 코드를 작성하면서 동료들과 혹은 선배들과 소통을 한다.
그 소통을 할때 필요한건 코드 인데..
이 코드가 상대방이 이해하기 어렵다거나, 당장 내가 수정을 해야하는 데 코드 파악이 안되면 ... (ㅋㅋ)
미래의 나를 위해, 옆의 동료를 위해 우리는 언제나 클린코드를 염두하며 업무를 하는 것이 좋다.
위의 토스영상은 실무에서 프론트앤드 개발자가 클린코드를 지키는 방법에 대해 설명해준다.
그리고 이 게시글은 영상의 내용이 담겨있다.
🥇 실무에서 클린코드의 의의
클린코드가 의미있는 이유는 무엇일까?
클린코드가 적용이 안되어있다면 그것은 읽기어려운 코드라 볼 수 있다.
그러한 코드들은,
- 코드를 읽고 이해하느라 개발할때 병목이 되고
- 유지보수할때 시간이 오래 걸리며
- 기능추가가 어렵고 성능이 좋지않을 것이다.
동료, 과거의 내가 빠르게 이해할 수 있다면
유지보수할 때 드는 개발 시간이 짧아진다.
물론, 버그가 났을 때 디버깅 시간도 단축된다.
🥈 안일한 코드 추가의 함정
물론 처음 코드를 설계하고, 새로운 파일에서 짤땐 코드는 깨끗하다.
만약에 기존 코드에 기능을 추가하는 상황이라면 어떨까?
👈 같은 기능 추가요청이 들어왔다 해보자.
보험에 대한 질문을 입력하는 페이지 이다.
AS-IS
- 보험 질문 입력
- 질문등록 팝업
- 확인
TO-BE:
- 보험 질문 입력
- 내 설계사가 있으면? >
- 설계사 사진이 들어간 팝업을 먼저 띄워달라.
기존 코드에 새로운 기능을 추가하면 어떻게 하면 될까?
질문하기 클릭 함수에, 나의 설계사가 있으면, 팝업을 노출하면 된다!
설계대로 코드개발하면 아래와 같다.
나의 설계사가 있으면, popupOpend 가 true > 연결 전문가 팝업 show ! > 클릭시 > 연결 전문가 질문 전송 !
기능추가구현은 완성되었으나..
이 코드에는 심각한 함정들이 있다.
😞 하나의 목적인 코드가 흩뿌려져 있다.
초록색으로 강조한 코드가 모두 연결중인 전문가 팝업 관련 코드 인데.
목적이 같은 코드들이 한 페이지(한 파일)에 흩뿌려져 있다.
이러한 코드는 나중에 또 기능 추가할 때 스크롤을 위아래로 이동하면서 코드를 이해해야 한다.
😞 하나의 함수가 여러가지 일을 하고 있다.
위의 함수는 handleQuestionSubmit 으로, 이름만 보면 "질문을 전송하는 submit 핸들러 함수구나 ~" 이해할 수 있다.
하지만, 실제 내부에 세부 구현된 코드를 보면 이름과 다르다.
- 연결 전문가 정보를 받아오고 > 있으면 팝업을 띄우고
- 약관 동의를 받아오고 > 약관동의를 안했으면 팝업을 열고
- 위의 두 단계가 모두 통과가 되어야 ! 질문이 전송
handleQuestionSubmit 라는 함수에 실제로, 위의 세가지 기능을 하고 있는 것이다.
즉, 함수 이름뿐만 아니라 세부 구현을 모두 읽어야 함수의 역할을 알게 된다.
😞 함수 세부 구현 단계가 제각각이다.
파란색 노란색 부분은 모두 이벤트 핸들링 함수로, 이름이 비슷하다.
handleQuestionSubmit
handleMyExpertQuestionSubmit
심지어, 파란색은 질문전송 외에도 여러가지 일을 하고 있어 읽을때 이해하기 어렵다는 단점이 있다.
..이렇게, 깔끔했던 코드가 작은 기능 하나를 추가했더니 어지러운 코드가 되어 버렸다.
자 이제 리팩토링을 해보자.
🥉 리팩토링 할까요?
먼저 함수의 세부 구현 단계 통일해보자.
함수이름을 통일감있게 바꿔보자.
handleQuestionSubmit 👉 handleNewExpertQuestionSubmit
그리고, 팝업관련 코드를 하나로 뭉쳐보자.
함수 하나에서 기능별로 쪼개서 함수를 호출해보자.
함수 하나에서 하나의 일만 쪼갰다.
=> 코드가 처음보다 길어졌는데 이게 클린코드인가요?
네!
명심해야 할 것은, 클린코드는 짧은 코드가 아니다.
원하는 로직을 빠르게 찾을 수 있는 코드이다.
👐 로직을 빠르게 찾을 수 있는 코드
1. 응집도
같은 목적인 코드는 뭉쳐주자.
아래와 같은 기능을 뭉친다고 생각해보자.
연결 전문가가 있으면,
전문가의 정보를 팝업으로 띄어주고,
그 전문가에게 질문을 전송할 수 있으며,
팝업을 닫을 수 있다.
custom hook을 사용해 한군데로 뭉쳐보자! 했는데,
오히려 코드파악이 어려워졌다 왜일까?
어떤 내용의 팝업을 띄우는지, 어떤액션을 하는지 전혀 알 수 없다.
모두 hook 속에 가려져서 알 수 없게 되었다. 모든 구현로직들이 숨겨진 것이다.
👉 대표적인 custom hook의 안티패턴이라 볼 수 있다.
그럼 무엇을 뭉쳐야 할까?
당장 몰라도 되는 디테일을 뭉치자.
명심해야 할 것은, 뭉쳐서 짧은 코드로 만든다고 코드가 깨끗해지는게 아니다 !
코드 파악에 필수적인 핵심 정보를 뭉치면 안된다 !
핵심데이터: 팝업 클릭시 수행하는 액션 / 팝업제목 / 팝업 내용
세부구현: 팝업 열고닫을때 / 액션을 어떻게 수행하는지 / 팝업의 모습
openPopup 이라는 custom hook 안에 모든 코드를 다 숨기는 것이 아닌,
세부 구현만 숨겨놓고, 핵심데이터 (팝업, 제목, 내용, 액션)은 바깥에서 넘기도록 했다.
우리는 이러한 프로그래밍 기법을 선언적 프로그래밍 기법이라고 한다.
💬 " 제목은 A고, 내용은 B고, 확인버튼을 누르면 C가 실행되는 팝업을 띄어줘!"
핵심데이터만 넘기면, 세부구현을 모르더라도 , 무엇을 하는 함수인지 빠른 이해가 가능하다.
무엇을 해야 할 지만 넘기는 방식
세부구현을 뭉치지 않고, 하나하나 작성한 방식은 명령형 프로그래밍 이라 한다
사실 선언적 프로그래밍도 까보면 명령형이다.
그래서, 선언적 프로그래밍이 더 좋은건가?
아니다! 두 방법 모두 의미가 있다.
2. 단일책임
함수는 오로지 하나의 일을 하도록 하자.
그리고 함수의 이름을 뚜렷하게 짓자.
이벤트 핸들러 함수 이름을 지어보자.
함수안에 약관동의도 받아오고, 팝업도 열고, 질문전송도 하는데 함수이름이 질문제출 일 수 있을까?
내부 구현의 중요 포인트가 이름에 모두 담겨있지 않다면 위험하다.
리액트 코드로도 단일책임 분리가 가능하다.
이전에는 버튼클릭함수에 로그찍는 기능과, API 콜 두가지가 있었는데,
After 에는 로그는 로그, 버튼은 API 콜만 신경쓰도록 할 수 있다.
3. 추상화
로직에서 핵심 개념을 뽑아내자.
추상화의 개념은 다양하게 뽑아낼 수 있다.
정답은 없다.
상황에따라 필요한 만큼한 추상화하면 된다.
만약, 코드에 추상화 수준이 섞여있다면 어떨까 ?
추상화 수준이 섞여있다면, 전체적으로 코드를 보았을 때, 어떤 수준으로 구체적으로 기술된 것인지 파악하기 어렵다.
추상화 단계를 비슷한 것 들 끼리 모으는 것이 좋다.
✨ 액션아이템
담대하게 기존 코드 수정하기
구조뜯기를 두려워하면 실무코드 유지가 불가능하다.
큰 그림 보는 연습하기
그때는 맞고 지금은 틀릴 수 있다.
처음 코드를 짤 때 부터 여러 생각들을 하자.
팀과 함께 공감대 형성하기
코드에 정답은 없다
'🌳Frontend > etc' 카테고리의 다른 글
| [FE] Next.js SSR 환경에서 흔히 겪는 에러 Server Error XXX is not defined. This error happened while generating the page. (0) | 2023.09.04 |
|---|---|
| [FE] 토스가 정의하는 컴포넌트의 역할과 분리 기준 (0) | 2023.09.03 |
| 프론트엔드 성능 최적화 (0) | 2023.07.05 |
| package.json 의 version 과 틸드 tilde(~) 그리고 캐럿 caret(^) (0) | 2023.06.15 |
| 포커스된 요소의 부모요소에 스타일링 (2) | 2023.06.15 |
