첫 프로젝트 : 지원선발 어드민

회사 자산이라 이미지 첨부는 안함.

 

지원선발 어드민을 만들었고, 6/7부터 실제 상용화되고 있다. 

 

정말 떨렸는데, 아직까지는 큰 문제 없이 잠잠해서 다행이다.

 

지원선발 어드민은 우리 회사 부트캠프에 지원한 사람들이 탑승하기 까지의 선발 과정을 관리하는 관리자 페이지이다.

 

내가 인턴일때 기획이 시작되어서 6/3 첫 라이브 배포를 하였다.

 

반성

1. 내가 작업한 부분 말고는 남들에게 설명할 수 없음(알림톡,surveyjs), 코드리뷰를 대충한 결과라고 생각함.

2. 시간추산 오차가 너무 컸다. 예를 들면 1.5시간 잡은 작업이 하루 종일 걸렸음

3. 레거시를 만드는 코드 작업. '일단 만들고 나중에 리팩토링 하지' 라는 자세는 매우 안좋은 자세라고 한다. 레거시를 만들기 때문이다. 하지만 어쩔수없었다. 시간추산을 잘못 했기에, 시간이 없었다.

4. 자신의 작업에만 몰두하여 코드리뷰를 대충했다.

 

잘한것

1. graphQL에 빨리 적응하였다.

2. 팀원들과 활발하게 소통하면서 작업했다.

3. 특히, 백엔드 영역에서 문제가 생긴것은 혼자 해결하려 하지 않고, 바로바로 물어봤는데 아주 잘한일 같다.

면접볼때, 내가 물어봤던 질문은 '모르는게 있으면 혼자 고민하는게 맞는지, 그냥 물어보는게 맞는지?' 였는데 그때 면접관님의 대답은 '내선에서 해결하려 하지 말고 그냥 빨리 물어봐라, 나의 숙제가 아닌 우리 모두의 숙제 이기 때문' 이었다. 바로바로 물어봤기 때문에 우리의 숙제를 빠르게 해결할 수 있었던것 같다.

 

어려웠던 것

1. Table 컴포넌트

처음에는 AgeGrid를 사용하여 Table을 작성하려 했다.

먼저 비슷한 어드민작업을 한 동료가 있어서 이것저것 물어봤는데, AgeGrid는 커스텀에 한계가 있어서 table태그로 한땀한땀 만들었다고 했다. 

나도 table태그로 한땀한땀(그 동료의 코드를 복붙하며) 테이블을 만들었다.

 

문제는 그 테이블이 모든페이지에서 적용될 수 있는 공통컴포넌트여야 한다는 것이었다.

 

어떤 상황에서도 사용될 수 있도록 모든 경우의 수를 상상하며 Table을 만드는것이 큰 어려움이었다.

 

고민하다가, 일단은 당장 사용할 수 있게 Table을 만들고, 동료들에게 이야기해서 모든 Table은 내가 만들겠다고 했다.

 

내가 만들어야 공통화 할 수 있을것 같았기 때문이다.

 

결론은 공통화를 성공했다.

 

기존 다른 어드민에서 사용하던 table을 바이블로 생각한것이 큰 딜레마였던것 같다. 삭제할꺼 삭제하고 새롭게 필요한 것들을 붙혔다.

 

한참을 까보며 사이드이펙트를 없앨 수 있었고, 외부에서 받는 props에만 영향을 받도록 만들었다.

 

 

2. 필터링

 

사실 이건 아직도 해결을 못한채 임시방편으로 막아둔 상태이다.

 

필터링쿼리를 날리면 계속 전체 데이터를 받아오는 쿼리가 재실행되는 버그이다.

 

refetch가 적용되는 것은 아닌데, 아무리 찾아봐도 원인을 알 수 없었다.

 

또 3~4번 필터링을 하면 다시 정상작동한다. 하지만 새로고침하면 다시 필터링할때마다 전체 데이터를 다시 받아오게 된다.

 

결국 다음과 같이 state를 하나 만들어서 전체 데이터를 받아오는 쿼리를 막았다.

 

  useEffect(() => {
    if (!searchApplicationListData) return;

    const { nodes, totalCount } = searchApplicationListData.applicationList;
    setTotal(totalCount);
    //필터링을 하면 isAfterFiltering이 true가 된다.
    if (isAfterFiltering === false) setApplicationList(nodes);
  }, [searchApplicationListData]);

하지만 이건 근본적인 문제를 찾아서 해결한 것이 아니라, 그냥 문제를 덮어둔 것이라서 그리 맘에 들진 않는 방법이다.

 

 

좋았던 것

데일리 스탠드업

매일 daily standup 미팅을 하며 전날 작업한 것을 공유하고 회고를 했는데 큰 도움이 되었던 것 같다.

서로가 어떤 작업을 하는지 알 수 있었고, '아 나만 힘든게 아니구나, 저 사람도 엄청 빡세게 하고 있구나' 라는 것을 느끼며 동기부여를 받을 수 있었다. 그리고 서로 작업범위가 겹치는 것을 방지할 수 있었다.

 

소통잘했다

소통이 꽤 잘 이루어졌던것 같다.

적어도 소통오류로 스트레스 받는 일은 없었다.

 

다음에는..?

코드리뷰 꼼꼼히!

일정추산에는 코드리뷰가 포함되어야 한단 것을 머리로만 알고 실제로는 작업시간만 생각했다.

왜 일정추산에 코드리뷰가 포함되어야 하는지 알겠다. 내가 코드리뷰를 받는 시간뿐만 아니라, 내가 코드리뷰를 하는 시간도 포함되어야 한다는 것을 알았다.

 

레거시만드는 코드 지양하기

일단 작동하는 코드를 만들고 나중에 고치기로 했다. 사실 이러면 안된단걸 알고 있었지만 눈에 밟히는 레거시들을 그대로 두고 기능구현에 급급했다. 

레거시는 잠재적 버그이고, 후에 리팩토링시간을 또 필요로 한다. 

 

레거시를 만드는 코드를 지양하는 첫번째는 일정추산을 올바르게 하는 것이다.

 

 

=> 일정추산 똑바로

적고나니까 결국 위 두개는 일정추산으로 귀결되는 것 같다.

 

---

교육생때 작성했던 회고처럼 퀄리티있는 회고를 작성하려 했는데, 이미지를 첨부하지 않고 글만 작성하니 그냥 일기장이 되어버렸다.