리팩터링: CHAPTER 03

코드에서 나는 악취를 읽으며

냄새 나면 당장 갈아라.
- 켄트 벡 할머니의 육아 원칙

인스턴스 변수는 몇 개가 적당한지, 메서드가 몇 줄을 넘어가면 안 좋은지 등은 각자 경험을 통해 감을 키워야 한다.

해당 챕터의 시작 문구만 봐도 이번 챕터는 어떤 이야기를 하고 싶은지 바로 알 수 있었다.
이번 챕터에서는 당장 리팩터링에 대한 기능보다는 리팩터링을 언제 시작하면 좋을지 개인의 판단과 경험이 매우 중요하다고 강조하고 있다.

기이한 이름

추리 소설이라면 무슨 일이 전개되는지 궁금증을 자아낼수록 좋지만, 코드는 아니다.
이름만 보고도 각각이 무슨 일을 하고 어떻게 사용해야 하는지 명확히 알 수 있도록 엄청나게 신경 써서 이름을 지어야 한다.

글쓴이는 해당 문구에서 엄청나게라는 단어로 강조했다.
프로그래밍을 하다보면 변수명이나 함수명을 짓는데 생각보다 꽤 많은 시간이 걸릴 때가 있다. 오죽하면 개발자는 이름짓는 사람이라는 농담이 있겠냐마는ㅎ
이런 고민을 한다는 것 자체는 긍정적인 신호가 아닐까 싶다.
현업에서 이렇게 습관이 되다보니 혼자 알고리즘을 풀때도 변수명을 고민할 때가 많았다. 예전에는 그냥 a, b와 같은 방식으로 많이 넘어갔지만 정확히 해당 변수가 하는 역할을 최대한 적어두려고 한다.
이름을 짓는데 어려움을 겪고 있다면 ChatGPT에게 물어봐도 좋을 것 같다. 정말 잘 만들어주더라...짱.

긴 함수

우리의 경험에 비춰보면 오랜 기간 잘 활용되는 프로그램들은 하나같이 짧은 함수로 구성됐다.
함수 이름을 잘 지어두면 본문 코드를 볼 이유가 사라진다.

이거야말로 제곧내(제목이 곧 내용)이 아닐까 싶다.
이번 마이그레이션 중에도 호스트가 해당 스페이스의 방문 기록을 다운받는 기능을 구현하려고 했는데 기존 함수가 너무 길어서 현재 당장 못건드리고 있는 코드가 있다.
역할 자체는 서버로 받아온 데이터를 여러 예외처리를 거친 뒤 엑셀 파일로 추출해주는 기능인데, 주석이 없이 함수가 너무 길어서 당시의 기획의도였던 예외처리등의 부분을 해석하고 있을 시간이 없어 우선 해당 기능은 보류처리 해두었다.
커피타임을 가지면서 코드의 원작자는 해당 코드가 간단하니 옮기는데 큰 문제가 없을 것이라고 했지만 코드를 보는 다른 사람의 입장에서는 생각보다 복잡한 코드일 수 있겠다는 생각이 들었다. 나도 이런 코드를 작성할 수 있으니 조심하자.

함수 이름은 동작 방식이 아닌 '의도'가 드러나게 짓는다.

이 부분을 보니 어찌보면 현업에서의 프로그래밍은 코드를 작성하는 사람이 아닌 코드를 보게될 사람 즉, 프로그래밍의 의도를 파악해야하는 사람을 위한 장치라는 항상 마련해야한다는 생각이 들었다.
글쓴이는 사실 내가 당장 작성한 코드도 다음 달에 보게되면 다시 그 코드를 이해해야하는 사람이 되기 때문에 코드를 잘 리팩터링해두어야 한다고 했다.

추측성 일반화

추측성 일반화는 우리가 민감하게 반응하는 냄새로, (...) 이 냄새는 '나중에 필요한 거야'라는 생각으로 당장은 필요 없는 모든 종류의 후킹포인트와 특이 케이스 처리 로직을 작성해둔 코드에서 풍긴다.
그 결과는 물론 이해하거나 관리하기 어려워진 코드다. 미래를 대비해 작성한 부분을 실제로 사용하게 되면 다행이지만, 그렇지 않는다면 쓸데없는 낭비일 뿐이다. 당장 걸리적거리는 코드는 눈앞에서 치워버리자.

스프린트를 진행하면서 느낀 점은 기능을 구현하고 qa를 거치면서도 느끼는 부분이지만 정말 유저는 서비스를 사용하면서 어떤 행동을 할지 예측하기 정말 어렵다는 것이였다.
유저의 모든 돌발행동들을 예측해서 프로그래밍을 한다는 것은 정말 어려운 일인 것 같다.
qa파트에서도 시간이 부족할 때가 많아 많은 부분에 대응을 해보지 못해보더라도 서비스의 많은 빈틈을 볼 수 있었는데 유저의 행동은 정말 대응하기 어렵다.
그런 것들을 모두 대응하기보다 정말 필요한 때의 대응들을 추가해나가다보면 서비스의 빈틈을 줄이면서 좋은 코드를 작성할 수 있지 않을까싶다.

중개자

여러분이 팀장에게 미팅을 요청한다고 해보자. 팀장은 자신의 일정을 확인한 후 답을 준다. 이러면 끝이다. 팀장이 종이 다이어리를 쓰든, 일정 서비스를 쓰든, 따로 비서를 두든 우리는 알 바 아니다.

함수나 클래스가 내부적으로 처리하는 로직은 알바가 아니다라는 뜻인걸까...?
그렇다는 뜻이라면 내가 코드를 짤 때는 해당 부분의 기능을 캡슐화하고 잘 사용하게 만들어두려고 노력한다.
그런데 또 현업에서 프로젝트를 진행하다보니 남이 작성한 코드를 분석해보고 비교해보고 싶을 때가 있다.
개발 1년차로서 실력에 대한 욕심이 늘어나고 있다보니 남이 잘 숨겨둔 코드를 분석하는데 시간을 쓸 때가 많다...좀 더 속도를 높이고 싶다.

주석

주석은 악취가 아닌 향기를 입힌다. 문제는 주석을 탈취제처럼 사용하는 데 있다. 주석이 장황하게 달린 원인이 코드를 잘못 작성했기 때문인 경우가 의외로 많다.

v1 프로젝트엔 주석이 정말 많이 없어서 초반 입사 당시에 많은 고생을 했었다. 주석의 많은 필요성을 느꼈고 현재 프로젝트를 진행하면서도 주석을 통해 해당 코드의 의도를 전달하려고 노력하고 있다.
그러면서도 어쩌면 나는 주석을 탈취제로써 사용하고 있지 않은지 생각해보았다.

주석을 남겨야겠다는 생각이 들면, 가장 먼저 주석이 필요 없는 코드로 리팩터링해본다.

나도 주석을 봐야만하는 코드가 아닌 주석이 필요없는 코드를 작성하고 싶다.

마무리

이 외에도 많은 소제목의 내용이 있었지만, 당장 추후에 나올 리팩터링 내용의 대한 부분을 요약해서 미리보기처럼 설명하고 있어 이해하기 어려운 부분이 많아 당장 이해할 수 있고 와닿는 부분만 우선 정리해두었다.
나중에 여기서 얘기한 부분들을 읽어보고 다시 읽어본다면 많은 부분에서 공감하고 이해할 수 있을지 기대된다.
오늘도 아침스터디 끝!