🔗 토이프로젝트II

토이프로젝트II는 5주였던 토이프로젝트I보다 진행 기간이 단축되어 3주동안 기획과 개발을 하였고 리팩토링 기간은 1주로 진행되었다.

토이프로젝트II의 주제는 "직원들을 위한 급여관리 플랫폼"이였다. 우리 팀은 4인으로 구성되었으며 프로젝트 주제에 맞게 "자영업자 사장님들을 위한 직원 급여관리 플랫폼"을 기획하게 되었다.

사내 인트라넷을 주제로 했던 토이프로젝트I과 비슷한 주제이긴하지만 토이프로젝트I은 바닐라JS로만 개발했다면 토이프로젝트II는 React와 Redux, TypeScript, Firebase를 사용하여 개발하는 것이었다.

우리 팀은 자영업자 사장님들을 위한 직원급여관리 플랫폼으로 사장님은 우리팀과 계약할 시 계정이 부여된다고 가정하였으며 사장님이 직원을 등록하면 직원들은 플랫폼 이용이 가능하다. 사장님과 직원들은 스케줄러를 이용하여 스케줄관리를 하고 매달 급여명세서를 확인할 수 있으며, 직원들은 플랫폼을 이용하여 급여 정정을 요청할 수 있고 사장님은 요청 내역을 기반으로 직원들의 급여를 수정하고 확인할 수 있다.

사장님 페이지는 일정관리, 직원리스트, 직원급여내역 페이지로 구성되고 직원페이지는 일정관리, 급여내역 페이지로 구성된다.

🔗 담당 역할

내가 담당한 역할은 초기 기획단계에서 피그마를 사용하여 와이어프레임을 제작하고 개발단계부터는 Firebase의 Firestore를 사용하기위해 API연결을 구축하였고 급여내역 페이지를 담당하였으며 Firebase hosting을 이용하여 배포를 하였다.

결과물

와이어프레임

회의를 바탕으로 처음으로 피그마를 사용하여 와이어프레임을 제작해보았다. 각 컴포넌트의 구역과 위치, 기능 등을 위주로 작업했다.

사장님의 급여내역 페이지

직원들의 이름은 팀원들의 실명이라 가렸다.(ㅋㅋ)

각 직원의 급여 내역을 열람하면 아래와 같이 급여명세서를 띄우는 모달이 생기며 사장님은 해당 모달을 통해 정확한 실지급액을 확인하여 급여를 지급할 수 있고 직원들의 추가수당을 수정하여 수정된 급여내역을 기록할 수 있다.

직원들이 정정요청하면 사장님은 요청에 대한 승인과 반려를 할 수 있으며 결과를 기반으로 급여 내역을 수정하여 기록할 수 있다.

직원의 급여내역 페이지

직원들은 자신의 급여 명세서를 매달 확인할 수 있으며 잘못 지급된 급여에 대해 사장님께 급여 정정을 요청할 수 있고 자신이 요청한 내역의 상태를 확인 할 수 있다.

🔗 리팩토링

멘토링 & 코드리뷰

github 팀 레파지토리에 코드리뷰 PR을 생성하면 멘토님께서 아래처럼 각 코드에 대해 간략하게 리뷰를 달아주셨고 멘토링 시간 때 개선사항에 대해 자세하게 설명해주셨다.

1. 클린코드

위의 사진처럼 변수명도 명확하지 않았고 각 pay 데이터를 똑같은 처리로 반복하고있어 코드 양도 많아지고 가독성도 떨어져보였으나 멘토님의 리뷰를 반영하여 아래와 같이 수정하였다. 코드 길이 뿐만아니라 가독성도 훨씬 좋아졌다.

2. Firebase API 비동기 코드, 쿼리 사용하기

Firebase CRUD 블로그 에서는 각각의 코드가 중첩된 for문을 사용하여 가독성도 떨어지고 속도도 느렸으나 빠른 처리 속도와 가독성을 위해 쿼리와 map메서드를 사용하여 더 효율적으로 수정하였다.

// deleteSalaryCorrection.ts
import { collection, deleteDoc, doc, getDocs, query, where } from 'firebase/firestore';
import { db } from './Firebase_Config.ts';

