일부 오래된 (나보다 오래된) C 코드를 정리하고 최신으로 가져와 (다른 것들보다) 유지 관리가 쉽고 현재 코드와 더 완벽하게 통합됩니다.레거시 C 코드를 MVC 디자인에 리 팩터 화합니다.
기존 코드는 상당히 엉망이며 GUI 로직을 비즈니스 로직 및 데이터 액세스 로직과 자유롭게 삽입합니다. 유일한 절약은 스파게티 코드가 아니며 모듈화 된 것입니다 (70 년대 대부분의 코드가있는 경향이 있습니다).
내 질문은 : 누구나 MVC로 코드를 리팩터링하는 방법에 대한 가이드 라인을 제공 할 수 있습니까? (BTW 또한이 작업을 수행하는 동안 C에서 C++로 코드를 이동합니다. 염려, 나는 두 언어 모두에 대해 상당히 비합법적이다.)
나는이게 사소한 일이 아니라는 것을 충분히 알고 있습니다. DBAL/BL/GUI를보다 깔끔한 MVC 구현과 섞은 모듈 코드에서 어떤 단계가 진행되는지 알고 싶습니다.
확실한 단계가있을 수 있다고 확신하지는 않습니다. 기존 코드의 구조에 따라 달라질 수 있습니다.
@ Jesus Ramos에 동의합니다. 여기서는 테스트 전략을 찾는 것이 핵심입니다. 문제는 "단위"가 실제로 없기 때문에 코드가 현재 단위 테스트 할 수없는 것이기 때문에 UI를 테스트하지 않고 비즈니스 로직을 테스트 할 수는 없습니다.
나는 리팩토링보다는 그 내용을 다시 작성하는 것에 대해 매우 진지한 고려를 할 것입니다.
리팩터링을한다면 내 생각에 일종의 "스위스 치즈"방식을 택할 것입니다. 구멍을 많이 뚫어 중앙 질량을 남기고 조각을 뚫습니다. 따라서 명확한 API와 데이터 객체 집합을 제공하는 데 중점을 둔 데이터베이스 액세스 코드를 가져와 모델의 기본이됩니다. GUI 코드를 뷰 레이어로 가져 오십시오. 남은 것은 컨트롤러 논리이며,이를 리펙토링 할 수 있습니다.
비즈니스 로직 레이어를 먼저 작성하고 (일부 단위 테스트와 함께 원래대로 실행되는지 확인), 데이터 레이어에서 다시 단위 테스트와 함께 작업하게됩니다. 이 두 가지를 얻은 후에는 GUI 코드를 결합하지 않고도 견고하게 만들 수있는 인터페이스를 만드는 것이 가장 좋으며 비즈니스 로직과 데이터의 필수 기능을 GUI에 표시하는 것은 개인적으로 GUI가 가지고있는 데이터 만 제출해야하지만 비즈니스 논리 계층을 생성 한 다음 데이터 계층에 제출합니다. 여기서 중요한 것은 유닛 테스트 (가능한 경우)입니다. 그러면 코드와 원본이 모두 기능적으로 동일한 지 확인하는 것이 더 쉬울 것입니다.
이 단계를 단계별로 수행 할 필요가 없으므로 끝까지 GUI를 종료하는 것이 비즈니스 논리 계층보다 덜 복잡합니다 (대부분의 경우).
가장 어려운 작업은 일부 사람들이이 작업을 어렵게 만들고 단 하나의 기능으로 3 개의 레이어를 모두 가지므로 그만두면 혼란이 될 수 있으므로 디커플링 자체를 파악하는 것입니다.