회사 프로젝트 마무리를 하며

Dokkabei97·2022년 8월 20일
0

일상

목록 보기
1/6

프로젝트

2022.08.19 회사에서 진행한 프로젝트가 끝났다, 대략 4개월 정도 진행 했다

프로젝트 기술은

  • Server
    • Java 11
    • Spirng for GraphQL
  • Client
    • Flutter

프론트엔드

프로젝트 초기 디자인팀에서 준 Figma 사이트를 들어가 디자인을 보며
Flutter를 개발했다, 처음 팀에서 도입한 Flutter라 아쉬운 게 많았는데

2가지만 뽑자면
1. Lint
2. TDD
이렇게가 있다

초기에 Flutter를 빠르게 학습 후 바로 프로젝트에 투입되면서 따로 Lint를 설정한 게 없다 보니
나와 동료의 코딩 스타일은 너무 달랐고 중반부터 나는 주로 백엔드 개발을 하다 보니 종종 내가 초기에 개발한 부분을 동료가 맡아서 개발한 부분이나 혹은 동료가 휴가 가서 급하게 수정이 필요할 때 내가 맡으면 코드를 읽는데 시간이 매우 많은 시간이 필요했다.

  Widget _itemButton(
      {required String icon,
      required double iconSize,
      required String label,
      required Function onTap}) {
    return InkWell(
      onTap: () => onTap,
      child: Row(
        children: [
          Container(
            width: 50,
            height: 50,
            decoration: BoxDecoration(
              shape: BoxShape.circle,
              color: Colors.grey.withOpacity(0.3),
            ),
            child: Center(
              child: Container(
                width: iconSize,
                height: iconSize,
                child: SvgPicture.asset("assets/svg/icons/$icon.svg"),
              ),
            ),
          ),
          SizedBox(width: 15),
          Text(label)
        ],
      ),
    );
  }

Flutter 학습 때 클론 코딩한 코드 중 일부

큰 이유로 Flutter의 코드 스타일에 있다.
위와 같이 Flutter 코드는 라인이 길어져서 나는 UI 컴포넌트마다 dart 파일을 만들어서 뺀 방면 동료는 초기에 한 dart 파일에 컴포넌트를 만들고 또한 안 쓰는 코드 주석 적게는 수십 줄에서 많게는 수백 줄을 안 지워서 몇 페이지는 천 줄이 넘는 대 참사가 일어났다.

그래서 한 번은 작업하기 전에 컴포넌트를 전부 빼고 주석 제거하는 리팩토링 작업만 날 잡고 해서
천 줄이 넘는 코드를 100줄까지 줄이고서 작업을 한 적이 있다.

위와 같은 상황을 다시 보기 싫어서 동료가 코드 천 줄이 넘는 페이지를 작업할 때 타이밍 맞춰서 컴포넌트 분리와 안 쓰는 코드는 제거 요청을 해서 프로젝트 중후반부터는 위와 같은 일이 없었지만 변수 명과 일부 함수 명이 아쉬운 점이 있는데 프로젝트 초기에 lint를 알았고 설정했다면 어땠을까 싶다는 아쉬운 점 있다.

다음 TDD도 위와 같이 빠르게 작업을 하다 보니 dart 테스트 코드를 작성하는 법을 몰랐고
나는 중반부터 백엔드를 집중하다 보니 나중에 내가 다시 flutter를 개발할 때 테스트 코드를 작성하는 법을 학습하고 테스트하기에는 시간이 부족했다고 판단했다 그래도 hotreload 기능이 있기에 빠르게 직접 UI를 누르며 테스트가 가능했다고 생각한다.

당장은 아니지만 나중에 flutter 개발 때 사용할 사내 라이브러리를 제작하자는 의견이 있었고 그때는 lint와 TDD를 도입하기로 했다.

백엔드

