[지속 가능한 Frontend개발] Clean Code

면접을 볼 때 자주 하는 질문이 있다.

"좋은 코드란 어떤 코드라고 생각하시나요?"

지원자의 90% 정도는 가독성이 좋은 코드를 말하고 그 가독성에 대해 재차 물으면 클린코드를 말하면서 사실 추상적이게만 대답한다.

개발자들이 클린코드, 클린코드 하면서 왜 가독성이 중요한지, 또 정확히 어떻게 해야 가독성이 좋아지는지에 대해 잘 모르는 경향이 있다.

이 포스팅에서는 클린코드의 기술적,이론적인 것을 말하는 것이 아님을 먼저 말한다.

이런 부분은 다른 블로그나 문서나 책을 보면 어렵지 않게 접근할 수 있다.

 

1. 클린코드는 정답이 없다. 

아니 다르게 말해서 개인 또는 조직의 기준과 성향에 따라 클린코드는 달라진다고 생각한다. 

코드 스타일도 airbnb나 google이나 각 조직마다의 방식이 있는 것이고, 조직마다 코드는 읽는 방식 또한 다르기 때문이다. 

즉 클린코드를 한다고 하더라도 상황에 따라서 같은 코드가 best case 가 될 수도, worst case가 될 수도 있는 법이다.

 

클린코드를 하기 위해 다양한 장치들이 있다. 디자인패턴이나 아키텍쳐나 어떤 정형화된 것들이 있는데 

맹목적으로 그 정형화된 것들을 따르다 보면 생각과 고민의 과정이 부족하게 되고 왜 이런 사람(또는 조직)이 이렇게 만들었을까라는 이해가 부족하게 된다.

그렇다면 그 클린코드의 판단을 할 수 없게 되고 그런 사람의 코드는 파편화된 부분이 많이 보이게 되기 마련이다.(본인이 그랬다)

 

2. 가독성에 대해서도 생각을 해보자.

어떤 코드가 가독성이 좋은 것인가? 아무래도 코드량이 적으면 읽기 편하지 않을까?

물론 짧은 코드가 읽기 좀 나을 수 있겠지만 

가독성은 짧은 코드보단 원하는 로직(도메인, 프로세스 등)을 빠르게 찾을 수 있는 코드 라고 생각한다. 

클린코드하면 단일책임원칙이라든지, 추상화라든지, 응집시킨 다든지 SOLID 다양한 규칙들이 있는데 

이 목적이 짧은 코드가 나오게 하는 것이 아니라, 원하는 로직을 빠르게 찾을 수 있기 때문이다

 

추가로 원하는 로직을 더 빠르게 찾는 방법은 무엇인가?

바로 개발자간 합의다.

'우린 스타일 코드는 여기에 이런 방식으로 합니다'

'우린 도메인 부분은 이 디렉토리에 이런 파일형태로 이렇게 합니다' 

라고 합의되어 있다면 엄청 빠르지 않을까?

그럼 가독성이 좋은 코드는 어쩌면 클린코드가 아니라 개발자간 합의된 코드이지 않을까?

 

3. 클린코드는 사실 개발자에게 중요하지 않다.

개발을 하다보면 여러가지 변수들이 생긴다

(없던 적이 없는 것 같다)

요구사항의 변경이 있을 수 있고, 환경이 바뀔 수도 있고, 문서와 다른 결과를 제공해줄 수도 있고, 유저스토리가 바뀔 수도 있다.

그러다보면 아무리 클린코드를 하고자 하였더라도 이런 변수를 소화하다보면 

그 코드가 클린하지 않다는 것을 알게 될 것이다. 그러면 어떻게 해야하는가?

두가지 방식이 있는데 이런 여러가지 변수가 있다는 것을 예상하고 변수를 커버할 수 있게 만드는 방식이 있고, 

일단 빠르게 만들고 나중에 리팩토링하는 방식이 있다.

 

두 방식은 변수를 소화할 수 있지만 이 방식 또한 각각의 문제가 있다. 

예상하는 방식은 오버엔지니어링이 될 가능성이 매우 높으며

리팩토링 방식은 나중에 해야지하고 미뤄두면서 리팩토링 안하는 경우를 꽤 많이 봤다. 

 

그래도 많은 사람과 조직이 선택한 TDD만 봐도 

일단 테스트를 통과하게 만든 후, 리팩토링 하는 것을 선택하는 것을 봐선 

후자를 선호하는 것이 아닐까 생각이 든다. 

(아무래도 오버엔지니어링은 좀..)

 

각설하고, 

클린코드는 짧지 않은 미래의 나와 조직을 위한 것이므로
클린코드를 추구해야하지만 실제로 대부분의 조직은 생산성 측면에서 trade-off를 요구하게 된다.

 

하지만 대이직의 시대에서 클린코드는 

개발자 개인이 챙겨야하는 부분이 아니라 조직이 챙겨야하는 부분인 것인데, 아직 개인의 역량으로만 판단되는 것 같다.

물론 조직이 요구하는 대로 할 수 있는 개인의 역량이 필요하지만 

결국 조직이 해당 조직의 클린코드를 정의할 수 있고 그 룰을 만들 수 있으며 그 가치 또한 조직에서 제공받을 수 있다.

따라서 

소제목에서 어그로를 끌었지만

클린 코드는 사실 개발자보다 조직에게 중요하므로 조직에서 챙겨야 하는 부분이다.