현업에서 느낀 유지보수 업무의 문제점과 개선 방안. 운영중인 서버에서 사용자가 발견한 이슈가 가장 큰 우선순위를 가진다. 이런 경우는 있어서도 안되지만 운영팀에 넘어와서 정말 많이 봤다. 1년 전 CDW 운영팀으로 넘어와서 처음 넘겨받은 레거시 소스가 운영기임에도 불구하고 문서화된 설계가 많이 부족한 POC적 성격이 강한 소스코드였고, QA관리가 제대로 되지않아 기획서에 정의된 기능이 제대로 작동하는 경우가 거의 없었다. 대게 가능한 10가지 경우의 수 중 자주 사용할만한 2가지 경우의 수에서만 작동하는 식이었다. 이렇듯 레거시 소스가 기획서에서 찾아볼 수 있는 일반화된 입력에 대해 수행 불가한 경우가 많아서 이슈를 처리하기 위해 Confluence위키나 주석을 찾아보면, 정리된 내용이 소스코드에 구현된 내용과 다른 경우가 허다했다. 따라서, 유지보수라는 명목하에 사실상 구현이 미비한 기능의 신규 개발을 수행한 적이 많았으며, 레거시 소스의 문서화 미비로 공수 산정은 어려웠으며 실제 공수는 항상 예상 공수보다 길어져만갔다. 위와 같은 문제가 발생하게된 주요 원인을 나는 3가지 정도로 정리한다. 소스코드 문서화 미비 (ex, 입 출력 범위가 명확하지 않은 API 명세서, 컴포넌트 명세서 혹은 관련 표준안의 부재) 버전관리 역량의 부족 이 부분은 또 세부 적으로 나눠서 설명할 필요가 있다. 첫 째로, 커밋을 한 이후에 자신이 인입/수정하고 싶은 라인이 제대로 반영되었는지 확인을 해야하는데 확인들을 잘 안하고 push한다. 대게 머지 커밋시에는 확인을 안하는 문제가 있었으며, 문제 제기를 해도 머지시 브렌치에 인입/수정 됐던 라인들이 conflict가 안나도 반영이 안될 수 있다는 인식이 부재한 캐이스 였다. 두번째로, 커밋된 내용 확인을 하더라도 공백 제외 옵션을 켜놓고 보는 경우를 많이 봤다. 특히 IntelliJ를 사용하는 개발자들이 주로 그랬는데, 이는 공백만 변경한 의도치 않은 라인들이 커밋에 섞여들어가 타인의 커밋내용과 불필요한 confl...