개발자 스스로 이 프로젝트를 평가해 볼 때 ApiEdit는 비교적 깔끔하게 작성되었다고 생각한다. 꼭 필요한 기능에 대해 간결하게 코드를 작성했으며 기본적인 서브루틴들이 잘 정비되어 있어 이후 발생할 문제 해결이 쉽고 기능을 확장하는 데도 큰 문제는 없을 것 같다. 물론 더 고급 기능을 지원하기 위해서는 근본적인 구조 변화가 필요하다. 스스로 ApiEdit에 후한 점수를 메기는 이유는 변화를 받아들일 수 없을 만큼 엉망인 구조는 아니라는 뜻이며 차후의 확장까지도 충분히 고려되었기 때문이다.
하지만 당근의 경우는 결코 높은 점수를 줄 수 없다. 혼자 프로젝트를 하다 보니 다양한 시스템에 두루 호환되는 코드를 작성하지도 못했으며 기능 구현에만 급급하다 보니 에러 상황에 대해서 세심한 처리를 하지 못하고 있다. 에러가 발생하는 것은 어쩔 수 없다 치더라도 에러를 좀 더 빠르고 정확하게 찾을 수 있는 ASSERT문도 일부러 작성하지 않았는데 이는 출판용 예제라는 특수함에 기인한다.
Dangeun.cpp의 길이가 무려 8200줄이 넘는데 이 점만 봐도 당근의 구조가 그리 좋지 않다는 것을 알 수 있다. 메인 윈도우가 너무 많은 일을 하고 있는 것이다. 코드의 길이가 이쯤 되면 한 번의 대대적인 구조 조정이 필요하다. 메인 윈도우가 담당하고 있는 작업들을 잘게 분리할 필요가 있다. 이 구조대로 계속 프로젝트를 진행하여 코드량이 2배 정도 늘어나면 그때부터는 코드끼리 엉켜서 더 이상의 기능 추가가 불가능해진다.
코드를 잘게 분할하는 방식에는 여러 가지가 있는데 현재 상황에서는 객체 지향만이 유일하고도 완벽한 해결책이다. 기능의 덩어리들을 객체로 묶어서 표현하고 메인 윈도우는 모든 작업을 객체에게 위임하는 것이 옳다. OOP가 생산성 향상에 어떤 영향을 미치는지는 따로 설명하지 않더라도 익히 알고 있을 것이다. 현재 버전에서도 CParse, CMru, SOption 같은 몇 개의 객체들이 존재하는데 이 수준을 더욱 더 높여야 한다. 선택영역은 CSelection으로, 캐럿은 CCaret으로 따로 떼어내는 것이 좋고 북마크 관리, 버퍼 구조 등도 객체화하는 것이 좋을 것 같다.
객체 지향 프로그래밍을 할 것인가 아닌가는 더 이상 선택의 문제가 아니므로 망설일 필요가 없다. 좋은 코드를 작성하고 싶다면 시대의 대세를 따라야 한다. 그러나 MFC를 쓸 것인가 아닌가는 선택의 문제이다. 직접 필요와 효용에 맞게 객체 프로그래밍을 할 것인가 아니면 MFC의 미리 만들어진 프레임워크를 활용할 것인가의 차이가 있을 뿐이다.
MFC는 통일된 표준 프레임워크를 제공하므로 이 구조에 익숙한 사람들끼리는 분담 작업이 용이하다는 이점이 있고 이미 제공되는 여러 가지 자료구조를 수월하게 사용할 수 있다. 또한 대화상자의 DDX, DDV 같은 메커니즘은 코드를 직관적이고 간단하게 만들어주며 OnIdle 처리는 기본적으로 처리되므로 별도의 코드를 작성할 필요도 없다. 뿐만 아니라 도큐멘트/뷰 구조를 따르면 분할창이나 16진 편집모드 등은 거의 공짜로 지원받을 수 있다.
그러나 MFC는 코드 크기가 크고 결과코드가 아주 약간 느리다는 단점이 있는데 이는 요즘의 빠른 대용량 컴퓨터의 성능 덕분에 사소한 문제라 할 수 있다. 단일 버퍼 구조의 텍스트 편집기 제작에 Serialize 기능은 어울리지 않으며 효율적이지도 않다. MFC로 텍스트 편집기를 만드는 것 자체는 사실 아무 문제가 없지만 MFC적인 발상이 문제가 될 수는 있다. 버퍼 구조를 CString의 연결 리스트로 작성한다거나 한술 더 떠서 문자의 연결 리스트로 설계하게 되면 편집기는 느려지고 많은 메모리를 소모하게 된다. 사용자 인터페이스는 MFC의 고수준 프레임워크를 사용하고 핵심 루틴은 직접 만들어 최적화한다면 가장 이상적이다.