내가 몇 년 동안 노력하고있는 큰 프로젝트는 펌웨어의 핵심 인 고급 장치의 제어 및 모든 응용 프로그램입니다.

장치는 메모리에서 말할 수있는 것보다 더 다른 기능으로 상당히 발전했으며 98 %는이 거대한 실행 파일로 처리됩니다. 한편으로, 프로그램은 상당히 유지 관리가 가능하고 내부적으로 모듈화되어 있으며 문서화되어 있으며 디렉토리와 파일 등으로 기능이 합리적으로 분리되어 있습니다.

그러나 결국 원격 데이터베이스 통신, 터치 스크린 처리, 수십 가지 다양한 통신 프로토콜 처리, 측정, 여러 제어 알고리즘, 비디오 캡처, 일출 시간 및 부활절 날짜 등 모든 것을 수행하는 하나의 응용 프로그램으로 클러스터링됩니다. 매우 진지한 목적에 필요합니다!) … 일반적으로, 매우 얇게 관련된 것들, 종종 일부 원거리 모듈들 사이를 흐르는 일부 데이터를 통해서만 관련됩니다.

소켓을 통해,보다 구체적인 목적으로, 필요에 따라로드 / 언로드 등 서로 통신하는 여러 개의 개별 실행 파일로 수행 될 수 있습니다. 이런 식으로 만들어진 특별한 이유는 없습니다.

한편으로는 작동하며 정상적으로 작동합니다. 여러 바이너리의 빌드를 유지하지 않고도 프로젝트가 더 간단합니다. 소켓이나 공유 메모리를 통해 대화하는 대신 메소드를 호출하거나 변수를 읽을 수있을 때 내부 구조도 더 쉽습니다.

그러나 다른 한편으로,이 것의 크기, 규모는 저를 놀라게합니다. 그것은 타이타닉을 조종하는 느낌입니다. 나는 항상 모듈화하는 법을 배웠고 모든 것을 하나의 거대한 파일로 묶는 것이 잘못되었다고 느낍니다. 내가 아는 한 가지 문제는 (심지어 무의미한) 하나의 모듈이 모두 충돌하는 것입니다. 그러나 코드 품질은 이것이 릴리스 버전에서 실제로 발생하지 않도록합니다. 그렇지 않으면 내부 분리 및 방어 프로그래밍을 통해 내부 모듈의 절반이 어떤 이유로 정상적으로 작동하지 않더라도 대부분 올바르게 실행됩니다.

다른 어떤 위험을 간과 했습니까? 왜 이런 일이 발생합니까? 이것은 알려지지 않은 것에 대한 비이성적 인 두려움 일까? 진지하게 큰 프로젝트를 이런 식으로 받아들이 는가? 내 두려움을 진정 시키거나 버전 2.0을 여러 개의 작은 바이너리로 리팩토링해야 할 충분한 이유가있다.

답변