빼곡 스토어 출시! 그리고 개선방향(feat.코드리뷰)

 

그동안 열심히 개발해온 독서기록 앱, <빼곡>이 드디어 Andorid/Ios 프로덕션으로 출시되었다🎉🎉

그간 겪었던 수많은 난항...과 회고는 뒤로하고,

앞으로의 운영, 그리고 개선방향에 대해 고민해볼때 인것같다.

 

마침 배포와 동시에 좋은 기회로ㅎㅎ 면접을 보게 됐는데, 무려 세시간동안 코드리뷰나 다름없는 면접을 볼 수 있었다.

덕분에 앞으로 리팩토링의 방향성, 그리고 부족했던 부분들을 개선해나갈 인사이트를 얻었다..!

오늘은 이러한 부분을 정리해보려고 한다.

 

---

 

우선 백엔드를 배포하고, 혼자 운영환경에 대해 고민했을때 필요했던 부분은 다음과 같았다.

 

갑분노션

 

전체적으로 코드 자체는 성능과 관련된 정말 운영이슈를 개선하려고 했었다.

현재 API자체는 잘 동작하기 때문에, 성능관련한 고민만 하면 되겠지? 라고 생각했던것 같다.ㅎㅎ

 

 

그런데 코드리뷰를 받으면서, 그동안 내가 작성했던 클래스 자체에서 몇가지 문제점을 발견할 수 있었다(관련 포스팅은 바로바로 링크할 예정이다).

 

1. 잘 돌아가던 클래스가 안되면 그부분만 해결하기 급급했어서, 전체적인 설계 자체에 문제가 생긴것들이 있었다(Bean인 통시에 Util인 클래스, 사용하지 않는 생성자 등)

 

2. 어노테이션을 생략했는데도 잘돌아가는 클래스들이 있었다. 그런데 그 <이유>에 대해서 생각해본적이 없었다.

 

3. 특히 로그인로직 쪽에서, 기존 구현체를 사용하지 않고 다른 구현체를 만들어 사용한 코드가 있었는데, "구체적으로 어떤 로직이 달라서" 따로 만든건지 자세히 이해하고있지 않았다. (그냥 "아 다르구나! 그럼 따로 만들어야지" 하고 넘어갔던것이 화근이였다.)

 

4. ENUM과 같은 타입에서 어떤건 대문자, 어떤건 소문자를 사용했는데, 1인개발이다보니 따로 컨벤션없이 진행해서 이러한 결과가 나왔던거였다(큰 의미가 없었다는 뜻..)

 

5. 응답타입에서 <Void>와 <Null>을 혼용하고 있었다..

 

6. 직접 정의한 Exception클래스의 구조가 좋지 않았다. 어느 하나를 수정하면 내부의 모든 메소드를 수정해야하는 비효율적 구조였다.

 

7. readOnly=true와 같이, 성능적 이점이 있을거라고 추상적으로 생각하고 사용하던 속성이 있는데, 이에 대한 깊은 이해가 필요함을 깨달았다.

 

이외에도 다양한 깨달음이 있었는데...ㅎㅎ 어쨌든 핵심적이였던 부분은 위와같다. 정리하자면 구현에 급급했기 때문에 효율적이지 못하거나, 혼란스러운 클래스를 만들었던거다.

그래서 앞으로는 이부분에 있어서 리팩토링 및 학습을 진행하며, 좀 더 효율적이고 기능에 적합한 코드를 작성하기 위한 공부를 하려고 한다! 앞으로의 포스팅도 이부분에 중점을 맞출 예정이다.