토스 개발자 컨퍼런스의 프론트엔드 클린코드 관련 컨퍼런스를 보았을 때의 충격이 잊히지 않는다!
왜냐하면 추상화 개념을 처음 접했었고, 코드의 큰 그림에서의 convention, 그리고 내가 자주 실수하는 기능 추가 시에 놓치는 것들에 대한 것을 다루고 있었기 때문이다.
많은 프론트엔드 개발자들이 공감할만한 컨퍼런스 영상이라고 생각한다.(링크)
그래서 또 돌려보았다. 영상 마지막에 클린코드가 무엇인지 글로 정리해보라는 말에 이렇게 게시물을 포스트하려고 한다.
내가 생각하는 클린 코드란?
영상에서는 어려운 클린하지 못한 코드를 다음과 같이 정의한다.
- 흐름 파악이 어렵다.
- 도메인 맥락 표현이 안되어있다.
- 동료(짠 사람)에게 물어봐야 알 수 있다.
- 그래서 클린한 코드는 유지 보수(코드 파악, 디버깅, 리뷰) 시간의 단축할 수 있는 코드라고 말한다.
비슷한 맥락에서 프론트엔드를 98% 정도 혼자 작업하는 내 코드는 나만 알 수 있다. CTO님도 내가 초반에 짠 코드들은 불친절하다고 했다.
해당 영상을 처음 보고 난 후, 추상화라는 것을 생각했지만 결국 빠르게, 급하게, 일주일 단위의 배포 등을 핑계로 다시 원상복구 된 것 같다...😭
내가 생각하는 클린 코드
- 친절한 코드
다음에 어떤 프론트엔드 개발자가 와도 쉽게 이해할 수 있는 코드
- 어떻게 쉽게 이해할 수 있도록 할 것인가?
- 함수명, component명을 누가 봐도 알 수 있게 적자
- 함수는 하나의 역할만을 하도록 하여 And, Or 이런 글자를 함수명으로 사용하지 말자
- hooks를 써서 코드를 응집하려고 할 때, 핵심 정보는 보일 수 있게 작업하자 custom할 수 있는 hook을 짜자
- 추상화 레벨을 맞추자 적어도 한 컴포넌트 안에서는
- 기능이 추가 될 때도 이것을 지키자
- 코드가 길어짐을 두려워하지 말자
- SoC를 통해 필요한 코드들끼리 묶자
코드를 작성하는 것은 한 편의 소설을 쓰는 것과 마찬가지이며, 하나의 훌륭한 코드는 하나의 훌륭한 소설과 같다.
로버트 C.마틴의 "클린 코드"에서
예전에 이 책을 읽었을 때는 "이게 맞나?"라는 생각을 했었다. 코딩을 하면 할 수록 이 말이 무슨 말인지 깨닫는 것 같다.
클린 코드를 적용했을 때, 어떤 모습이 되고 싶은가?
클린 코드를 사내, 개인 프로젝트에 적용했을 때 나는 이런 모습이 되고 싶다.
- 디렉터리와 파일명만 봐도 어떤 역할을 할 파일인지 알았으면..
- 함수명만 봐도 어떤 역할을 하는 함수인지 알았으면..
- hooks와 components들이 props만 넣으면 되게끔 모듈처럼 동작했으면..
- 글을 읽듯 읽히는 코드
이렇게 안짜면 향후 어떤 점에서 위험할 수 있을까?
이렇게 안짜면 내가 이 프로젝트에서 손을 떼는 날에는 훗날 누군가 이 프로젝트를 짠 사람을 쉽게 욕할 수 있을 거 같다..
'그 땐 맞고 지금은 틀리다'라는 말에서 틀리다의 화살표 방향이 나를 가르킬 것 같다.
어떻게 개선할 수 있을까?
- 이전에는 custom hook들을 디렉터리의 규칙 없이 한 디렉터리에 때려넣었다..! 앞으로 코드의 응집성과 추상화 레벨을 고려하여 hook을 더 많이 짜게 될 것 같다. 이것이 영상에서 설명하는 선언적 프로그래밍을 하기 위함과 코드를 더 클린하게 짤 수 있을 것 같다.
- SoC와 응집하기를 통해 관심사를 필요한 컴포넌트, 함수에만 전해준다.
- 하나의 함수에는 하나의 역할만 주자
리팩토링..
솔직하게 말하면 회사의 모든 코드를 리팩토링하기에는 프론트엔드 개발자가 혼자인 상황, 일주일 단위의 배포에서 쉽지는 않을 것 같다.
그래서 나의 목표는 앞으로 짤 코드에 대해서 클린 코드를 도입하여 오늘을 기점으로 누가봐도 clean/dirty가 구분 될 수 있을 코드를 짤 것이다.
