소프트웨어 유지보수 방법론

현업에서 느낀 유지보수 업무의 문제점과 개선 방안.

운영중인 서버에서 사용자가 발견한 이슈가 가장 큰 우선순위를 가진다. 이런 경우는 있어서도 안되지만 운영팀에 넘어와서 정말 많이 봤다. 1년 전 CDW 운영팀으로 넘어와서 처음 넘겨받은 레거시 소스가 운영기임에도 불구하고 문서화된 설계가 많이 부족한 POC적 성격이 강한 소스코드였고, QA관리가 제대로 되지않아 기획서에 정의된 기능이 제대로 작동하는 경우가 거의 없었다. 대게 가능한 10가지 경우의 수 중 자주 사용할만한 2가지 경우의 수에서만 작동하는 식이었다. 이렇듯 레거시 소스가 기획서에서 찾아볼 수 있는 일반화된 입력에 대해 수행 불가한 경우가 많아서 이슈를 처리하기 위해 Confluence위키나 주석을 찾아보면, 정리된 내용이 소스코드에 구현된 내용과 다른 경우가 허다했다. 따라서, 유지보수라는 명목하에 사실상 구현이 미비한 기능의 신규 개발을 수행한 적이 많았으며, 레거시 소스의 문서화 미비로 공수 산정은 어려웠으며 실제 공수는 항상 예상 공수보다 길어져만갔다.

위와 같은 문제가 발생하게된 주요 원인을 나는 3가지 정도로 정리한다.

1. 소스코드 문서화 미비 (ex, 입 출력 범위가 명확하지 않은 API 명세서, 컴포넌트 명세서 혹은 관련 표준안의 부재)

2. 버전관리 역량의 부족

   이 부분은 또 세부 적으로 나눠서 설명할 필요가 있다. 첫 째로, 커밋을 한 이후에 자신이 인입/수정하고 싶은 라인이 제대로 반영되었는지 확인을 해야하는데 확인들을 잘 안하고 push한다. 대게 머지 커밋시에는 확인을 안하는 문제가 있었으며, 문제 제기를 해도 머지시 브렌치에 인입/수정 됐던 라인들이 conflict가 안나도 반영이 안될 수 있다는 인식이 부재한 캐이스 였다. 두번째로, 커밋된 내용 확인을 하더라도 공백 제외 옵션을 켜놓고 보는 경우를 많이 봤다. 특히 IntelliJ를 사용하는 개발자들이 주로 그랬는데, 이는 공백만 변경한 의도치 않은 라인들이 커밋에 섞여들어가 타인의 커밋내용과 불필요한 conflict를 발생시켜 버전관리에 혼선을 줄 수 있는 중대한 문제이다. blame으로 라인별 히스토리를 추적하는 작업을 가장 어렵게 하는 주적이다. 마지막으로, PR이 없다. 사실상 Pull Request과정이 있으면, 위에서 언급한 문제들을 예방할 수 있는 절차가 한번 생기는건데, 그런 과정없이 바로바로 main에 push를 하고 있었다.

3. 클래스들간의 높은 결합도와 낮은 결집도

   유지보수 작업을 하면서 소스코드를 보면, 이곳저곳 소스코드 중간에 서로 다른 개발자가 관입시킨 라인들이 보인다. 대게 그런 부분에서 오류가 생긴가. 대게 업무할당은 기능별로 나뉘기 마련이다. A라는 사람이 a라는 기능을 개발하면 B라는 사람은 b라는 기능을 개발한다. 그런데, a,b가 같은 클래스 안에 구현된 기능인 경우, 심지어 같은 클래스내 같은 메소드에 수정이 필요한 기능인 경우가 발생하는 경우를 많이 봤다. 이는 각 클래스가 객체지향적 설계를 준수하지 못했고, 서로간의 높은 결합도를 보이기 때문에 발생한는 문제라고 생각했다. 만약에라도 각 클래스간의 기능적인 독립이 뚜렸했다면, 서로다른 기능을 개발하는 개발자가 같은 메소드를 수정하는 일은 없었을 것이다. 이 프로젝트에서 가장 눈에띄던 결합도는, HashMap 파라미터였다. 레거시 소스의 9할은 인터페이스 메소드에서 파리미터 인자로 HashMap울 받아 처리하게끔 구현되어있었다. 심지어, 다중 HashMap으로 말이다. 이러면 메소드의 입력 도메인이 명확하게 정의되지 않을 뿐더러, 입력 도메인이 무한정 커지는 문제가 있다. 이 경우 메소드상단에 JavaDoc 으로 해당 파라미터에 대한 상세 설명이라도 달아놔야하는데, 그런 소스는 본적이 없다. 또한 메소드 내부에서도 별도의 검증 처리를 거치지 않고 사용하고 있었다. 이렇게 된다면, 해당 메소드드는 외부로부터 받는 입력에 높은 결합도를 가지게 된다.(입력값에 명확한 제한이 없으므로, 메소드를 호출하는 외부 모듈이 입력하는 데이터에 높은 종속성을 가지게 된다. ) 그 다음으로 눈에 띄는 문제점은, 바로 HashMap같은 자료구조를 메소드 입력으로 넘기고, 동일 레퍼런스 객체를 결과로 리턴 받아서 사용하는 페턴이다. 이는,인자로 넘어가는 자료구조가, 하위 메소드 내부 로직에 영향을 어떤식으로 받는지 인지를 한 상태에서야, 이후의 제어흐름에서 올바르게 활용을 할수 있기때문에 두 메소드간의 높은 결합도가 형성되어 버린다. 하위 메소드의 오류라도 발견되는 날에는, 디버깅이 아주 복잡해지는 설계 패턴이다. 유지보수성을 위해서는 입력받은 자료구조를 수정하는 메소드는 항상 내부적으로 DeepCopy를 수행해야한다고 생각한다. 그리고 더 나아가, 위에서 말한 두가지 문제점을 한번에 예방할 수 있는 설계 방식이 있는데, 바로 메소드 인터페이스 파라미터에 primative타입 혹은 record등의 immutable 타입을 사용하는 설계 방식을 사용하는거다. 이러면, 리턴 객체는 자연스럽게 새 객체 혹은, deepcopy된 객체가 리턴 될 수 있기 때문이다.