이전 글에서 SI에 대한 비판이 녹아나있는거 같다는 생각이 들었다.
하지만 문제를 의식적으로라도 바라보고 진정으로 마주해야 그안에서 해결하려는 목소리도 나오지 않을까 싶다.
애자일 방법론에서 문제를 드러나게 하여 이슈화시키는 것과 비슷하게 말이다.
나로서는 과거를 돌아보고 기록하여 미래에는 좀 더 나은 방향으로 가기를 바랄뿐이다.
전편에 이어
.
.
.
레거시 시스템2
이 오래된 시스템은 크게 몇가지 문제가 있어보였다.
-
모듈간의 정합성이 떨어진다
-> 초기의 단순했던 모듈들이 시간이 지나서 기능들이 추가되고 그것도 각자 다른 개발자들이 그것을 수행하면서 패키지, 클래스, 함수, 변수등의 네이밍이 각자 모두 달라고 코딩방식, 형식 등 모든 것이 제각각이었다. -
데이터를 처리하는 모듈이 일괄되지 않는다
-> 최종적으로 데이터베이스에 저장될 데이터를 처리하고 가공하는 곳이 제각각이었다. 어느곳은 프론트에서 데이터를 가공하여 전달하고 어느곳은 controller에서 또는 servece에서 또는 DAO에서 하기도하고 최악은 프론트에서 가공한 데이터를 contoller에서 재가공했다가 DAO에서 다시 가공하기도 했다.
또한 연계시스템으로 전달하여 오라클 패키지내에서 스케줄이 돌며 가공되기도 했다. -
로그 시스템 없이 무분별한 로그로 인해 추적이 어렵다
-> log4j같은 라이브러리가 존재하였지만 데이터 처리뿐만 아니라 각 모듈에서 로그 규칙없이 무분별하고 무의미한 로그를 남기는것이 많아 혼란스러웠다.
이러한 몇가지 문제로 인해 이 시스템에서 오류가 발생하거나 데이터가 잘못 들어갔을 경우 그것에 추적하기도 수정하기도 매우 어려웠다.
문제점을 파악한 뒤로는 주어진 업무 외에 나름대로의 목표를 설정하였다.
점진적으로 리팩터링하여 시스템을 개선할 것이다.
리팩터링
시스템을 리팩터링하여 개선하는것은 쉽지 않은 여정이였다.
그리고 결론부터 말하자면 해피엔딩은 아니다.
리팩터링 대상은 시스템 전체적으로 광범위하기에 무엇을 어디부터 손대야할지 난관이였다. 그리고 나는 리팩터링에 대해 모르는 상태에서 호기롭게 이것을 공부해서 적용하겠다고 마음먹은것이다.
무엇보다 시스템의 권한과 책임을 가지고있는 고객사 담당자도 그리고 같은 팀내의 개발자 조차 이것이 왜 필요하고 무엇을 얻을수있는지 인지하지 못하는 상황이었다.
그렇지만 여러가지 문제점들을 해결하는 방법은 결국 이것이 정답이라고 생각했고 반드시 하고싶었다.
결국은 난관을 해결할 나름대로의 방법을 찾고 리팩터링을 공부하여 천천히 느리지만 꾸준히 리팩터링을 하기로 했다.
리팩터링2
내 나름대로의 방법은 이러했다.
리팩터링 자체를 업무로 승인받기는 어려웠고(몇번의 간접적으로 담당자에게 얘기했지만 이해받지 못하고였고 동료개발자들은 소통자체를 꺼려하는 분위기와 나에대한 업무 평판이 낮았기때문에 얘기하지 못했다)
업무내의 최대한 녹여내여 실행할수 있었다.
어떤 오류가 발생하여 담당자가 수정요청을 한다면, 프로세스를 분석하여 대상 범위와 수정할 부분을 빠르게 피드백한 뒤, 일정을 산출함에 있어 약간의 시간을 더 추가하여 그것을 활용하여 조금씩 개선하는 방법이다.
내 입장에서는 다른개발자에 비해 처리속도가 늦어져 실력에 대한 평이 좋지 않았기에 정신적인 부분에서도 어려움이 있었다.
처음에는 리팩터링이 문제가 아니라 원래 유지보수의 업무인 오류처리조차 쉽지 않았다.
문서도 참고할 레퍼런스도 없고 도움을 요청할 동료도 없는 상황에서 복잡한 프로세스를 분석하여 원인을 찾아내는것부터 어려웠다.
하지만 시간은 우리편이고 사람은 적응하는 동물이다.
시간이 지남에 따라 복잡해보이는 시스템도 익숙해지고 조금씩 업무 처리속도가 올라감에 따라 고객사내의 나의 입지도 올라갔고 원래 목표였던 리팩터링도 할 수 있게 되었다.
리팩터링은 계획했던 방식으로 진행되었다.
먼저 오류가 발생했던 프로세스를 분석하여 camunda modeler 툴을 사용해 매우단순한 형태의 BPMN으로 시각화하였고고 오류원인 대상뿐만 아니라 연관된 앞뒤의 모듈을 리팩터링 대상으로 잡았다.
리팩터링을 학습방법으로는 유명한 책을 읽었다. 회사내에서는 도메인 지식을 강조할뿐 그외에 개발에 관해서 관심있는 개발자를 찾을수없었고 온라인에서는 체계적인 리팩터링에 대한 방법들을 내가 자체적으로 필터링할 능력이 안되기 때문에 잘못하다가는 잘못된 방향으로 될까 싶어 책을 선택하게되었다. 온라인 강의를 찾았으나 오히려 부족한 이론때문인지 더욱 난해하게 느껴졌다.
무튼 1독을 완료한 시점에서 리팩터링이 대해 어느정도 감을 잡았다 수준이었고 디테일한 방법에 대해서는 전혀 모르는 상태였다. 한가지 느낀점은 클린코드를 함께 적용해야한다는 점이었다.
그리하여 클린코드를 학습하고 리팩터링에 녹여내기로 하였다.
클린코드
목차를 꼼꼼하게 읽은뒤 내용은 빠르게 읽어 내려갔다.
무언가를 시작할때 중요하게 생각하는점은 디테일에 너무 신경쓰면 일 자체가 진행이 안된다는 점이다.
장인이 되기위해서는 디테일에 신경써야한다. 하지만 시작하는 단계에서 디테일을 신경쓰다보면 흐지부지 끝나느 경우가 많다.
아주 빠르게 정리하지 않고 읽어 내려갔다.
목차가 매우 중요했다. 이것만으로도 나에게는 버거웠다.
의미가 어려웠다기보다는 방대한 양을 전부다 해내고 싶었던 내 욕심이 나를 힘들게 하였다.
네이밍과 형식맞추기 같은 간단한것은 바로 적용이 가능해보였다.
가장 쉽고 빠르게 적용한것은 '보이스 카우트 법칙'이다.
"캠프장에 처음 왔을때보다 더 깨긋하게 해놓고 떠나라"는 의미이다.
코드를 다룰때 변수 이름 하나를 개선하고, 조금 긴 함수를 나누고, 약간의 중복을 줄이는것만으로 충분했다.
이것은 신입개발자에게 권했다. 너무 많은것을 하지말고 딱 한가지만 개선해보라고 하였다.
신입에게는 결과보다는 과정이 더 중요하다. 변수명 하나를 개선하기위해 고민하는 그 과정들이 추후에 더 나은 개발자로 성장하는 거름이 될꺼라고 기대했다.
나 역시 결과보다는 과정에 더욱 집중하였다. 욕심은 줄이고 조금 느려도 괜찮다는 마음가짐으로 임하였다.
가장 먼저 눈에 들어오는것은 '주석'이였다.
동료 개발자들은 운영중인 시스템에서 문제없는 코드를 건드는것이 매우 꺼려했다. "굳이 왜 잘돌아가는 시스템을 수정해서 문제가 발생시키려하나"식이였다. 물론 함부로 손대는것은 잘못된것이기는 하였지만 개선이 필요한것을 방치하는것은 더욱 잘못된것이였다.
여기에는 주석도 포함되어있었다.
10년전에 작성된 주석, 개발자가 확인하기위한 주석, 코드 변경을 반영하지 못한 주석 등등 주석이 오히려 혼란을 유발하기도 하고 주석으로 인해 코드 형식을 깨지는 등
그 누구도 이 주석을 무시한채 코드를 다루고 있었다.
나는 주석은 모두 지워버리고 의미있는 주석은 코드에 녹여 내려하였다. 어떤것은 변수명을 의미있게 변겨하는것으로 가능했고 또다른 것은 함수명에 주석내용을 담을수있게 변겨하기도 하였고
어떤것은 반드시 필요하다고 생각되어 코드 형식을 깨뜨리지 않도록 상단에 잘 정리하기도 하였다.
그 과정은 단순해 보이지만 어려운점은 검증할 사람이 오직 나뿐이라는점이었다. 코드리뷰를 받고싶었고 옳은 방향으로 가고있는지 의구심이 들었다.
지금 상황에서는 계속해서 하는것만이 최선이었다.
클린코드2
다른 방법을 떠올릴수없었다.
"단지 하는것, 계속하는것, 꾸준히 하는것" 밖에는 없었다.
그 다음으로는 함수를 개선하는것이었다.
리팩터링을 적용함에 가장 큰 핵심은 기존의 기능을 유지해야한다는것이다.
클린코드의 관점으로 코드를 깨끗하게 유지하였다면 그 다음은 리팩터링을 통해 더욱 견고하고 유지보수성이 높이도록 설계를 변경하는것이다. 여기서도 유의해야할 점은 작은것부터 개선해야한다는 점이었다. 처음부터 큰 관점으로 패키징, 클래스같은 모듈을 건들다가는 정합성을 깨뜨릴수있다. 특히나 모듈간의 결합도가 너무 높았기때문에 잘못건들였다가는 사이드이펙트의 범위가 더욱 커지게된다. 예측이 불가능한것은 오히려 리팩터링을 하지 않아야 한다. 클린코드를 먼저 적용하려했던 이유이기도 하다.
간결하고 읽고 분석하기 쉬워야 리팩터링도 가능하다.
리팩터링3
가장 작은 모듈구성인 함수를 리팩터링해야했다.
기능을 추가하다보면 자연스럽게 기존의 함수에 추가하는 경우가 있다.
나도 그래왔고 그것에 대해 문제를 인지하지 못했다.
함수를 작게 만드는것이 좋다는건 알고있어서 처음에는 한가지 기능만하도록 작게 만들곤하였지만 이랬던 함수가 이렇게 거대해질꺼라고는 생각하지 못하였다.
나도 모르는 사이 기존의 함수에 if문을 넣고 추가기능을 else에 넣게되고 이후에 또다른 추가기능이 발생하면 if else에 코드를 추가하는 식으로 난잡해진다.
유지보수를 하면서 얼마나 큰 문제인지를 깨닫게 되었고 리팩터링 책을 보면서 어떻게 개선해야할지를 알게되었다.
이렇게 거대해진 함수는 분석부터가 난관이였다.
어떤 변수가 어느부분에서 어떻게 사용되는지 파악하기가 어렵고, 출력되는 결과도 다양하다. javascript의 전역변수를 제대로 이해하지 못하고 사용함으로서 발생하는 결과를 단지 출력값으로만 검증하는 경우도있었다.
무튼 이런 함수들은 먼저 클린코드적 관점으로 정리한뒤
기능을 따로 분리하여 별도의 함수로 빼내기도 어느것은 합치기도 하였고 따로 분리된 함수는 내부 중첩함수로 작성하거나 private하게 캡슐화를 하여 진행하였다.
수개월을 진행하는 동안 나름대로의 목적을 달성한듯 보였으나
결국 넘을 수 없는 거대한 벽에 다다르게 되었다.
.
.
.
제목과 다르게 이직에 관한 내용보다는 SI의 경험과 내가 겪은 문제들에 대한 고찰로 내용이 채워진거 같다.
다음편에서는 이직에 관한 내용이 전개될거같다.
