좋은 코드는 오로지 유지보수성 하나로 정의된다 (maintainability)

 

정의한다는 말의 무게

좋은 코드를 논하기 전에, '정의한다'는 말이 가지는 함의에 대해서 가볍게 얘기해보고자 한다.

 

좋은 코드의 정의를 논하려는 것은, 좋은 코드의 속성, 특징, 아니면 자주 보이는 공통점 같은걸 말하려는 의도가 아니다. 어떤 상황에서도, 어떤 환경에서도, 누구와도, 어떤 조건에서도 통용되는 그러한 아주 기초적인 원리원칙을 논하고자 하는 것이다.

 

따라서 "좋은 코드의 정의는 이러이러한데요, 너무 이러이러한 상황이나 저러저러한 조건에서는 그걸 꼭 지키지 않을 수도 있어요"라고 말할 수 있다면 그것은 내가 생각하는 '정의'의 정의에 어긋난다. 그런 관점에서, SOLID 원칙은 좋은 코드의 (꽤 자주 보이는) 특징일 수는 있어도, 좋은 코드의 정의는 아니다. 항상 보이는 것도 아니고, 항상 유효한 것도 아니다.

 

반면에 내가 찾는 것은 진리에 가깝다. 비록 다양한 관측을 통해 귀납적으로 얻어낸 명제일지라도, 절대 빗나가지 않는 그런 문장을 만들고자 하는 것이다 (적고보니 상당히 오만하다).

 

정의 : 유지보수성이 충분하면 좋은 코드다

각설하고, 나는 좋은 코드의 유일하고도 절대적인 정의를 '유지보수성이 충분한가'로 정의한다. 그리 다양한 코드베이스를 봐오진 못했지만, 이것이 내가 보고 듣고 그 외에 직간접적으로 경험한 모든 좋은 코드들의 공통점이자 빠지지 않는 특징이다.

 

왜 유지보수성인가? 죽지 않은 모든 코드는 진화한다. 때로는 죽어있는 것처럼 보이는 코드도, 3년만에 혹은 5년만에 들춰보게 되는 경우가 허다하다. 진화하기 위해선 코드를 변경해야 하고, 코드를 변경하기 위해선 코드를 이해해야 한다. 코드를 이해하기 위해선 코드를 들여다봐야 하고, 이 지점에 유지보수성이 빛을 발한다. 유지보수하기 쉽게 작성된 코드는, 말 그대로, 유지보수하기 쉽다. 나는 이보다 깔끔한 이유를 찾기가 어렵다.

 

아무리 공을 들여도, 우리가 formal method 전략을 취한다할지라도, 버그는 발생하고 장애는 일어난다. 그리고 모든 문제는 코드를 수정해서 해결한다. 따라서 코드를 수정하는 작업에 드는 공수를 최소화하는 것이 모든 코드베이스에 공통적으로 존재해야 하는 속성이라고 생각한다.

 

이 정의가 너무 모호해서 무의미하다고 생각할 수도 있다. 따라서 현 시점, 내 시선에 빗대어, 이 정의가 어떤 식으로 드러나는지에 대해 마저 몇 자 더 적어본다.

 

지표 : 유지보수성이 높다면 이런 경향성이 두드러질 것이다

- 새로 입사한 팀원도, 버그가 발생했을 때 어디를 수정해야 할 지 곧바로 알 수 있다 (어디를, 어떻게, 얼마나 고칠지).

- 새로운 코드를 작성할 때, 비지니스 로직 이외의 모든 것에 대해 고민하지 않는다 (폴더, 코드 컨벤션, 코드 패턴, 사용할 타 함수들).

- 퇴사할 때, 코드에 대해서 인수인계 할 사항이 없다.

 

이 지표들이 아직도 너무 모호해서, 여전히 무의미하다고 생각할 수 있다. 따라서 현 시점, 나만의 시선에 빗대어, 이 지표를 구체적으로 어떻게 달성할 수 있을지 마저 몇 자 더 적어본다.

 

수행 항목 : 유지보수성을 높이기 위해서 이런 시도들을 해보자

를 한참 썼다가 싹 지웠는데, 업무를 진행하면서 쌓아놨다가 나중에 한 번에 정리해보겠음. 모호하게 마무리해서 죄송합니다.

 

 

 

P.S. 내가 새로운 개념을 창조했다고 생각하지는 않는다. 유지보수성이라는 표현은 오만가지 단어와 문장으로 분장하고 수도 없이 많이 개발자들을 두드렸을 것이다. 나는 다만 그걸 더 간결하게 압축하고 싶었을 뿐이다. 한 단어 정도는 모두가 암기할 수 있을거라 믿으며...