[TOSS SLASH 21] 실무에서 바로 쓰는 Frontend Clean Code

Gyuhan Park·2023년 9월 30일
0

conference

목록 보기
1/2

https://brand.toss.im/

[ 요약 ]
클린 코드 : 원하는 로직을 빠르게 찾을 수 있는 코드
응집도 : 핵심 내용은 겉으로 드러나게, 세부 구현은 추상화
단일 책임 : 한 가지 일만 하는, 명확한 함수명
추상화 : 핵심 개념 뽑아내기
선언적 프로그래밍 연습하기
큰 그림 보는 연습하기 (기능을 추가하면서 그 때는 맞고 지금은 틀린 코드)

💭 TMI

요즘 들어 좋은 개발자, 잘하는 개발자는 무엇인가 에 대한 생각이 많이 든다.

전공 수업을 열심히 들어 학점을 잘 받은 사람?
프로젝트 경험이 많은 사람?

영향은 있지만 100% 인과관계는 아닌 것 같다.
나는 그냥 많이 해본 사람이다. 프로젝트를 여러가지 해봤지만 많이 해본 거 자체는 잘하는 사람이 아니라 많이 해본 사람이다. 많이 해본 사람은 기술 또는 라이브러리를 사용하는 것에 익숙한 거지 잘하는 것과 별개의 문제라는 생각이 든다.
또 내가 쓰는 코드가 좋은 코드인가에 대한 기준 없이 그냥 예전에 이렇게 했으니까 습관적으로 사용한다.

연휴 기념으로(?) SLASH 영상을 보며 좋은 코드에 대한 기준을 잡아보자

📖 실무에서 바로 쓰는 Frontend Clean Code

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

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

실무에서 클린 코드의 의의 : 유지보수 시간의 단축
동료 혹은 과거의 스스로 짠 코드를 빠르게 이해할 수 있다면 유지보수할 때 드는 개발 시간이 짧아진다.

지뢰 코드
1. 흐름 파악이 어려움.
2. 도메인 맥락 표현이 안되어 있음.
3. 동료에게 물어봐야 알 수 있는 코드
=> 개발 병목. 유지보수 어려움. 기능 추가 어려움. 성능 저하.

새 기능을 구현할 때는 문제가 없음
기존 코드에 기능을 추가할 때 문제가 발생
기능을 추가할 때 맥락상 자연스럽더라도 나쁜 코드가 될 수 있다.

나쁜 코드
1. 하나의 목적인 코드가 흩뿌려져 있다.
2. 하나의 함수가 여러가지 일을 한다.
3. 함수의 세부구현 단계가 제각각이다.

이와 같은 흐름에서 클린 코드의 정의를 다음과 같이 내릴 수 있다.

클린 코드
짧은 코드 X
원하는 로직을 빠르게 찾을 수 있는 코드 O

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

클린 코드를 작성하기 위해 3가지 관점으로 코드를 바라볼 수 있다.

  1. 응집도
  2. 단일 책임
  3. 추상화

1️⃣ 응집도

같은 목적의 코드는 뭉쳐두자

핵심 내용은 겉으로 드러나게, 세부 구현은 추상화
당장 몰라도 되는 디테일 -> 추상화 O
코드파악에 핵심적인 내용 -> 추상화 X

뭉쳐서 짧은 코드를 만든다고 깨끗한 코드가 아니다

ex) 팝업을 조작하는 코드를 커스텀훅으로 한번에 뭉쳐두기 -> 읽기 힘든 코드
why? -> 팝업에서 어떤 내용을 띄우는 지, 팝업에서 버튼을 눌렀을 때 어떤 액션을 하는 지 파악 어려움

남겨야할 핵심 데이터와 숨겨도 되는 세부구현 파악

핵심 : 팝업 제목, 내용, 클릭 이벤트
세부 : 팝업 열고닫는 상태, 세부 마크업, 버튼 클릭 시 함수호출 바인딩

const [openPopup] = usePopup();
async function handleClick() {
	const confirmed = await openPopup({title:'팝업제목', contents: `<div>설명</div>` });
	if(confirmed) {
      await submitQuestion();
    }
}

세부 구현을 읽지 않고도 어떤 팝업인 지 파악 가능.
이러한 코드 스타일을 선언적 프로그래밍 이라고 한다.

선언적 프로그래밍

  • 무엇을 하는 함수인 지 빠르게 이해
  • 세부 구현은 안쪽에 숨김
  • 무엇만 바꿔서 쉽게 재사용 가능

2️⃣ 단일 책임

한 가지 일만 하는, 명확한 함수명

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

2가지 핵심 작업을 하는데 함수명에는 한가지 작업에 대한 내용만 담겨있으면 코드에 대한 신뢰가 하락하며 세부구현을 확인하게 된다.
ex) 약관동의와 질문제출이라는 2가지 포인트 존재 -> handle질문제출() 이라고 함수명을 지으면 위험. -> 기능단위 함수 분리

기능성 컴포넌트

세부 구현과 API 콜이 섞여있으면 읽을 때 헷갈리는데,

<button onClick={async () => {
  log('제출 버튼 클릭');
  await openConfirm();
}} />

다음과 같이 로그를 찍는 함수와 API 콜 로직을 분리할 수 있다.

<LogClick message='제출 버튼 클릭'>
  <button onClick={async () => {
  await openConfirm();
  }} />
</LogClick>

3️⃣ 추상화

핵심 개념을 뽑아내자

얼마나 추상화할 것인가?

추상화 수준이 섞여 있으면 코드를 파악하기 어렵다.
코드를 읽는 데 사고가 널뛰게 된다.
추상화 정도는 상황에 따라 선택.

// level 0.
<Button onClick={showConfirm}>전송</Button>
{isShowConfirm && (<Confirm onClick={() => {showMessage("성공")}} />
)}

// level 1.
<ConfirmButton onConfirm={() => {showMessage("성공")}}>전송</ConfirmButton>

// level 2.
<ConfirmButton message="성공"/>
  
// level 3.
<ConfirmButton />

📌 어떻게 행동해야 하는가

  • 담대하게 기존 코드 수정하기
  • 큰 그림 보는 연습하기 (기능을 추가하면서 그 때는 맞고 지금은 틀린 코드)
  • 팀과 함꼐 공감대 형성 (고치고 싶은 포인트 이야기 나누기)
  • 문서로 적어보기 (글로 적어야 명확해진다. 향후 어떤 점에서 위험한지, 어떻게 개선할 수 있는지 작성해보기)

🔥 프로젝트에 적용하기

영상에서 배운 내용을 코드에 적용시켜 볼 예정 !

profile
단단한 프론트엔드 개발자가 되고 싶은

0개의 댓글