Skip to content

20 05 회고

Jump to bottom
Yongku cho edited this page May 31, 2020 · 16 revisions

커뮤니케이션

안부물으면 나도 묻자

논리 커뮤니케이션이 아닌 표면 커뮤니케이션 일때 질문을 받으면 나도 물아보자. 질문을 받고 대답만하면 챗봇이지 사람이냐.

질문도 시작맨트가 필요

대뜸 질문하는 것 보다는 어떤것에 대한 질문인지 상대방에게 전달하자. 생각에 범위를 좁힐 수 있다.

그리고 상대방의 시간을 쓴것과 상대방이 시간을 할애해줬음에 항상 감사해야함을 잊어서는 안된다.

내 스스로의 좁은 시각

내 스스로가 생각하는 시기적절한 행동과 옳음의 판단이 좁은 시각에서 비롯될 수 있다. 이런 부분은 인생 선배들은 이미 판단이 섰을 수 있다.

내가 옳았음을 찾기 보다는 내가 어떤 부분을 틀리게 또는 다르게 생각했는지 여유있게 찾아보자. 그럼 좁은 시각이었음을 알 수 있을 것이다.

일정산정 빠르게 진행됨

AS IS는 3명이 스토리별로 하나씩 논의. TO BE는 2명이 스토리별로 MD 산정, 그리고 2명이 MD 논의 후 조정. 마지막으로 1명이 검토.

이렇게 진행하니 빠르게 완료됨.

출발지/목적지는 같은 데, 항로가 다르다.

다른 파트 협업자들과 커뮤니케이션이 잘되나 같은 파트이고 바로 옆에서 일하는 동료와 커뮤니케이션이 안되는 케이스가 있다. 출발지와 목적지 그리고 서비스가 잘됬으면 하는 마음은 같다.

하지만 업무를 처리함에 있어 각자 다른 세계에 경험이 있기 때문에 100에서 80은 다른 의견이 존재한다. 이럴때 일 수록 대대적인 개선이 필요할듯하다.

일정산정

Feature

Feature List 작성은 작성하는 사람의 업무를 분할하는 방법에 영향이 있다. 그래서 본인이 아닌 다른 사람이 해당 Feature를 봤을 때 다르게 해석할 여지가 있다.

사례

이 세가지 Feature에 다른 시각이 있었다.

- 마크업 적용
  - 마크업만 복붙한다.
  - 마크업 + 데이터 바인딩을 한다.
  - 마크업 + 컴포넌트화를 한다.
- API 연동
  - API 요청/응답 선언부를 작성한다.
  - API 요청/응답 선언부 + 데이터 바인딩을 한다.

Estimation

  • 공통 Feature를 분리하는 작업에 따라 다르다.
  • 공통으로 묶을 수 있다라고 생각하는 개발자에 따라 MD가 다르게 생각한다.
  • 해결방법: 대전재가 필요하다.
    1. 공통 Feature 분리를 가정하고 산정한다.
    2. 공통 Feature 분리를 가정하기 않고 산정한다.

개발

현재 URL이 특정 값과 일치할 때 처리 방법

  1. 함수로 구현. 필요할 때 호출.
  2. 라우팅 변경 시 한번만 세팅. 필요할 때 저장된 상태 사용.

이 부분도 서베이시 모두 2번을 선택했다. 확실히 함수형 사고에 고정된듯하다. 패러다임에 맞는 코딩을 하는 것을 추구하지만 스스로가 그렇지 못한 거 같다.

에러 처리 방법

지인들과 파트원들에게 async await 에러 핸들링 방법에 대한 선호도를 서베이했다. try..catch와 then catch 선택지 두가지가 있었다. 전원 try..catch를 선택했다.

나는 계속 then catch를 선호했다. 곰곰히 생각해보니 함수형에 너무 빠져있는 듯해서 고집하고 있었다.

IDE Refactor 안되는 현상

/store/myModule/actions.ts
const actions = {
  fetchData (arg) { return Promise.resolve(arg); },
};
export default actions;
/store/myModule/index.ts
import actions from '~/store/myModule/actions';
export default {actions};
/store/plugin.ts
import myModule from '~/store/myModule';

interface ModuleActions {
  myModule: keyof typeof myModule.actions;
}

type ActionHandle<Keys extends string> = {
  [key in Keys]: (payload?: any) => Promise<any>
}

const actionMap = new Map<keyof ModuleActions, string[]>([
  ['myModule', Object.keys(myModule.actions)],
]);

export const useStoreAction = () => {
  function mapStoreAction<T extends keyof ModuleActions> (
    moduleName: T
  ): ActionHandle<ModuleActions[T]> {
    const keys = actionMap.get(moduleName) || [];
    return Object.assign(
      {},
      ...keys.map(action => ({
        [action]: () => Promise.resolve(`${moduleName}/${action}`),
      }))
    );
  }
  return {mapStoreAction};
};

const myModuleAction = useStoreAction().mapStoreAction('myModule');
myModuleAction.fetchData();

actions.ts의 함수를 IDE의 Refactor 기능을 사용하면 사용측에 정상적으로 반영 안된다. 하지만 plugin.ts에서 action.ts를 index.ts를 통하지 않고 바로 읽으면 IDE의 Refactor 기능이 동작한다.

Clone this wiki locally