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

 

 

작년 자료긴 하지만 프론트엔드에서도 클린한 코드를 구현해야 나뿐만 아니라 다른 개발자도 코드를 읽고 바로 기능을 이해할 수 있기 때문에 생산성을 더 높일 수 있다고 생각한다.

특히 좋은 개발자의 기준 중 하나로써 빠른 생산성을 강조하는 몇몇 포스팅을 본 적이 있는데 기업 입장에서도, 팀 입장에서도 업무에 교착상태없이 원활하게 업무를 진행하려면 팀원의 생산성 속도를 적절히 조절할 수 있어야 한다.

그러기 위해서는 우선 빠르게 생산성을 올릴 수 있는 방법부터 고안해봐야한다. 빠르게 하는 걸 느리게 하기는 쉬워도 느리게 하는 걸 빨리 하기는 어렵기 때문이다.

토스에서는 이런 생산성을 위해 프론트엔드에서도 클린 코드를 지향했다고 하는 강연이 있어서 보게 되었다. 이번 강연을 보면서 클린 코드의 개념과 의의를 다시 한번 생각해보게 되었고, 내가 클린 코드를 지향하면서도 계속해서 나쁜 코드가 되는 이유를 알게 되었다. 그래서 내용을 잊지 않기 위해서 정리해둔다.

 

1. 실무에서 클린 코드의 의의
   
   1. 흐름 파악이 어렵고 도메인 맥락 표현이 안돼서 동료에 물어봐야 알 수 있는 코드
      1. 병목이 되고, 유지보수할 때 시간이 많이 걸림
      2. 심하면 기능 추가가 불가능한 상태가 됨
      3. 성능도 안좋음 -> 유저 입장에서 쾌적하지 못함
   2. 유지보수 시간의 단축
      1. 코드 파악
      2. 디버깅
      3. 리뷰
   3. 시간 = 자원 = 돈
   4. '처음엔' 클린했습니다.
      1. 기존 코드에 기능을 추가하는 상황에서 스파게티 코드 등의 문제 발생 ...
2. 안일한 코드 추가의 함정
   
   1. 기능 추가 요청이 들어왔다
      1. 기존 코드 파악
      2. 간단한 구현 설계
      3. 설계대로 개발 완료! -> 그러나 나쁜 코드
         1. 왜? 1) 하나의 목적인 코드가 흩뿌려져있다
         2. 왜? 2) 하나의 함수가 여러 가지 일을 하고 있다
         3. 왜? 3) 함수의 세부 구현 단계가 제각각이다
   2. PR만 봤을 때는 잘 모른다 -> 전체 그림으로 봐야 보인다
   3. 큰 그림을 보며 코드 리팩토링
      1. 함수 세부 구현 단계 통일 : 기존 함수 이름 변경으로 위계 맞추기
      2. 하나의 목적인 코드는 뭉쳐 두기
      3. 함수가 한 가지 일만 하도록 쪼개기
   4. 클린 코드 != 짧은 코드 && 클린 코드 == 원하는 로직을 빠르게 찾을 수 있는 코드
      1. 원하는 로직을 빠르게 찾으려면?
         1. 응집도
         2. 단일책임
         3. 추상화
