프로젝트 소개
fintech의 일종으로써 거의 비슷한 데이터 정보를 받고 이를 조건에 맞춰서 다양한 서비스 기능들을 작동시켜야 했다. 더하여 공동체가 동시에 finance 데이터를 관리하고 구성하는 기능이다 보니 약간의 SNS의 연결성도 포함된듯한 프로젝트였다. 그러다보니 복잡한 데이터와 endpoint 구성을 보내는 기능들이 많았던거 같다.
나에게 할당된 작업
수입 및 지출에 관한 거래 내역
수입 및 지출에 관한 카테고리별 거래내역
총 수입/지출 + 정기 지출 + 변동 지출 추출
거래 내역과 관련된 mock데이터의 생성 (python 이용)
Cloud front를 활용한 AWS S3 구축
나의 개발전략
위와 같은 작업들은 비슷한 데이터를 받아서 사용하여 조건들을 상황에 따라 다양하게 재사용하는 전략을 택했다. 디자인패턴으로 얘기하자면 아래와 같이 flyweight의 패턴을 자주 사용 하였다.
Flyweight - 하나의 인스턴스를 다양한 방면에 공유하며 재사용하는 방식
난 스파게티 코드를 싫어하고 클린 코드를 지키자 주의자라서 복잡한 기능의 API개발에서 이러한 디자인패턴 전략을 적용 하였던거 같다. 더하여 쿼리빌더의 기능까지 적용을 하였다. 이번 기회를 통하여 최대한 하나의 함수로 여러 서비스단에 함수들을 재사용하는 전략들을 많이 경험하였다.
예를들자면 나의 코드는 대략 아래 그림과 같은 구성들이 많았다.
전체구성 DAO - SERVICE - CONTROLER - ROUTES
-1. 하나의 함수를 다양한 함수에서 사용하여 조건문에 따라 다른 결과를 출력하는 경우
-2. 하나의 함수에 다른 변수 parameter를 넣어 다른 결과의 데이터를 출력하는 경우
-3. 두개 및 3개의 함수를 하나의 함수에 다 모아서 활용하여 여러가지 데이터 출력문을 만드는 경우
이렇게 세가지의 전략들이 있었다. 이 기법을 사용하여 레고 만들듯이 기능들을 편하게 구현하면 되었기에 좋은 전략을 적용한거 같았다고 생각이 되었다.
보완과 개선이 필요했던 부분
위에서 말한 3번과 같은 케이스는 경우에 따라서 하나의 함수가 6줄이 넘어가는 함수가 되는 경우들이 있었다. 만약 줄수가 많이 포함된 함수가 한번 오류가 걸리게 되면, 코드를 점검하고 리뷰를 하는데 다소 많은 시간이 걸리고 정리가 안될수 있는 약점을 갖게된다. 즉, 코드를 고치고 업데이트하는 개발 전략에서 이상적인 것은 아니라고 생각이된다. 다음에 개발을 할때는 이러한 함수들은 여러개로 쪼개서 하나로 합치는 전략을 적용 해야될거 같다라는 생각이든다.
