제일 먼저 해야 할 일은 문제점을 파악하는 일이다. 문제점을 파악하면서 새로운 구조를 생각해보기로 했다.

나래온 툴의 근본적인 문제는 기능 자체에 대해서는 많은 고심 끝에 만들어진 것들이지만 내부는 별 생각 없이 만들었다는 점이다. 프로그램이 오래 갈 것에 대해서 손톱만큼도 생각을 해 보지 않은 것이 설계에 묻어난다. 물론 개발이 계속 진행되면서 모듈화가 지속적으로 이루어졌지만, 그러지 못한 부분들도 많고 특히 핵심 부분은 거의 바뀌지 않았다. 대표적으로 문제를 꼽아보면 다음과 같다.

1. UI 소스가 너무 길다

UI 소스만 1001줄!

메인 폼의 소스가 너무 길다. 이런 탓에 몇 번 모듈로 빼서 대략 1000줄 가량의 소스가 또 생겼지만 내부에 그만큼의 코드가 더 생겼다.
이렇게 된 이유는 애초에 프로그램이 커질 걸 예상을 못하고 MVC 분리를 제대로 하지 않았기 때문이다. 물론 MVC에도 장단점이 있어서(대표적으로 델파이의 RAD 기능이 쓸모없어진다) 엄격하게 MVC를 따를 생각은 없지만 비즈니스 로직은 좀 분리할 필요가 있다.

2. 절차 지향과 객체 지향이 무분별하게 섞여있다

프로그램에 함수로 된 계층이 있다

프로그램에 전역 함수로 된 계층이 있을 정도로 함수의 증가세가 심하다. 사실 저 그림도 확실하지 않다. 함수들 사이에 상호 호출이 굉장히 많아서 TSSDInfo 객체 – DiskFunctions 유닛 – PartitionFunctions 유닛은 하나의 혼돈이라고 봐도 될 정도다. 꼭 엄격한 객체 지향을 따르지 않더라도 함수와 함수 간이라도 정확한 분리가 필요하다.

3. 객체의 공개성이 구조체급이다

대표적으로 TSSDInfo, 모든 필드가 public이다. 어차피 읽기 전용 클래스로 썼으므로 입출력을 헷갈려서 생기는 문제는 발생되지 않았지만, 유닛 하나만 떼어놓고 보면 낙제점인 셈이다.

4. 명령 집합(ATA, SAT 등)의 확장성이 별로다

나는 명령 집합의 추가로 인한 부담이 별로 없을 줄 알았다. 그런데 이번에 확인해보니 명령 집합을 꽤 높은 레벨에서도 자주 부르는 것이 목격되었다. 따라서 새로운 명령 집합을 추가하기 위해선 추상적인 고수준 객체와 분리할 필요가 있다.