3. 로직을 빠르게 찾을 수 있는 코드
   
   1. 응집도 : 같은 목적의 코드는 뭉쳐두자
      1. 하나의 기능이지만 코드는 여기저기
      2. 파악 한번에 안되고 버그 발생 위험도도 높음
      3. 해결 1 -> 커스텀 훅 이용해서 한 군데로 뭉치기 -> 오히려 어려워진 코드 파악 (커스텀 훅의 대표적인 안티패턴)
      4. 무엇을 뭉쳐야 하는가?
         1. 뭉치면 쾌적 -> 당장 몰라도 되는 디테일
         2. 뭉치면 답답 -> 코드 파악에 필수적인 핵심 정보
      5. 코드 응집 Tip : 핵심 데이터와 세부 구현 나누기 -> 핵심 데이터는 밖에서 전달, 나머지는 뭉친다
      6. 선언적 프로그래밍 : 핵심 데이터만 전달받고 세부 구현은 뭉쳐 숨겨 두는 개발 스타일
         1. '무엇'을 하는 함수인지 빠른 이해 가능
         2. 세부 구현은 내부에 뭉쳐 둠
         3. '무엇'만 바꿔서 쉽게 재사용 가능
      7. 명령형 프로그래밍 : 뭉쳐두지 않고 하나하나 세부 구현을 작성한 방식
         1. '어떻게' 해야 할지 하나하나 명령하기
         2. 장점 : 세부 구현 노출로 커스텀하기 쉬움
         3. 단점 : 읽는 데 오래 걸리고 재사용하기 어려움
      8. 두 방법 모두 유동적으로 적용할 것 !
   2. 단일책임 : 하나의 일을 하는 뚜렷한 이름의 함수를 만들자
      1. 함수 이름을 지어보자 -> 중요 포인트가 모두 담겨 있지 않은 함수명은 위험 !
         1. 독자로 하여금 함수명으로부터 기대한 기능과 다른 기능이 있을 경우 독자는 함수명을 신뢰하지 못하고 세부 구현을 모두 의심함
      2. 기능 추가 시 함수는 더욱 잡탕이 된다
      3. 리팩토링 Tip 1 : 한 가지 일만 하는, 명확한 이름의 함수
      4. 리팩토링 Tip 2 : 한 가지 일만 하는, 기능성 컴포넌트
         1. LogComponent로 감싸서 버튼에서는 API콜만 신경쓸 수 있게 하기
         2. IntersectionObserverArea라는 상위 컴포넌트로 만들고 감싸서 분리하기
      5. 리팩토링 Tip 3 : 조건이 많아지면 한글 이름도 유용해요
         1. 주석과 같은 효과를 내기도 한다
   3. 추상화 : 핵심 개념을 뽑아내자
      1. 피카소의 '소'
      2. 지하철 노선도의 추상화
      3. 프론트엔드 코드의 추상화 : 컴포넌트
      4. 프론트엔드 코드의 추상화 : 함수
         1. 설계사 라벨을 얻는 코드 세부 구현
         2. 중요 개념을 함수 이름에 담아 추상화
      5. 얼마나 추상화할 것인가? -> 상황에 따라 필요한 만큼 추상화하기
      6. 실무 예시 : 추상화할 수 있을까요?
         1. 추상화를 제안
         2. 추상화를 일부러 깬 이유를 설명
      7. 추상화에서 유념하면 좋을 점
         1. 추상화 수준이 섞여 있으면 코드 파악이 어려움 -> 추상화 단계를 비슷하게 정리
   4. 액션 아이템
      1. 담대하게 기존 코드 수정하기 : 두려워하지 말고 기존 코드를 씹고 뜯고 맛보고 즐기자
         1. Mother branch에서 리팩토링한 코드를 따서 PR 보내는 것도 방법 !
      2. 큰 그림 보는 연습하기 : 그때는 맞고 지금은 틀리다, 기능 추가 자체는 클린해도 전체적으로는 어지러울 수 있다
      3. 팀과 함께 공감대 형성하기 : 코드에 정답은 없다, 명시적으로 이야기를 하는 시간이 필요하다
         1. 사소하지만 이슈를 명시적으로 공유하지 않는다면 유지보수하는 데 시간이 오래 걸림
         2. 공감대는 자동으로 만들어지지 않음
         3. 함께 만들어온 코드에서 고치고 싶은 포인트를 서로 말해보고, 각자 문제라고 생각하는 지점을 공유해 집단지성을 모음
         4. 어떻게 개선할건지 고민하자
      4. 문서로 적어보기 : 글로 적어야 명확해진다
         1. 향후 어떤 점에서 위험할 수 있는지
         2. 어떻게 개선할 수 있는지