강의에 대한 리뷰

지난 주에 이어서 Readable Code를 진행했다.

코드 다듬기, 리팩토링 연습, 기억하기 좋은 조언들, Outro 섹션을 진행하였고 Readable Code 강의는 마무리 되었다.

저번 주 학습한 내용은 Readable Code를 어떻게 구현하는 가에 가까웠다면, 이번 주 학습 내용은 잘 정리된 Readable Code를 좀 더 정갈하게 정리해보자. 라는 느낌이었다.

예를 들면, 섹션 6. 코드 다듬기에서는 주석의 양면성과 메서드 나열 순서, 패키지 나누기 등을 학습한는데, 내 생각에 이 주제들은 구현보다는 정리이기 때문에 강사님도 코드 다듬기라고 한 것이라 추측한다.

강의 내용

주석이 많다는 것은 비즈니스 요구사항을 어떤 방법으로든 코드에 잘 녹여내지 못했다는 뜻이다. 하지만 코드에는 도저히 녹여낼 수 없는 것들도 존재한다. 예를 들어 해당 코드에 대한 의사 결정 히스토리는 코드에 담아내기 어렵다. 나 역시 실무에서 레거시 코드를 봤을 때, "이렇게 하면 쉽고 깔끔할 것 같은데 왜 이렇게 복잡하고 어렵게 했지?" 라는 생각으로 리팩터링할 때가 종종있다. 이후에, 알고보니 그렇게 짜놓은 이유가 있는 코드였었다. (물론 10번 중에 한 두 번만..)

클린코드와 주석에 대한 의견이 꽤 분분하다고 알고 있다. 모든 클래스와 메서드에 주석을 작성하기를 권장하는 사람들도 있는 반면, 이를 모두 코드에 담아내라는 사람들도 존재한다. 나는 아직 경험이 적기 때문에 정답은 잘 모르겠다. 하지만 자바, 스프링 등 구현된 소스를 보면 클래스 단위에 주석이 작성되어 있는 것이 좀 더 공부하기 좋았다. 주석은 상황, 팀 컨벤션 등에 따라 선택하면 될 것 같다.

또, 메서드 나열 순서에 대해서도 배웠는데, 이건 정답이라기 보다 뭐랄까... 좋은 습관 정도라고 생각한다. 생각해보면, 메서드의 순서는 그 순서를 알고 있는 사람에겐 Readable 하지만, 모르는 사람에겐 아무 도움도 되지 않는다. 어찌됐든 혼자 하든 같이 하든 메서드 나열 순서에 대한 컨벤션이 있으면 Readable 하겠다 라는 생각은 한다.

다음은, 기억하면 좋은 조언들 섹션에 대해 얘기해보려 한다.

그 중, 오버 엔지니어링과 은탄환은 없다 섹션을 감명깊게 봤다. 최근에 내가 시도하려했던 사이드 프로젝트가 오버 엔지니어링으로 흐지부지 된 경험이 있다. 정확히 말하자면 오버 엔지니어링을 시도하다가 흐지부지 됐다고 하자. 클린코드나 Readable Code에 대한 건 아니고, 개발 하기도 전에 이것저것 (Sonarqube, Jacoco, Jenkins, Spring security...) 다 붙여놓은 다음에 개발하려다가 개발을 제대로 해보지도 못하고 지쳐서 흐지부지 되어버렸다. 작동하는 작은 단위부터 하나씩 쌓아올려야 한다는 점을 다시 되새겼다. 테스트 코드 작성에 대한 강의를 듣고 다시 시도해볼 것이다.

미션

이번 주는 미션이 하나밖에 없었다.

스터디카페 키오스크에 대한 코드를 지금까지 배운 것을 토대로 리팩터링하는 것이었다.

가장 어려웠던 것은 추상화 레벨에 대한 것이다. 아직 추상화 레벨을 맞추는 게 어렵다. 추상화 레벨의 기준이라는 것도 잡기 어렵다. 이 부분은 꾸준히 생각하며 개발하다 보면 코드에 대한 사고가 변할 거라 생각한다.

회고

나는 무엇이든 진득하게 못하는 것 같다. 다음 할 일이 있으면 그것을 위해 이전에 하던 것을 최대한 빠르게 마무리하고 넘어가려는 성향이 있다. 이런 성격만 바꾸면 조금 더 좋은 사람, 더 좋은 개발자가 되리라고 확신하는데 알면서도 그게 잘 안 된다. 이 부분을 바꿀 수 있는 방법에 대해 좀 더 고민해보고 알아봐야겠다.