SkyNote2라는 이전에 만들었던 프로그램을 살리고자 하였는데 간만에 코드를 살펴보니 정말 엉망이었다. 당시에는 Qt를 배우던 단계였고 C++도 익숙하지 않았기에 그럴 수 있다는 생각이 들긴하지만 그래도 심난했다. 처음 코드를 만들었을 때가 2018년 1월이라 지금으로부터 1.7년 정도가 지난샘이다. ‘나는 그동안 얼마나 변화했을까?’ 라는 생각이 문득 들어 리펙토링을 진행해 보고자 하였다.

리팩터링은 소프트웨어 공학에서 ‘결과의 변경 없이 코드의 구조를 재조정함’을 뜻한다. 주로 가독성을 높이고 유지보수를 편하게 한다. 외부 화면은 그대로 두면서 내부 논리나 구조를 바꾸고 개선하는 유지보수 행위이다.


네이밍

네이밍 규칙은 전혀 일관적이지 않았고 변수의 이름도 매우 난해하게 만들어져 주석이 없으면 한번에 코드를 이해하기 어려운 구조였다. 현재 필자가 사용하는 네이밍 규칙은 아래와 같다.

  • (파이썬이 아니면) 변수, 메서드 : 카멜 기법(baeJino)
  • (파이썬이면) 변수, 메서드 : 스네이크 기법(bae_jino)
  • bool 변수 : 앞에 is를 붙인 카멜(isBaeJino)
  • 클래스 : 파스칼 기법(BaeJino)
  • 패키지 : 전체 소문자(baejino)
  • 상수 : 전체 대문자 및 언더스코어로 띄어쓰기 구분(BAE_JINO)

또한 변수의 이름은 최대한 변수가 하는 역할을 길게 나열하는 방식으로 작명하여 주석 없이도 읽기 어려움이 없도록 하는 것을 추구하고 있다.


클래스

또한 당시에는 private에 변수를 선언하고 불필요한(set, get) 메서드를 선언하는 것 보다 위와같이 변수를 직접 조작하는게 효율적이라 생각했었다. 또한 한 파일에서 소스코드가 관리되는 걸 선호해서 헤더 파일에 즉시 메서드를 생성하였다.

하지만 최근에 생각이 바뀌었는데 작업할때 자동완성으로 입력 타입을 알려주어 set, get을 선언하는게 더 편리했다.


참조

자주 사용되는 객체임에도 불구하고 클래스 멤버 변수로 선언하지 않아서 필요할 때마다 객체를 생성하는 비효율적인 코드를 작성하였다. 연결된 폼의 경우에는 레퍼런스를 전달하여 한 객체를 여러 폼에서 사용할 수 있도록 변경하였다.


생성자/소멸자

클래스의 구현부는 최대한 헤더파일에 선언하지 않고 소스파일로 분할하여 작성했으며 공통으로 사용되는 변수는 멤버 변수로 초기화는 생성자를 활용하여 중복된 소스코드를 많이 단축시켰다.

또한 설정폼에서 사용자가 설정을 조작할때마다 파일 입출력이 일어나는 비효율적인 로직을 가지고 있었으나 소멸자를 활용하여 파일 입출력을 대폭 줄였다.


지금 생각해보면 정말 당연한 것들인데 뭔가 1.7년 동안 스스로 발전했다는 걸 체감할 수 있었다. (1.7년전 내가 정말 못난 것인가…) 변화된 점은 먼저 다른 사람이 내 코드를 볼 수 있다는 것을 생각할 수 있게 되었다. 혼자 작업하면 변수 이름의 일관성? 사실 중요하지 않다고 생각한다. 적어도 나는 기억할 수 있으니까. 하지만 다른 사람이 본다면 이해하기 어려울 것이다. 함수인지 변수인지 클래스인지 등등…

또한 메모리의 효율, 프로그램의 속도를 어떻게 최적화 할 수 있을지 생각할 수 있게 되었다. 이전에도 생각을 안했던건 아니지만 당시에는 포인터나 참조에 대한 지식이 많이 부족해서 어려움을 겪었다. 파일 입출력이 어느 정도로 느린지 등등을 알게 되었던 것들도 영향을 준 것 같다. 다음 해에도 이번 해에 작업한 프로젝트를 리펙토링 해보면서 스스로를 돌아보는 시간을 가져야 겠다.

WRITTEN BY

배진오

소비적인 일보단 생산적인 일을 추구하며, 좋아하는 일을 잘하고 싶어합니다 :D
im@baejino.com