좋은 코드를 만나는 일

프로젝트 코드를 개선하기 위해 리팩토링 문서를 찾아서 읽었다. 문서 안에는 나쁜 코드와 좋은 코드의 예시가 있었는데 나는 나쁜 코드를 보면서 어디에서 코드 스멜이 나는지, 어느 부분을 개선해야 좋을지 고민하면서 공부했다. 특히 기억에 남는 부분은 함수가 하나의 역할만 해야 사이드 이펙트를 피할 수 있고 가독성도 좋아진다는 것과 함수 이름 자체가 그 역할을 드러내야 한다는 점, 변하는 데이터 타입은 원본이 변경되지 않고 유지되어야 한다는 점이다. 지금 하고 있는 요가림 프로젝트를 구현할 때 고려하지 못한 부분이라 어서 적용하고 싶다는 생각이 들었다. 그래서 리팩토링할 내용을 다시 정리하자면 변수명 체크, 함수 역할 분리, 객체, 배열 데이터 원본 유지하는지 확인해야겠다. 과연 나는 적절한 변수명 짓기 산을 넘을 수 있을 것인가

---

기능 추가에 관하여

기능을 추가하기 위해서는 ‘이게 있으면 좋을 것 같은데..’라는 모호한 생각을 넘어서서 명확한 이유가 필요하다. 왜냐하면 구현하는데 시간과 노력이 들고, 구현하고 보니 있으면 좋겠지만 없어도 크게 문제가 되지 않는 기능일 수도 있기 때문이다. 프로젝트를 하면서 개선해야 할 부분이 점점 더 보이는데 그 모든 걸 한 번에 할 수는 없으니 일의 우선순위에 대해서 고민하게 된다. 이거 왜 필요하지? 지금 작동안하나? 그건 아닌데 사용성이 더 나아질까? 근데 처음해보는 거라 구현이 어렵네. 얼마만큼의 시간을 투자해볼까. 내가 정해놓은 배포가 미뤄지면 안되는데. 라는 생각을 자동적으로 하게 된다. 이 모든 생각은 모바일에서 통증 점수 매길 때 터치가 가능하게 끔 추가하려다 나오게 되었다.