망가진 앱(프로젝트) 리펙토링은 가장 스트레스를 많이 받는 일이다

개발자로 여러 프로젝트를 경험하다 보면 가장 어렵고 힘든 일은 망가진 프로젝트를 다시 리팩토링하는 경우다.

이런 망가진 프로젝트들은 다음과 같은 특징을 가진다.

1. 문서가 없다.

가장 기본이 되는 문서들조차 없는 경우가 많다.

- 사양(정책)정의서

- 화면정의서

- API 정의서

위에 언급한 3가지 문서는 모바일 개발을 위해서 가장 필수가 되는 문서들이다. 이 문서들이 없이는 개발을 진행할 수 없다.

이것 없이 개발한다 하더라도 언젠가는 결국 만들어야 한다. 그런데 망가진 프로젝트들은 보통 이런 기본적인 문서가 존재하지 않는다. 개발을 처음 시작할 때부터 그냥 말로 전달하는 내용을 개발자가 임의로 만들었을 가능성이 가장 높다.

이런 프로젝트를 리팩토링해야 하는 경우가 되면 우선 이 문서들을 다시 만드는데 많은 시간을 쓰게 된다.

소스를 분석해서 화면 단위 기능과, 정책, 주요한 비즈니스 로직들을 찾아낸다.

이 과정이 가장 시간이 많이 걸리고 어려운 과정이다. 앱의 동작을 보면서 소스를 하나하나 읽어가면서 분석해야 하기 때문에 시간도 많이 걸리고, 자칫 잘못된 분석을 하는 경우도 발생한다.

2. 설계의 흔적이 없다.

모바일일 개발을 하다 보면 Android, iOS, Flutter할 것 없이 기본적으로 필요한 기능과 구조가 있다.

제대로 된 프로젝트라면 모바일 특성에 맞게 설계된 아키텍처를 정의하고, 구조를 잡고, 정해진 규칙하에 소스를 확장해 나갈 것이다.

하지만 대부분의 망가진 앱의 소스에는 이런 잘 잡힌 아키텍처나 설계가 없다. 심지어 패키지 구조도 일관성이 없게 되어 있는 경우를 보기도 한다. 가끔 초기에는 구성을 잘하고, 설계를 신경 써서 했지만 시간이 지나면서 처음 구조와 약속들이 모두 깨져 더 이해하기 힘든 소스가 되기도 한다.

3. 주석이 없다.

개발자라면 이런 말을 들어 보았을 것이다.. "소스가 스스로 말을 하도록 자, 의미 있는 클래스와 함수, 변수명을 사용해서 주석 없이도 소스를 파악할 수 있어야 한다." 참 좋은 말이다. 하지만 이건 어디까지나 개발 경력이 많고 설계도 잘되어 있고, 프로그램 능력도 좋은 사람들을 위한 말이다.

물론 그들조차도 필수적인 주석은 달아야 한다.

그런데 대부분의 망가진 프로젝트의 소스들은 개발 실력도 부족한데 주석조차 없는 경우가 많다.

소스를 몇 번이고 보고 또 봐야 겨우 이해할 수 있다. (이건 어려운 프로그램이어서 가 아니라, 그냥 개발자가 못 만들어서 그런 거다)

우리는 한국 사람이다. 아무리 영어로 의미 있는 이름을 지었더라도 한글로 설명된 주석보다 더 쉽게 역할과 동작을 설명해 주지는 않는다.

어차피 자신이 작업한 소스도 나중에 시간이 지나면 무엇인지 기억도 잘 나지 않는 경우가 많은데, 자신과 남을 위해서 제발 주석 좀 달자

4. 테스트 코드?

테스트 코드 따위는 절대 있을 거라고 상상도 하지 말자. 있다 하더라도 쓸모가 없다.

5. 여러 개발자의 손을 거친 프로젝트

앱(프로젝트)의 수명은 그 제품을 담당하는 개발자의 수명 보다 훨씬 길다. 그래서 하나의 앱에 여러 개발자들의 손을 거치는 경우가 많다.

만약 설계도 잘되어 있고, 문서화도 잘되어 있다면 다행이겠지만, 앞에서 말한 것처럼 망가진 프로젝트에는 그런 게 없다. 그러다 보니 앱을 담당하는 개발자마다 소스 전체를 이해하지 못하고 힘들어하다 부득이 처리해야 하는 부분의 기능만 추가하거나 수정하기 마련이다.

결국 이 불쌍한 앱의 소스는 누더기가 되고, 아무도 담당하고 싶어 하지 않는 시한폭탄 같은 존재가 되고 만다.

모든 앱의 소스가 처음부터 망가지지는 않는다. 누군가가 신경 써서 관리하지 않는다면 언젠가 망가지고 말 것이다.

팀이 있다면 특정 앱이나 소스를 개발자 한두 명의 책임으로 떠넘기지 말고, 팀에서 프로젝트와 소스를 잘 관리할 수 있도록 해야 한다.

 

팀원들 공동의 노력으로 잘 관리된 소스는 팀과 개발자 개인의 시간을 아껴주고, 스트레스를 줄여 줄 것이다.