Clean Code ~Ch.4
사실 나는 주석을 다는 습관이 없다. 이 책에서는 주석을 필요악 으로 소개한다. 나랑 비슷한가? 라고 생각했지만 이는 오만한 생각이었다. 저자는 정말 많은 주석을 보고 경험했지만 나는 그냥 사용하지 않아서 필요한지 모르는 아이다.
이번 챕터를 읽으며 올바른 주석 사용법을 익히는 것을 중점으로 읽었다.
Chapter.4
나쁜 코드에 주석을 달지 마라. 새로 짜라.
지금의 내가 좋은 개발자라고 할 수 없지만 과거보다는 좋다고 가정한다면, 적어도 나는 이 문장을 지키고 있었다.
물론 완벽히 저자의 의도로 지킨 것은 아닐 것이다. 다만 나는 코드를 처음 짤 때부터 주석을 다는 것에 의문을 가지고 있었다. 왜 그런 생각을 가지고 있는 지는 나도 잘 모르겠다. 하지만 추측컨데 내게 코딩을 물어보는 주위 사람들이 짠 코드들에 주석이 가득해서 코드가 아닌 주석을 보고 이해하는 내 모습을 보며 자연스럽게 거부감이 들기 시작한게 아닐까 싶다. (절대 그 사람들을 무시하는 것이 아니다.)
처음에 말했듯이 반대로 나는 주석을 거의 안 달아서 깔끔하지 않은 내 코드를 다른 사람들이 이해 못 하는 경우도 왕왕 있다. 이건 내 안 좋은 점이라 생각해서 나는 좋은 코드와 좋은 주석을 작성하기 위해 노력해야겠다.
몇 초만 더 생각하면 코드로 대다수 의도를 표현할 수 있다.
지금 내가 생각하는 의도가 표현된 코드가 이 책을 다 읽고 생각하는 의도가 표현된 코드가 다를 것이라고 장담하기때문에 책을 다 읽고 내가 다시 블로그 글을 읽을 때, 생각할 수 있겠다는 생각이 들어 이 문장을 골랐다.
주기적으로 TODO 주석을 점검해 없애도 괜찮은 주석은 없애라
내가 Spring을 사용할 때, IntelliJ를 사용한다. IDE는 정말 똑똑해서 내가 TODO 체크를 해둔 것을 모아서 내게 알려준다. 하지만 내가 똑똑하지 않아서… 늘 TODO가 있는 채로 커밋을 한다. 일찍 알아차리면 amend로 고친 후에 푸시할 수 있지만 늦게 알아차리면 결국 내 코드는 지저분해져있다.
후에 나오겠지만 소스 코드 관리 시스템(git)을 적극 활용해서 개발을 하라고 말하고 있다. 하지만 이렇게 지저분하게 깃을 사용한다면 깃이 가지고 있는 강력함과 가능성을 적극 활용하지 못 하게 된다. 결국 나는 내가 작성한 커밋을 믿지 못 하고 내가 작성한 코드를 믿지 못 할 것 같다.
아래에도 다시 서술하겠지만 클린 코드는 코드를 깔끔하게 작성하는 것뿐만 아닌 것 같다. 개발을 하며 내가 작성하는 모든 텍스트를 깔끔하게 작성해야하는 것 같다. 코드는 물론이고 폴더명, 파일명 심지어 커밋 메시지도 마찬가지로.
내가 작성한 글자를 읽고 다른 사람과 문제가 없어야하기 때문이다.
자칫 대수롭지 않다고 여겨질 뭔가의 중요성을 강조하기 위해 주석을 사용
무언가 문제 해결을 하다보면 생각난 풀이 그대로 작성하는 경우가 대부분이지만, 번뜩이는 아이디어로 처리해야하는 로직을 줄이는 경우도 있다.
아마 그 아이디어는 누군가는 이해를 못 할수도 있을 것이다. 그럴 때 주석을 사용하라고 말하고 있다.
1
2
3
4
5
String listItemContent = match.group(3).trim();
// 여기서 trim은 정말 중요하다. trim 함수는 문자열에서 시작 공백을 제거한다.
// 문자열에 시작 공백이 있으면 다른 문자열로 인식되기 때문이다.
new ListItemWidget(this, listItemContent, this.level + 1);
return buildList(text.substring(match.end()));
소스 코드 관리 시스템(Ex. git)이 우리를 대신해 코드를 기억해준다.
클린 코드는 단순히 코드를 깔끔하게 잘 짜는 게 다가 아니라는 것을 조금 느낄 수 있는 구절이었다.
위에도 적어두었지만 우리는 개발을 하며 수많은 툴을 사용한다. IDE뿐만 아니라 Git, 필요에 따라 Notion 및 Slack(or Teams). 이 외에도 Jira 등 다양한 툴이 있지만 사용을 해보지 않아서 제외했다. 물론 Notion과 Teams는 코드와는 조금 거리가 있지만 IDE와 Git은 밀접한 관련이 있다. 우리는 이런 툴을 적극 활용해서 코드를 짜야한다.
저자는 예시로 필요없는 코드는 삭제하라고 말한다. Git을 적극 활용해서 최대한 현재의 코드를 깔끔하게 유지해야한다.
저자는 여기서 말을 끝냈지만 나는 조금 더 깊게 생각해봤다. 우리는 어떤 기능의 개발을 끝내면 커밋 & 푸시 를 한다. 당연하게도 커밋 메시지를 작성한다. 하지만 커밋 메시지가 자세한 내용을 담지 못 한다면 결국 우리는 Git을 사용하지 않는 것과 마찬가지다.
최근 나는 커밋 메시지 컨벤션에 큰 관심을 가지고 있다. 개인적으로 10개의 지저분한 커밋보다 1개의 깔끔한 커밋이 더 가치가 있다고 생각한다.
개발자들 사이에서 유행하는 1일 1커밋이 있다. 나도 한때 이걸 진행한 적이 있다. 이걸 진행할 때는 정말 뿌듯했다. 하루하루 갓생을 산 것 같고 이걸 지속하면 나는 성장해있을 줄 알았다. 조금 과격한 표현일 수 있지만 이는 틀린 방법이다. 물론 커밋의 내용이 정말 높은 퀄리티라면 이는 정말 좋은 방법일 것이다.
하지만 처음에는 나름 퀄리티 있는 커밋을 하기위해 신경썼다. 하지만 약속이 있는 날이나 귀찮은 날에는 그냥 커밋을 했다는 사실에만 신경을 썼고 점차 귀찮아지기 시작하면서 결국 손을 놓았다. 쌓여가는 커밋에 지저분해 보이는건 덤이다..
이런 이유로 커밋 컨벤션에 관심을 가지게 되었고 커밋을 할 때마다 참고하며 지키려고 노력하고 있다.
물론 급하면 안 할 때가 더 많다.