tidy first 8장 '설명하는 변수' 를 읽고

 

잊지 않으려고 노력하는 말이 있습니다.
그 자체로 설명이 가능하다는 것을 뜻하는 'self-descriptive' 와
'코드 자체가 문서가 되게 하라' 는 말 입니다.

 

말 자체에 대한 이해는 어렵지 않게 할 수 있지만, 보통 현실은 이론과 다른 경우가 많아 실무에 적용하는 것을 또 다른 문제라고 생각 합니다.

 

항상 같은 텐션을 유지하기란 쉽지 않고, 변경 사항에 대해 동기화를 유지하는 것도 쉬운 일은 아니라고 생각 합니다. 지금까지 그래왔던걸 봐왔기 때문이기도 합니다.

 

다양한 이유로 의미 없이 남게 된 주석들과 사용하지 않는 코드들이 가득한 레거시가 되고, 이것들은 가독성을 해치고 더 나아가 단순히 읽어 내려가기 어려운 수준을 넘어 오개념을 심어주기도 합니다.

 

그래서 특히, 2장 '안 쓰는 코드' 에서 말하는 '지워 버리세요. 그게 다입니다.' 에 특히 더 공감 했습니다.

 

 

그럼에도 주석 없는 코드와 동화책 처럼 읽히는 코드를 작성하기 위해서는, 약속된 구조에 코드를 작성하는 것도 중요하지만, 늘 함께 있어 소중함을 깜빡하는 변수의 이름을 짓는 일을 소홀히 해서는 안되겠다고 다시 한 번 생각 했습니다.

 

가끔 주석 없이 표현 해보겠다고 장고 끝에 긴 이름의 변수를 만들면, '이럴 거면 용어 사전에 그럴듯한 이름을 가져다 조합해서 쓰고, 주석에 설명을 잘 남겨놓자' 는 결론에 도달하기도 합니다. 약간 다른 얘기로 새지만, 주석이라는게 생각 하면 할 수록 잘 쓰면 약이고 못 쓰면 나 뿐만 아니라 모두를 죽일 수 있는 독이라는 생각을 많이 합니다.

 

혹여나 변수 이름을 짓기 어렵다면, 다른 문제가 (예를 들면, 모호한 도메인 정의, 풀고자 하는 문제를 해결할 수 없는 구조 등) 있어서는 아닐지 되돌아보고, 더 늦기 전에 개념부터 재설계 하는 것을 고민해보는 것도 좋겠다 생각 했습니다. '아 이거 아까운데, 지금 하기엔 늦었는데' 라고 생각 할 때가 복잡도가 제일 낮은 순간입니다. 물론 그런 문제에 마주했을 때는 여력이 없겠지만, 신뢰하는 조직 내에서는 못할 것도 없겠다는 생각 입니다.

 

추가로 짧게 언급 된 '코드 정리에 대한 커밋과 동작 변경에 대한 커밋은 분리' 한다는 부분에서 한 편의 소설을 읽는 느낌을 받을 수 있을까 상상 했습니다. 소설을 읽으면서 작가를 상상하듯 일련의 커밋들을 보면서 작성자의 내면과 무의식을 옅볼 수 있겠다는 생각을 했습니다. 그래서 코드 리뷰에 익숙하지 않은 사람은 첫 걸음을 떼기 더 어려운 것 같습니다.