const deleteSalaryCorrectionAPI = async (name: string, month: number, correctionDetails: string) => {
  try {
    const membersSnapshot = await getDocs(collection(db, 'members'));
    const deletePromises = membersSnapshot.docs.map(async (memberDoc) => {
      const q = query(
        collection(db, 'members', memberDoc.id, 'payrollCorApp'),
        where('name', '==', name),
        where('month', '==', month),
        where('correctionDetails', '==', correctionDetails),
      );
      const querySnapshot = await getDocs(q);
      return querySnapshot.docs.map(async (docSnapshot) => {
        deleteDoc(doc(db, 'members', memberDoc.id, 'payrollCorApp', docSnapshot.id));
      });
    });
    await Promise.all(deletePromises);
  } catch (error) {
    console.error('Error deleting salary correction:', error);
  }
};

export default deleteSalaryCorrectionAPI;

// updatePayrollCorApp.ts
import { collection, doc, setDoc, getDocs, query, where } from 'firebase/firestore';
import { db } from './Firebase_Config.ts';

const updateCorrectionState = async (name: string, month: number, state: string, correctionDetails: string) => {
  try {
    const membersSnapshot = await getDocs(collection(db, 'members'));
    const payrollCorAppUpdatePromise = membersSnapshot.docs.map(async (memberDoc) => {
      const q = query(
        collection(db, 'members', memberDoc.id, 'payrollCorApp'),
        where('name', '==', name),
        where('month', '==', month),
        where('correctionDetails', '==', correctionDetails),
      );
      const querySnapshot = await getDocs(q);
      return querySnapshot.docs.map(async (docSnapshot) => {
        setDoc(doc(db, 'members', memberDoc.id, 'payrollCorApp', docSnapshot.id), {
          ...docSnapshot.data(),
          correctionState: state,
        });
      });
    });
    await Promise.all(payrollCorAppUpdatePromise);
  } catch (error) {
    console.error('Error updating correction state:', error);
  }
};

export default updateCorrectionState;

🔗 토이프로젝트II를 마치며

발표회 당시 민태강사님께서는 안정적으로 개발된 프로젝트인 것 같다는 인상을 받았다고 하시면서 기능과 UI의 적절한 배치도 그렇고 코드상에서 익숙하지 않은 TypeScript가 보였음에도 불구하고 많은 양의 데이터와 코드들을 Type 지정하려고 노력한 부분이 많이 보여 고생했다고 하셨다. 추가로 버튼 스타일의 일관성, 규칙성의 중요성과 각 기능들의 무거운 과업, 가벼운 과업에 대해 고민하고 생각해볼 필요가 있다고 언급해주셨다. 예를 들어 사장님이 월급날을 수정하여 적용하는 기능이 있었으나 어떠한 알림이나 확인없이 바로 적용되는 부분이 아쉬웠다고 하셨다. 무거운 과업인 기능이 가볍게 기획되었을 때 프론트엔드 개발자도 기획자나 디자이너에게 건의를 할 수 있어야하고 기능면에서 중요도에 따라 적절한 Validation이 필요하다는 것도 다시 한 번 깨닫게 되었다.

💡 좋았던 점

1. ESlint설정, Prettier설정, 커밋컨벤션, 스타일 컨벤션, 폴더구조 등 탄탄한 초기 설계
2. React를 사용한 컴포넌트 개발 및 Hooks를 사용한 상태관리
3. Redux를 사용한 동기, 비동기 전역 상태관리
4. Firebase를 이용하여 서버 구축
5. Firebase hosting을 이용한 배포
6. TypeScript를 이용하여 Type지정을 통해 에러와 버그 개선

💡 아쉬운 점

1. 짧은 3주동안 Redux와 TypeScript, Firebase를 공부하고 프로젝트에 적용하였으나 추가적인 공부가 필요하다고 느꼈다.
2. 익숙하지 않았던 커밋 컨벤션으로 초기에 컨벤션을 완벽히 지키지 못하였다.
3. 토이프로젝트I 리팩토링때도 있었던 변수명, 함수명에 대한 규칙은 잘 지켜졌으나 적절한 이름을 사용하지 못하고 놓친 점이 아쉬웠다.

💡 배운 점

1. 프로젝트 초기 설정에 있어서 팀원 한 분이 한번에 해주셨는데 결과물을 보고 각 환경설정에 대해 배울 수 있었다.
2. 피그마를 처음 사용해봐서 미숙한 점이 있었으나 피그마를 다뤄보셨던 팀원이 있어서 궁금한 것이나 모르는게 있을 때 물어보고 배울 수 있었다.