💻 20240527 실무에서 바로 쓰는 Frontend Clean Code

📌 참조

로버트 C. 마틴 클린코드
타입스크립트를 위한 클린코드
실무에서 바로 쓰는 프론트엔드 클린코드

---

📌 개요

React라는 자유로움 안에서 Typescript, Webpack, ESLint등의 조합으로 규율을 만들어서 사용하고 있었다. 추가로, 클린코드, 리팩토링 관련 지식들로 가독성이 좋은 코드를 작성하기 위해 노력했다.

자유함은 논쟁으로 이어졌다. 모든 조직을 겪어 보지는 않았으나, 클린코드, 리팩토링 관련해서 유독 이견들이 많았고, 이는 건전하고 발전적인 대화가 아닌 탁상공론으로 빠졌던 기억들이 떠올랐다.

사람이 모이는 곳에는 정답은 없지만, 언제나 개선은 존재한다고 생각한다. 이번 계기로 클린코드, 리팩토링에 대한 본질적인 지식들을 체득하고 논의함으로서 다음 조직에서 같은 문제가 나타 났을때 개선에 기여하고 싶다는 생각이 들었다.

---

📌 What is clean code?

개발 조직에서 가장 중요한 포인트는 '시간은 곧 돈이다' 코드 파악이 어려운 경우 시간이 할애되고 비용이 빠져 나간다고 생각하면 정말 클린 코드는 중요하다.

조금 서술해서 작성하자면 개발자들에게 병목을 일으키고, 유지보수 시간이 증대되며, 기능 추가가 어렵고, 대게 이런 코드들이 성능도 좋지 못하다.

과거의 나 또는 동료가 짠 코드를 빠르게 이해할 수 있다면, 위 문제들이 해소가 되고 더욱 효율적인 개발 조직이 될 수 있다.

---

📌 언제부터 코드가 지저분해질까?

개발자가 조직에 들어가서 일을 하는 경우, 기존 코드에서 기능 추가 하는 일을 맡을 것이다. 이 부분에서 긴장을 놓치면 클린하지 못한 코드를 작성으로 이어지며, 이 순간들이 스노우볼이 되어 병목을 일으킬 수 있다.

클린코드는 짧은 코드가 아니다.
클린코드는 원하는 로직을 빨리 찾을 수 있는 코드이다.

아래 예시는 기존 코드에서 신규 기능을 추가할 때 주의사항들이다.

1. 하나의 목적을 가진 코드가 흩뿌려져 있을 경우
2. 함수가 여러 가지 일을 하고 있는 경우
3. 함수의 세부구현 단계가 제각각인 경우

---

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

개발자 작업 병목 현상을 일으키는 요인들을 살펴 보았다.
그렇다면, 어떻게 작성해야 원하는 로직을 빨리 찾을 수 있는 코드를 작성할 수 있을까?

응집도

1. 정의 : 같은 목적의 코드는 뭉쳐두자, '선언적 프로그래밍'
2. 절차
   1. 커스텀 훅 활용 : 응집도는 높혔으나, 핵심 기능 파악이 어려움
      • 뭉치면 쾌적 : 당장 몰라도 되는 디테일
      • 뭉치면 답답 : 현재 코드 파악에 필수적인 핵심 정보
   2. 응집도 높히는 방법
      • 남겨야 할 핵심 데이터 : 팝업 클릭 시 액션, 제목, 내용
      • 숨겨도 될 세부 구현 나누기 : 팝업 열고 닫는 상태, 컴포넌트 세부 마크업, 버튼 클릭 시 특정 함수를 호출해야 한다는 바인딩

단일책임

1. 정의 : 하나의 일을 하는 뚜렷한 이름의 함수를 만들자
2. 절차
   1. 한 가지 일만 하는 함수명
   2. 예) 버튼 핸들러에서 로그 전송, API콜 함께 하는 경우
      • 로그 전송 컴포넌트를 만들어 클릭시, 자동으로 전송할 수 있도록

추상화

1. 정의 : 핵심 개념을 뽑아내자, 눈으로 보았을 때, 바로 알 수 있게
2. 절차
   1. JSX 컴포넌트를, 컴포넌트, 동작으로 추상화
      (onConfirm, onSuccess등)
   2. 라벨을 만드는 헬퍼 변수들을 헬퍼 함수로 추상화
   3. 경고 1 : 추상화 수준이 섞여 있으면 코드 파악이 어려움
   4. 경고 2 : 클린 코드가 메인이지 추상화가 메인이 아님을 경계 !!!

---

📌 액션 아이템

1. 담대하게 기존 코드 수정하기
2. 큰 그림 보는 연습하기
3. 팀과 함께 공감대 형성
4. 문서로 적어보기

---

📌 결론

팀 안에서의 클린 코드

• 3, 4번 액션 아이템에 대한 고찰이다.

[공감대 형성]
해당 부분에 대한 공동체 의식이 결여된 상태에서 클린 코드를 독단적으로 도입한다면,
클린 코드가 클린하지 못한 코드로 이어질 수 있다는 생각이 들었다.

[안정적인 코드 검증]
1순위는 안정적인 제품 릴리즈이다. 그렇기 위해서 돌아가는 코드를 만들어야 하고
검증이 테스트 코드를 통해 남아 있어야 한다.

[리팩토링에 대한 논의]
검증이 선행된 상태에서, 현재 우리는 어떤 수준까지 리팩토링 전략을 가져가야 할 지,
논의를 통해 나아가야 하며, 논의를 통해 맞춰진 수준 가운데 PR을 통해 클린 코드에 대한 코멘트를 남기면 좋을 것 같다는 생각이 들었다.

[문서를 통한 리팩토링 수준 버전업]
추가로, 문서 릴리즈를 통해 응집도, 단일책임, 추상화에 대한 적절한 깊이와 수준을 맞춰 나가며 나아간다면, 여러명이 작성 했지만 한명이 작성한 것 같은 순간이 언젠가 찾아오지 않을까 싶다.

개인이 갖춰야 할 클린 코드

• 팀 안에서의 클린 코드가 선행이 되어야 한다.
• 1, 2번 액션 아이템에 대한 고찰이다.

[리팩토링은 필요하다]
Task 단위에서 리팩토링 단위가 존재할 만큼, 리팩토링은 안정적이고 리소스 효율성을 높히는데에 꼭 필요한 작업이다. 단, 위에서 설명한바와 같이 팀 안에서의 클린 코드에 대한 협의가 이뤄진 상태에서 그 수준에 맞게 진행하고, PR을 통해 수정 사항을 적용함으로서 함께 점진적으로 나아 가는것이 중요해 보인다.

[큰 그림 보는 연습하기]
코드짜기 전에 펜을 들고자 노력한다. 현재 내가 작성하는 컴포넌트는 어떤 컴포넌트이고 이 컴포넌트에 목적은 무엇이며, 어떻게 하면 이 컴포넌트가 순수함을 유지할 수 있는지, 불가피하게 그렇지 못하다면 추 후, 어떤 방향으로 이 코드를 수정할 지 다양한 고민들을 작성하고 확신이 들었을 때, 코드를 작성 하는것이 좋을 것 같다는 생각이 들었다.