팀프로젝트 회고

최환석·2023년 5월 19일
1

서론

이 포스트는 제가 프로젝트를 진행하면서 겪었던 어려움과 또 얻었던 인사이트를 공유하는 포스트입니다.

처음으로 우리들이 모였던 날은 4월26일 수요일에 모여서 처음으로 회의를 하게 되었다. 원래 처음 프로젝트 주제로 받은 주제는 연차 당직 관련 사이트였다. 하지만 이 패턴 즉 일반유저와 권환있는 유저를 기반으로 CRUD 를 구현하는 것을 연차,당직 프로그램으로는 쓰기 너무 아쉬운 주제라고 생각이 되어서 다른 주제를 삼기로 했고 우리는 바로 회의를 진행하였고, 그 다음에 나온 의견이 칸반보드를 기반으로 한 프로젝트를 관리하는 사이트 였다.

우리는 바로 프로젝트를 관리를 하는 github에 영감을 받아서 제작을 해당하는 아이디어에 영감을 받아서 바로 프로젝트를 진행하였다.

본론

우리가 제일 먼저 생각했던 것

우리가 제일 먼저 중요하게 생각했던 것은 바로 소통이다. 프론트엔드 개발자들은 필연적으로 다른 팀들과 소통을 해야하는 경우가 있다. 백엔드 팀들과 UI/UX 팀들과 또 PM들과 소통을 항상 하며 자신의 개발을 공유하며 또 결과물을 내야한다. 또 프론트엔드 맨들은 특히 백엔드와 제일 밀접하게 연관이 있기 때문에 항상 소통을 해야한다.

그렇기 때문에 우리는 디스코드를 사용하여 5분대기조를 만들었다.

프로젝트 기간동안 항상 통화방에 있어서 무슨일이 생기면 바로 보고 하며 또 물어볼 것 이 있다면 바로 물어보는 식으로 프로젝트를 진행해나갔다. 덕분에 우리는 적어도 프로젝트 기간동안 소통 부족으로 인한 코드 꼬임은 방지 할 수 있었다.

그리고 매일 13시, 21시에 정기스크럼을 가지면서 자신의 진행사항을 언제든지 팀원들과 공유하여 또 에러가 발생하면 그 자리에서 즉시 도움을 받을 수 있었다.

우리가 정한 주요기능

  • 일정 관리(등록, 수정, 삭제)
  • 일정 상세 관리
  • 전체 일정 월별 조회(Calendar)보기
  • 일정 조회(Overview)
  • 나와 관련된 일정 조회(Kanban)
  • 관리자 권한
  • 일정 통계 조회(DashBoad)

이렇게 크게 나누었고 또 이 것을 위주로 개발을 하기로 결정하고 그 다음은 api문서를 짰다. 또 api문서를 짤때도 마찬가지로 같이 의논하면서 여기는 어떤 것이 와야하는지 또 응답으로는 뭐가 와야하는 지 정하면서 미리 픽스하여 개발에서 잦은 변경을 없도록 하였다. 만약에 필연적으로 수정을 해야하는 상황이라면, 바로 백엔드와 소통을 하여 정중하게 부탁을 드려서 코드를 고칠 수 있었다.

그 다음은 일사천리로 일이 진행되었다. 미리 구매한 피그마 시안을 우리 프로젝트에 맞춰서 수정을 진행하고, 개발을 진행했다.

개발과정

개발을 진행하면서 우리는 Next.js 프레임 워크를 사용하여 개발을 진행하기로 결정했다. 그냥 React보다 Next.js 를 사용하기로 결정한 이유는 다음과 같다.

  • SSR을 활용을 해야하는 페이지 존재
  • Next.js의 pages 폴더 라우팅을 연습하고 싶었음.
  • 후에 혹시 모르는 vercel 배포시 연동성이 아주 강력함.

크게 위의 세가지 이유로 Next.js를 사용하게 되었고, 또 상태관리 라이브러리는 Zustand를 사용하기로 했다. Zustand에 대한 포스팅은 다음 포스팅에서 작성하겠다.

아무튼 우리는 조금더 기능을 개발하는데 집중하고 싶어서 https://chakra-ui.com/getting-started 를 사용하기로 했다.

그리고 이 프레임워크를 사요하면서 css 프레임워크에 대한 인식이 조금 바뀌었다.

겪은 문제들

하지만 순탄하기만 하면 당연히 아니였다. 일단 나는 칸반 보드 제작과 모달창을 제작하기로 했다.

DnD 라이브러리 유지보수 중단

라이브러리를 사용할때는 신중히...

칸반보드를 제작하기 위해서는 dnd 기능을 구현을 해야했는데, 문제는 dnd를 구현하기 위해서 사용된 react beautiful dnd 라이브러리를 사용해야 하는데 해당 라이브러리는 유지보수가 중단이 된 라이브러리이다. 그렇기 때문에 최신 react에서는 제대로 작동하지 않았고 또 next.js 에서도 문제가 발생했다.

하지만 구글링을 하면서 정보를 얻게 되었고 먼저 최신 react에서 대응되는 문제는 react-strict 모드를 false로 설정을 하면되고 그 다음에 next.js에서만 문제가 발생하게 되었다.

