MFC의 추억

1994년에 나온 MFC 기술

 

 

- 제조업체들에는 독특한 소프트웨어 개발방식이 존재하는데요 ..​

- 신규 장비개발 프로젝트가 시작되면 제어나 비전 프로그램을 첨부터 새로개발하는게 아니고

- 이런저런 이전 프로젝트용으로 이미 개발해논 소스크드를 가져와서 새장비에서 달라진 부분만 뜯어고치는 식으로 많이들 개발을 하더라구요 ..

- 컴퓨터공학에서 이런 개발 방법론도 부르는 공식 명칭이 존재하는지 궁금합니다.

Waterfall 도 아니고 .. 애자일도 아니고 ... ^^;

- 여하튼 그러다 보니, 개발해논 소스코드는 이사람 저사람이 손을 댄 흔적들이 고스란히 남아있어서, 기본 몇기가가 넘을 정도로 거대하구요. 지우지 않고 뭉텅이로 코멘트 처리해논 옛날 함수들도 허다 합니다.

- 심지어는 이전 프로젝트에서 캡쳐해놓은 이미지들(바코드나 OCR 테스트 이미지 등등)같은 리소스파일 들도 다수 존재하는 경우가 종종 있기도 해서, 코드의 이해에 혼동을 주기도 합니다.

- 특이한건 이런 코드일수록 정체모를 dll 들과 중복되는 클래스들도 많고, 중복 래퍼들도 많으며, 코멘트가 거의 안달려 있어서 초기부터 개발을 경험한 개발자만이 코드를 이해할수 있다는 것이며. 그게 다른사용자가 이코드를 이해하고 수정하기 어렵게 됩니다.

- 다시말해, 기존 개발자는 진입장벽을 쌓기 쉬워지는 반면 신규투입 개발자는 인수인계 및 개발이 어려워지는 개발 방법론 이라고 생각 됩니다. ​

- 이런 개발방식 때문인지, 국내 제조업체들은 아직도 여전히 수십년전 개발환경인 델파이나 MFC 같은걸 고집하고있는곳도 많죠. C#.Net 으로 넘어간 곳은 그래도 양반 ...

- 그 때문에 인공지능 혁신을 주도하는 파이썬 또는 오픈소스 진영과 호환(또는 Glue Coding)이 매우 힘든 부작용도 낳고 있구요 ... 제조업에 딥러닝을 접목하기 힘든 장애물로 작용하고 있기도 합니다.

- (저도 시니어 지만) 시니어 개발자 분들의 이런 변화하지 않으려는 개발방식은 가뜩이나 어려워지고 있는 국내 제조업에서의 소프트웨어 개발의 혁신을 가로막고 국제 경쟁력을 저해하는 요인으로 느껴집니다만... 여러분들 생각은 어떠신가요?

- C#.Net 이 처음 나올때 MS가 했던 말이,

"MFC는 개발자 등골빼먹을 정도로 비효율적인 GUI 프레임웍이므로 이젠 Winform GUI(c# .net )로 다들 넘어가야 합니다. MS는 MFC를 더이상 업그레이트 하지 않을것입니다"

였습니다.

- 하지만 C#.net 이 계획과는 달리 널리 사용이 안되자 MS는 여전히 MFC를 계속 수명연장 하고 있지요.

어쩌면 MFC의 낮은 GUI 개발생산성 때문에 궁여지택으로 기존코드 재활용 방식은 시작된 걸지도 모릅니다...!