개인앱 ARDust의 리팩터링을 계획..

1년전에 제작한 “iOS ARKit를 이용한 미세먼지 시각화 앱” 이라는 주제로 ARDust라는 앱을 제작하였습니다.

앱스토어에 배포를 하고 난 다음에 버전문제라던지 로직에 오류가 좀 있는 거 같아서 배포를 중단하게 된 비운의.. 앱이긴 합니다. iOS를 처음 시작하면서 계획한 앱이기도 하고 ARKit를 공부하면서 적용해보고 싶은 아이디어가 문득 떠올라 제작하게 되었던거 같습니다.

자 그럼 저의 과거를 반성하며 … 리팩터링이 어떤것이며 왜 내가 리팩터링이 필요한지? 에 대해서 간단하게 생각을 정리해보도록하겠습니다!

왜 리팩터링 할려고 하는가?

회사에서 인턴을 하면서 리팩터링에 대한 얘기도 많이 들었고 또 얼마나 중요한지에 대해서 배웠습니다. 책을 읽으면서 리팩터링에 관하여 조금 생각하게 되었고 단순하게 코드를 갈아엎는다는 개념으로만 생각했었지만.. 조금 생각이 달라졌습니다.

제가 짜온 코드를 돌이켜보면서 사실 잘못된 부분이 많다고 생각은 했었습니다. 코드를 짜면서 “이렇게 해도 될까?,,”, “돌아는 가겠지?,,” 라고 생각하고 넘긴 부분이 많았습니다. 이런 잘못된 습관들이 프로젝트 전체의 악영향을 끼친다는 것을 알면서도 말이죠..

사실 이런 ‘잘못’ 되었다는 부분은 그때그때 최적의 성능과 그런 결함들을 바로잡을 수 있게 해주어야 합니다. 하지만 핑계아닌 핑계로 “배포일이..얼마남지 않아서..”, “ 기한이 촉박해..” 라는 등의 이유가 붙기마련입니다. 저같은 경우에는 “일단은 기능구현해볼꺼니깐!! 로직이야 어떻게 되는 나중에 나에게 맡기자” 라는 마인드였습니다.

네.. 과거의 나에게 조금 화나기도 합니다. 사실 이런 “기한의 핑계”는 설득력 있는 이유는 되지 못합니다. 조금만 더 내다 보았을때 나중에 신경 써야할 중복 문제와 의존성 문제 등을 수정하기 위해 지금보다 배의 시간을 투자해야하기 때문에 초기진압 이 중요하다고 생각합니다.

“일찍 리팩터링 하고 자주 리팩터링 해라”

-실용주의프로그래머 책에서-

그런 이유에서 저의 개인앱인 ARDust를 리팩터링 해보고 또 AR기능에 대한 조금더 로지컬한 기능을 추가해서 보다 퀄리티 높은 기능으로 재탄생 시켜볼까 합니다.

근데 리팩터링은 언제 하는거야?

리팩터링을 하는 이유는 사실 크게보면 그렇다. 코드가 ‘잘못’ 되었기 때문에 하는 것이다. 어떤 것이라도 리팩터링의 사유는 될 수 있지만 정리를 해보자면 아래와 같습니다.

• 중복을 발견했을때
• 서로 코드의 decoupling(결합)이 심해 직교성을 해치는 경우, 즉 서로에게 영향을 지대하게 주는 경우(의존되어있을때와 같은 경우)
• 오래된 기술
• 성능

이유를 뽑아보자면 크게 위의 4가지 정도이지만, 사실 개개인의 프로젝트에 따라 뭐든 이유가 될 수 있다고 생각합니다. 가장 중요한것은 잘못된 코드를 망설이지 말고 즉시 수정하는 것이 바람직하겠죠?

거창한 이유 잘 들었다 그래서 ?

사실 리팩터링을 하는 이유는 입사해서도 리팩터링에 대한 업무를 아마 할 수도 있기 때문에 한번은 경험해보고 싶어서 입니다. 회사에서 리팩터링은 팀원과의 충분한 의사결정을 통해 진행되는거고 보다 더 복잡하고 조심스러운 부분일 것이라 생각이 듭니다. 개인이 하는 갈아엎는식의 리팩터링이라는 차원이 다르겠죠.

그렇기 때문에 저는 저 나름대로의 체계적인 리팩터링을 계획해보고 또 거기에 대해서 달성하는 것을 기록하면서 나름의 채찍질을 가미할까 생각합니다.(그래야 하기 때문에;;;)

조금 부끄럽더라도 과거에 내가 짠 코드 그리고 그 코드를 조금 비교하면서 개선된 코드 그리고 놓친 부분이나 몰랐던 부분을 매일 업로드를 통해 공유하면서 조금 재설계에 가깝게 해보려고 합니다.

어떻게 할꺼야?

우선 기존 코드의 문제점을 한번 나열해 보겠습니다.

• MVC로 인한 Massive View Controller
• 아키텍쳐 패턴의 부재
• 객체사이의 의존성 다수 존재 -> 의존성 주입
• 추가적인 기능 구현
• 기존의 ARKit의 미세먼지 로직 개선
• Unit Test/UI Test
• UI Custom View 구현/ UI Design & Animation 효과

이렇게 나열 해보았습니다.

우선 지금 프로젝트의 경우 MVC(ModelViewController)의 패턴이 적용되어있지만 하나의 View Controller에서 날씨 정보,미세먼지 정보 등을 다 보여주다보니 ViewController가 상당히 거대해 진 문제점이 있습니다.

그렇기 때문에 MVC의 이런 문제점을 보안하고자 MVVM을 적용해볼까 합니다. 그리고 API를 요청하는 네트워킹 부분의 경우 비동기제어를 하기 위해 다양한 외부라이브러리 등을 사용해서 한번 시도하고자 합니다.

Rx의 경우 사실 비동기제어의 하나의 방법일 뿐이지 정답이 될거같지는 않습니다. 그렇기 때문에 다방면으로 한번 접근해보고 궁극적으로 비동기제어의 목적이 무엇인지에 초점을 두고 코드 작성을 해야한다고 생각이 들었습니다.

그리고 객체사이의 의존성을 최대한 줄여볼까 합니다. 가령 양방향으로 의존하는 클래스들이 몇개가 보였고 추후에 유닛테스트 시에 문제가 될 수 있는 부분도 존재하는 것 같습니다. 그렇기 때문에 의존성이 없는 경우 최대한 제거를 하는 것이 바람직 하므로 이 부분을 개선해볼까 합니다.