1주일 회고(2/11~2/17)
1주일 회고(2019-02-11~2019-02-17)
- 코드 공통화
- 서류작업
코드 공통화
이번주에 내가 작업한 기능은 결재알림 발송시 해당 문서에 접근할 수 있는 링크를 제공하는 기능이였다. 유저와 해당 문서의 고유한 id를 가지고 토큰을 발급해서 메일에 a tag로 붙혀주면 되는 간단한 기능이였다. 사실 핵심기능을 만드는데 반나절도 안걸렸다. 이제 이 코드를 메일 발송 부분에 넣어주면 되는데.. 이 메일 발송 코드가 총 8곳이 존재했다. 프론트엔드에 6곳 + 백엔드 2곳
하하..
나에게 선택지가 주어졌다.
- 그냥 8곳 다 찾아서 링크 생성해주는 함수를 호출하는 코드를 8번 넣는다.
- 코드를 공통화 시킨다.
1번 방법은.. 프론트쪽에 접근 토큰 생성함수를 만들고 백엔드에도 또 만든다. 그리고 해당 함수를 호출하는 코드를 작성하면 끝이다. 단 15분이면 끝나는 일이다. 물론 개발자의 양심은(…)
2번 방법은 발송 코드를 전부 공통함수로 묶어서 코드를 공통화 한다. 결코 쉽게 끝날것같지 않는 방법이다.
잠시 고민끝에 2번 방법을 택했다. 1번은 쉬운 길이지만 유지보수의 관점으로 보았을때 나중에 덜 고생하는게 2번 방법이였기 때문이다. 하지만..이게 장장 3일을 잡아먹을지 누가 알았을까..
메일을 발송할때는 여러가지 사유가 존재하지만 크게 보면 아래와 같다.
- 일반 결재 알림
- 결재 완료
- 북마크한 문서의 결재가 변경됨
- 해당 문서와 연계된 도면의 존재유무
발송해야하는 경우마다 발송함수를 따로 만들어서 따로 날리는 코드를 각자 따로 만들었더니 변수명도 제각각이고 누구는 함수화를 시켰는데 누군가 그걸 복봍해서 커스텀하고.. 후…
결국 하나 하나 다 따라가서 공통화시킬 수 있는부분은 최대한 공통화 시켜 프론트쪽은 한군데로 공통화 시킬 수 있었다. 백엔드 쪽은 도저히 손댈 엄두조차 나지 않아 어쩔 수 없이 그대로 둘 수 밖에 없었다. 만약 백엔드쪽에 한번 더 메일 발송 함수를 따로 만든다면 그때는 내가 작업하는 수 밖에.
서류 작업
세상에서 가장 싫은 일중 구지 하나를 꼽으라면 서류 작성이다. 무튼 이번 2차용역 기능정의서를 내가 작성하게 되었다. 1차 용역에는 팀장님이 작성했기 때문에 아무 걱정없었지만 어쩌다보니 2년차 개발자인 내가 하게 된것이다.
크게 할말이 떠오르지 않는다. 싫어도 해야하는일은 해야하는법.
Leave a comment