그 이유는 next의 ssr과 관련된 에러였고 이를 해결하기 위해서는 _document.tsx 파일을 아래와 같이 수정하면 해결된다.

export default class MyDocument extends Document<Props> {
  static async getInitialProps(ctx: DocumentContext) {
    const initialProps = await super.getInitialProps(ctx);
    resetServerContext();
    return { ...initialProps };
  }

  render() {
    return (
      <Html lang="en">
        <Head />
        <body className="bg-gray-100">
          <Main />
          <NextScript />
        </body>
      </Html>
    );
  }
}

types...

그리고 이번에는 코딩을 하면서 조금더 타입스크립트를 제대로 응용하고 싶었고 그것을 위해서 enum과 constants 개념을 사용하여 기능을 개발하였는데 여기서 문제가 발생하였다. 확장성있게 설계를 하기 위해서 작성된 코드가 오히려 폐쇄적으로 코드를 막아버렸었다...

import { Assignee } from '@/apis/kanban';
import { IAssignee } from '@/components/CommonAvatar/CommonAvatar';

export enum StatusType {
  TODO = 'TODO',
  IN_PROGRESS = 'IN_PROGRESS',
  DONE = 'DONE',
}

export enum PriorityType {
  URGENT = 'URGENT',
  HIGH = 'HIGH',
  MEDIUM = 'MEDIUM',
  LOW = 'LOW',
}

export enum TeamType {
  DEVELOPMENT = 'DEVELOPMENT',
  HR = 'HR',
  MANAGEMENT = 'MANAGEMENT',
  TRADE = 'TRADE',
  SALES = 'SALES',
  SERVICE = 'SERVICE',
  PRODUCTION = 'PRODUCTION',
  EDUCATION = 'EDUCATION',
  MARKETING = 'MARKETING',
  OTHERS = 'OTHERS',
}

export type actionConstantsType = {
  START_AT?: {
    key: string;
    value?: Date;
  };
  END_AT: {
    key: string;
    value?: Date;
  };
  ASSIGNEE: {
    key: string;
    value?: IAssignee[];
  };
  SET_STATUS: {
    key: string;
    value?: StatusType;
  };
  SET_PRIORITY: {
    key: string;
    value?: PriorityType;
  };
  DELETE_TASK?: {
    key: string;
    value?: string;
  };
  EDIT_TASK?: {
    key: string;
    value?: string;
  };
};

export type actionType = keyof actionConstantsType;

위와 같이 해당된 코드를 정하고 또 해당하는 키워드를 무조건 사용하도록 고정을 하니 안정성은 보장이되었고 또 자동완성과 코파일럿에 대해서 도움을 상당히 많이 받을 수 있었지만, 위와 같은 로직으로 짜려고 하니 컴포넌트에 대해서 응용을 하기가 정말 까다로웠다. 그렇기 때문에 조금더 확장성을 고려하거나 정교한 설계를 했어야 했었다...

무튼 조금더 생각하면서 코드를 짜야겠다 라는 생각이 들었다.

라이브러리 도입은 심사숙고할것

우리는 charkra ui 프레임워크를 사용하기로 했지만 select ui가 생각보다 못생기게 나와서 이를 확장한 라이브러리를 사용했지만 이는 독으로 작용했다. 제작자가 꼼꼼하게 타입을 작성하지 않았는지 혹은 우리가 제대로 응용하는 부분을 몰랐는지 타입에러가 무수하게 쏟아져 나왔고, 나는 처음으로 라이브러리를 도입하는 것에 대해서 후회를 했다. 차라리 해당하는 버그를 무시하고 짜기 보다는 그냥 내가 커스텀해서 팀원들에게 뿌릴 수 있었더라면 더 좋았을 텐데

   // @ts-ignore
    if (e.key) {
      // @ts-ignore
      const { key, value } = e;
      if (key === 'ASSIGNEE') {
        // @ts-ignore
        const { label, profileImageUrl } = e;
        setTaskStatus((prevState) => ({
          ...prevState,[key]: {
            // @ts-ignore
            ...prevState[key],
            value: [
              // @ts-ignore
              ...prevState[key].value,
              {
                userId: value,
                name: label,
                profileImageUrl,
              },
            ],
          },
        }));
      } else
        setTaskStatus((prevState) => ({
          ...prevState,
          [key]: {
            // @ts-ignore
            ...prevState[key as string],
            value,
          },
        }));
    }

무수한 @ts-ignore ... 다음에는 제대로 알아보고 쓰자...

마무리

무튼 이렇게 내가 잘못했던 이슈를 돌아보면서 나는 아직 ts에 t도 모르는 것 같았다... 조금더 실수하면서 또 실수를 잡아가면서 성장을 해야겠다. 라고 느꼈다... 그리고 이 자리를 빌어서 같이 진행한 팀원에게 말을 하자면... 정말 고생많으셨어요!~!! 프로젝트 진행하면서 정말 재밌었습니다!

profile
최환석
항상 즐겁고 재밌게!
이전 포스트

SPA란 도대체 뭘까

다음 포스트

상태관리 라이브러리 사용후기

0개의 댓글