이기적인 총무 - 리팩토링 계획

단순히 기능적 요구사항만 만족하는 소프트웨어가 아니라 변경 용이성, 성능, 사용 편의성과 같은 품질 요소와 객체 지향적인 관점을 고려해서 구현하는 것이 구조적으로 튼튼한 소프트웨어를 만드는 일이다. 이기적인 총무를 처음 만들때는 빠르게 출시 해보는것이 목적이어서 기능 구현과 UX 디자인 이외의 것들을 생각하지 못했다. 그러다보니 몇몇 기기에서는 정상적으로 작동하지 않고 있고 수정 하려고 해도 어디서 부터 손대야 할지 엄두가 나지 않는다. 이미 출시 된지 꽤 많은 시간이 흘러 조금 늦은 감이 있지만 앞으로 두달 간은 그동안 놓쳐 왔던 것들을 계획을 세워서 보완해 볼 생각이다.

1. 구조설계서 작성

가장 중요한 일임에도 불구하고 빠르게 개발하는데 급급해 문서 남기는 일을 생략했다. 그 결과 마지막으로 업데이트한지 4달이 된 지금, 블로그를 제외하곤 아무런 문서가 없으니 처음부터 끝까지 개발한 나도 어떤 기능적 요구사항이 있었는지 그리고 이건 왜 이렇게 만들었는지 헷갈릴 지경이다. 적어도 나를 위해서도 문서를 남겨 뒀어야 했었는데.

그리고 문서를 만드는 과정이 없어 그런지 품질 요구사항에 대해서 진지하게 고려해보지 못했다. 이기적인 총무에 새로운 기능을 제안해주시는 분들이 있는데 개발 할 때 확장성과 변경 용이성을 고려하지 않아서 어떻게 수정해야 할 지 엄두가 안난다. 클래스 다이어그램이라도 그려 뒀으면 구조 파악이 쉬웠을텐데 말이다.

하지만 문서를 이쁘게 만드는데 비중을 두진 않을 것이다. 구조설계서의 주요 독자는 나와 혹시 모를 이기적인 총무앱의 동업자이며 소프트웨어를 잘 만들기 위해 작성하는 문서지 다른 사람들을 설득하기 위해 작성하는 문서가 아니다. 그리고 다른 개발자가 오독하지 않는 선에서 다이어그램의 문법을 적당히 지키려고 한다. 띄어쓰기를 지키지 않아도 무슨 말을 하는지 이해할 수 있는 것처럼 다이어그램도 개발자가 읽고 이해 할 수 있는 수준이기만 하면 된다.

2. 객체 지향 프로그래밍

나름 객체 지향의 관점으로 구현했는데 SE 수업을 듣고나니 이렇게 많은 기법이 있을 줄이야. 왜 90년대 이후로 객체지향/객체지향/객체지향 하는지 이제 알 것 같았다. 학자들이 연구한 내용을 보니 용어도 다 기억하기 어려울 정도로 수많은 원칙/프로세스가 있었다. 물론 다들 비스무리한 것들을 말하는 것 같지만, 이런 비스무리한 것들을 구현 할 때는 고려하지 못했다.

모든 원칙을 적용하기는 어려울 것 같아 핵심적인 것들만 간추려서 적용해보려고 한다. 현재 개발된 코드에 GRASP와 SOLID 원칙을 적용해 객체를 다시 명세한 후 Design Pattern이 적용될 부분을 찾아 개발에 옮길 생각이다. 이것만으로도 충분 한 것 같다.

이것들에 대해서 짤막하게 소개하자면...

GRASP - 시스템에서의 클래스를 나누는 기법을 말한다. 즉 시스템 내에서 새로운 객체를 만들고 역할을 부여할 때 판단의 기준이 된다

SOLID - 객체 지향 프로그래밍의 가장 기본적인 5가지 원칙.

• 클래스는 하나의 책임(Responsibility)만 가지고 있어야 하고(SRP)
• 확장에는 열려 있어야 하고 수정에는 닫혀 있어야 하며(OCP)
• 객체는 시스템의 정확도를 깨뜨리지 않으면서 상속 할 수 있어야 하고(LSP)
• 여러개의 범용 인터페이스보다는 특정화된 인터페이스가 나으며(ISP)
• 객체는 인터페이스에 의존해야지 구체화된 것에 의존하면 안된다(DIP) 가 있다.

Design Pattern - 객체 지향 기법을 이용해서 설계시 자주 발생하는 문제들의 해결 방법. 23가지가 존재한다.

3. Metric 측정

CCM, LCOM처럼 객체지향 프로그래밍에 다양한 지표가 있는 줄 몰랐다. 아마 이런 걸 알았더라면 막 짜지는 않았을 것 같은데 말이다. 그리고 내가 무의식적으로 얼마나 이런 지표를 잘 지키면서 구현했는지 궁금하기도 하다. 

2번 과정을 하기 전에 먼저 지표를 측정해보고 적용 후의 지표를 측정해볼 생각이다. 리팩토링 결과 코드의 품질을 수치적으로 비교할 수 있는 기록이 될 것 같다.