실제 운영중인 서비스를 보면 왜 이렇게 만들어놨지? 하며 한숨쉴 때가 있습니다. 그리고 그 서비스를 이어받아 기능을 추가해야할 때 기존 방식에 맞춰야할지? 아니면 수습하면서 진행해야할지? 당연히 수습해야한다! 확장성, 유지보수성, 가독성 등을 고려했을 때 무조건 수정해야한다! 하지만 시간이 없는데? 정해진 시간내에 못하면 어떡하지? 새로운 트러블을 만드는 건데 어떡하지?
제가 내린 답은 의외로 간단합니다!
책임질 수 있다면 수습하시면 됩니다. 말은 쉽지만 실행하기엔 어려운 선택입니다.
저의 경험으로 예를 들어보겠습니다.
이번에 신규 서비스를 만들면서 배치를 만들어야했습니다. 배치를 만들 당시 "이건 Spring Batch로 만들어야해!!" 했으나 Spring Batch를 할 줄 몰라서 @Scheduler로 구현이 되었습니다. 진작 공부좀 할껄.. 나중에 후회할텐데.. ㅠㅠ
시간이 지나서 서비스가 오픈하고 시간적 여유가 조금 생길 시기가 있었습니다. '이 때다! 지금 아니면 Spring Batch 적용 못한다' 라고 생각했습니다. 그래서 Spring Batch를 파고 또 파고 결과적으론 변경하자! 라고 컨펌을 받았습니다.
서비스 크기는 그렇게 크지 않았습니다. 실행해야할 타스크는 총 3개! 안정화된 소스도 있고 개수도 적으니 만들고 테스트까지 1주일이면 되겠구나! 하고 Spring Batch 작업을 시작하였습니다. 결론부터 적자면 3주 조금 안걸렸습니다. 여러가지 이유가 있었습니다.
- 관련 기술 학습
- 각 타스크는 갓 메서드로 구성되있어서 객체지향적으로 바꾸자!
- Mybatis를 걷어내고 Querydsl-JPA를 도입하자!
- 왜 outer join 이 안돼! ( Q클래스 잘못 사용 )
- Scheduler 걷어내고 Spring Batch 쓰자
- Jenkins로 Schedule돌리자
- 난 8시에 돌렸는데 왜 17시에 돌지? ( 젠킨스 서버 시간 세팅 문제 )
- 하드코딩 걷어내자!
- 소스를 옮기는 도중 누락 발생
- 여기에 이런 코드가 있었어!?
처음부터 이렇게 거창하게 할 생각은 없었으나 이왕하는거 제대로 해보자! 하다보니 계속 시간이 늘어갔습니다. ( 아직 주니어 개발자이구나.. ) 그리고 신기술에 따른 충분한 테스트 없이 바로 도입하여 그에 따른 문제로 또 시간이 늘어졌습니다. 다행히 운이 좋게 다음 프로젝트 들어가기전에 마무리하였지만, 만약 시간적 여유가 없었다면 일만 벌려놓고 또 다음 개발자가 보면 욕나올 상황이 벌어질뻔 했습니다.
개발은 항상 예기치 않는 문제를 항상 생각해야한다고 생각합니다. 모든 걸 고려하여 나는 끝까지 책임질 수 있을까? 생각하시고 잘 모르시겠다면 경험치가 많이 쌓이신 분들께 도움을 요청하는 방법도 좋은 방법인 것 같습니다! 갈아엎어서 성공한다면 능력있는 개발자가 되고, 실패한다면 그 반대가 될 것입니다.
전 주어진 시간내에 성공하지 못했습니다. 하지만 동료들의 커버가 있어서 마무리 지을 수 있었습니다.
결론. 좋은 동료다! :)
p.s
미리미리 공부하고 학습해놓자!! 처음부터 적용했다면 이런일 없었을텐데!!
코드 리팩토링하면서 많은 걸 배울 수 있어서 좋은 기회였습니다. 이번엔 정말 운이 좋았...
'MindControl' 카테고리의 다른 글
| 불편해하자. 불평하자. 불만을 갖자. (2) | 2021.03.08 |
|---|---|
| [Jetbrain 강의] 온/오프라인에서 활동하는 인플루언서의 이야기 (백기선님, 이동욱님, 박상권님, 백승주님) (0) | 2020.12.09 |
| 이런 개발자가 될 것이다. 남들 때문에 스트레스 받지 말자!! (0) | 2020.11.23 |
| 조회수 100을 넘기며 (0) | 2020.11.20 |
| 티스토리 시작하자! (0) | 2020.11.03 |