편한 유지보수를 위한 방법론

11/25

 

개발하다가 배우고 느낀점 간단하게 정리. 오늘의 주제는 유지보수를 편하게 만드는 방법이다.

자주 느끼는거지만, 뭔가를 개발할 때 0부터 만드는 것이 작업량은 많아 보여도 생각보다 속 편한 방법이다. 모든 프로그램이 내 의도와 설계 하에 있으며, 그 과정에서 발생하는 사이드 이펙트들을 바로 파악하고 개선할 수 있기 때문에..(이론상)
하지만 업무로써 개발을 하다 보면, 대부분은 존재하는 코드베이스들 위에, 혹은 안에 새로운 로직들을 짜 넣어야 하게 되고, 그 때마다 의도 파악을 위해 히스토리도 확인해야 하고, 사이드이펙트 체크도 해야 하는데, 하지만 그럼에도 불구하고 문제가 또 생긴다.

그렇다면 코드베이스가 존재하는 것과 사이드이펙트를 고려해야 하는 것, 이 두개가 문제인데, 사실상 둘 다 해결을 해야 하는 종류가 아니므로 결론적으론 문제가 덜 발생하도록 방지하는 것이 제일 중요하다.

서론이 길었는데.. 본론으로 들어가자

---

타이밍 만들기

갑자기 뜬금없이 타이밍?? 이라고 할 수 있는데, 사실 거의 기초에 가까운, 이미 잘 알고 있는 것이다. 그것은 바로바로....
기능별로 함수화하는 것이, 전체적으로 나열하는 것 보다 유리하다는 것을 잘 알고 있을 것이다. 또 이걸 지키겠다고 막 하나하나 전부 함수화 했더니, 오히려 전체 기능 흐름이 어떻게 흘러가고 있는지 오히려 가독성이 떨어졌던 경험 또한 있고...

아무튼 여기서 말하고 싶은 타이밍이란 것은, 어떠한 의도한 동작 전 후로 완결되도록, 달리 표현하자면 '타이밍'을 잡을 수 있도록 설계 해 놓는 것이다. 이렇게 설계할 경우, 먼저 유지보수 측면에서 확인해야 하는 곳이 명확하고, 동작별로 구분되어 있어서 편리하다. 다시 말해 원인이 되는 부분을 파악하기가 용이하다.
거기에 더해 추가 작업을 하기에도 편하다. 전후로 어떤 동작들을 하는지가 명확하게 구분되어 있으니, 이 작업을 추가함으로 앞쪽으로는 어떤 것들을 고려해야 하는지, 뒤쪽으로는 어떤 사이드이펙트를 가져올지 고려하기도 좋다.

정리하자면, 기능을 기능 단위로 미리 구별하여 설계하고, 배치하는 것. 함수의 기능화와 목적은 같지만, 엄청 엄격하게 지키는 것은 아닌, 그 정도의 느낌. 단순히 흐름 단위로 주석을작성해 구분해놓는 것도 좋다.

 

로그 작성하기

뭐 로그야 당연히 좋은거 아닌가? 싶을 수 있는데, 생각보다 에러로그를 작성하는 것도 습관화하지 않으면 놓치기 쉽다. 개발 일정이 빡빡하니, 일단 돌려보고 에러뜨네?? 싶은 곳만 고치고 의 반복... 으로 점철된 지난날들...
작성해야 하는 프로그램의 양이 많을수록, 그리고 수정해야 하는 기능의 기존량이 많을수록, 단순히 돌려 보고 문제가 생기는 부분들을 확인하는 것은 불필요한 시간이 너무 많이 소요된다. 이에 주요 포인트마다 로그가 찍혀 나오면 그 부분은 배제할 수 있는 근거가 생기고, 전체적으로 파악해야 하는 시간이 줄어드는 것.

거기에 더해 이런 개발상의 로그는 보통 작성이 완료되면 지우게 되지만, 오히려 신경써서 작성하고 남겨놓으면 좋은 곳도 있다. 예시를 하나 들어보면, 데이터 테이블을 두고 데이터가 들어오면서 사용되는 곳들.
이런 곳들에 데이터의 종류와 내용, 그리고 무엇 때문에 로직에서 처리되지 않는지를 자세히 작성해서 로그로 남겨 놓으면, 협업 과정에서 데이터 누락이나 오류의 경우, 작성한 당사자가 아니더라도 로그만 보고도 무엇이 문제인지 확인할 수 있다. 원인 파악에 들이는 시간도 줄어들고, 핑퐁에 소요되는 코스트도 줄어드는 것.

정리하자면, 로그를 구역별로, 필요한 경우 자세히 남겨놓을수록 유지/보수에 윺리하다. 문제의 원인이 되는 곳을 찾는데 소요되는 시간이 줄어들고, 당사자의 직접 확인 없이도 무엇이 문제인지 확인할 수 있다.