다음 백엔드 이야기다.
백엔드는 내가 잘 다루는 Spring으로 결정했고 Java 와 Kotlin 결정할 때
Kotlin은 좀 학습이 더 필요하고 회사에서 Kotlin + Spring을 다루는 사람이 당장 없어
Java로 선택했고 LTS 버전인 11버전을 사용했다.

그리고 REST API vs GraphQL 선택에 있었는데
GraphQL은 정말 처음이라 학습이 필요했지만 그렇다고 REST API라고 내가 잘 다룬다고 하기에는 백엔드를 개발한 시점에서 4개월 차 신입 입장에서 별 차이 없을 거라 생각했고 팀에서 신기술을 맡는 만큼 GraphQL이 신기술이라고 하기에는 그렇지만 그래도 사내에서 한 번도 사용된 적이 없기 GraphQL을 선택했다.

Java에서 GraphQL을 사용하기 위한 라이브러리를 조사하다가
Spring 측에서 개발하고 있는 GraphQL 라이브러리를 발견 했고 해당 라이브러리를 선택했고
Spring for GraphQL로 개발 할 때 1.0.0 M3 버전이라 공식버전 아니여서 참 많이 고생했다.

라이브러리에 대한 이야기와 버전에 대한 고생은 아래 회사 기술 블로그에 포스팅한걸 참조 바란다.

처음에 삽질한 거는 GraphQL의 장점을 못 살렸다.
REST API 마냥 DTO를 하나하나 만들어 반환해 주다 보니 너무 힘들었다.
mapstruct를 사용했다면 편했겠지만 당시에는 몰랐고 또한 보여주면 안 되는 민감한 정보만 제거한 DTO 1개만 만들고 나머지는 GraphQL 쿼리를 통해 원하는 것만 보여주면 되는데 초반에는 필요한 정보만 보여주는 DTO를 전부 다 만들어 반환해 주어 GraphQL의 장점 없이 사용했다.

그러다 백엔드 개발 초중반쯤 다시 GraphQL을 생각했고 잘못하고 있다는 걸 깨닫고 DTO를 싹 제거하고 민감한 정보만 제거한 DTO 1개로 반환하는 식으로 개발해 GraphQL의 장점을 살렸다.

아마 해당 라이브러리를 사용한 프로젝트는 국내 최초 아닐까 싶다.
서비스 런칭은 힘들꺼 같은데 서비스 까지 했으면 세계최초 타이틀 까지 달 수 있을꺼 같다 ㅠㅠ

인프라

마지막으로 인프라 쪽 이야기를 끝을 맺으려 한다.
프로젝트 초기에는 사내 서버로 띄운 깃랩을 사용했지만 인텔리 제이와 호환성이나 gitlab cicd는 자료 찾기가 힘들었다

반대로 github는 인텔리 제이랑 호환성도 좋고 action 자료도 많고 사용성이 편해
GitHub로 전환하고 Action를 통해 서버 자동 배포부터 Flutter 안드로이드 빌드 후
FireBase Distribution 업로드까지 자동화했다.
IOS는 mac-os가 필요해 처음 Action 설정을 mac os로 설정하니 빌링 정책에 따라 빌드 시간 * 10으로 계산이 되어 맥북에 selt hosted를 통해 자동화했다.

서버는 aws ec2 프리티어로 했는데 aws의 다른 기능을 해당 프로젝트에 적용해 보고 싶어
해당 ec2는 살려 두기로 했다.


위 프로젝트를 진행하면서 저와 동료가 회사 기술 블로그에 포스팅한 것들입니다.
Spring for GraphQL
Spring for GraphQL에서 GraphQL Interceptor 그리고 Map
Spring for GraphQL Custom Exception - 22.09.25
JPA로 RDB JSON 타입 다루기
Flutter GetX 상태관리
Flutter에서 GraphQL 사용하기
Fastlane을 이용한 앱 자동 배포
Github Actions에 Self-hosted Runner 등록하기
iOS/Android 프로젝트에 Flutter Module 적용하는 방법

profile
ESTJ 개발자 백엔드와 인프라에 집중하고 있습니다.

0개의 댓글