거대한 모 놀리 식 응용의 위험


20

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

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

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

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

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

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

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


7
태양이 너무 일찍 뜨면 영국은 바다로 표류 할 것입니다.
Maxpm

1
또는 지구의 핵심 압력이 약간 상승합니다.
StuperUser

1
@Maxpm 나는 당신이 무엇을했는지 봅니다
teto

3
@Maxpm : 운 좋게도 앱은 일출과 일몰을 구동하지 않습니다. 우리는 Celestia 공주가 그녀의 일에 실패하지 않을 것이라고 믿습니다.
SF.

1
@rwong : 1. 업그레이드를 위해 장치가 중지되었습니다. 업데이트 중에도 즉시 살아남을 수 있지만 어떤 이유로 든 업데이트가 잘못되는 경우 예기치 않은 결과를 원하지 않습니다. 2. Linux가 내장 된 단일 코어 ARM9. OS없이 실행중인 CPU를 감시하는 두 번째 CPU가 있으며, 메인 CPU가 제정신 출력을 생성하는지 확인합니다.
SF.

답변:


5

마지막에 작은 의견 (두 번째, CPU 감독)을 제외하고 내 회사를 설명 할 수 있습니다. 네, 부활절도 필요합니다.

글쎄, 우리는 조금 더 나아가고 있습니다. 우리는 큰 실행 파일을 분할하고 표준 비트에 표준 구성 요소를 사용하려고했습니다. 정확히 당신이 바라는 큰 개선은 아닙니다. 실제로 하드웨어 성능이 강화 된 경우에도 성능이 큰 문제가되고 있습니다. 또한 좁은 인터페이스를 통해 데이터를 직렬화하고 동기화하기위한 수많은 코드가있어 유지 보수 비용이 줄어들지 않았습니다.

내가 배운 교훈? 단일 실행 파일을 갖는 것은 소규모 시스템에 대한 입증 된 솔루션이며 수십 년간 관리 경험이 있습니다. 우리의 모든 도구는 기본적으로 지원합니다. 모듈성은 단일 실행 파일 내에서도 수행 할 수 있으며 다른 이유로 모듈성을 타협해야 할 경우 해킹은 작습니다.


감사합니다- "따라야 할 / 우수한 모범 사례"와 "가중 잠재적 이점 대 잠재적 단점"항목은 울타리 반대편에서 직접 경험 한 사람만큼 도움이되지 않습니다.
SF.

23

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

당신은 스스로 그것을 말했습니다-그것은 유지 보수가 잘되고 모듈화가 잘되어 있습니다 ...

내 의견으로는, 대부분의 경영진이 이것에 대해 나에게 동의 할 것이며, 변경을 위해 절대로 변경해서는 안됩니다. 이 프로그램 (귀하의 설명)에는 최신 프로그래밍 트렌드 (다른 답변에서 언급 됨)를 따르지 않는다는 것 외에는 아무런 문제가 없습니다.

예, 그것은 더 큰 프로그램입니다 ... 많은 전에도있었습니다. 또한 잘 문서화되어 있으므로 내부 조직을 연구하면 논리를 볼 수 있습니다. 나는 당신이 그것을 쓴 모든 사람들이 무능하다고 의심합니다. 따라서 조금 살펴보고 배우고 ... 그 후에 다시 작성해야 할 확실한 이유가 생길 때까지 그대로 유지하십시오. 비용 / 효과 비율이 좋은 점에 대해 관리자에게 감사드립니다.

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

그것은 크기 때문에 당신을 놀라게합니다-그러나 다시, 아무도 당신이 일주일에 마음으로 그것을 배우기를 기대하지 않습니다. 따라서 작업이 중단 될 때까지 조금씩 작업하십시오. 결국, 당신은 아마도 그것이 잘 구성되어 있고 어떻게 구성되어 있는지 배울 것입니다.

다시 작성해야했지만 동일한 결과를 얻을 수 있었지만 동시에 이전 코드 구성에 익숙한 모든 사람들을 위해 그것을 망치게됩니다. 이 방법으로 만 "적응"해야합니다.


16

모든 것이 단위 테스트에 싸여 있다고 말하면 기분이 좋아집니다. 그렇지 않은 경우 응용 프로그램 재구성에 대해 생각하기 전에 테스트 스위트를 빌드해야합니다.

테스트 스위트를 사용하면 애플리케이션에 대한 이해가 향상되고 애플리케이션 변경으로 인해 문제가 발생하면 알려줍니다.


2
그러나 이것은 가능한 두 가지 아키텍처 모두에 적용됩니다
.

3
그렇습니다.
Robert Harvey

10
... 따라서이 답변은 단위 테스트를 촉진하는 것 외에는 토론에 아무것도 추가하지 않습니다.
benzado

2
@benzado : OP 시나리오에서 어느 것이 가장 중요합니다.
Robert Harvey

2
@ironcode : "레거시 코드로 효과적으로 작업하기"와 같은 책을 살펴보십시오. 그가이 책에서 가장 먼저 말한 것은 "코드 범위가 높은 단위 테스트 스위트가 없다면 먼저 다른 코드를 작성하기 전에 먼저 작성하십시오. " OP가 구체적으로 "내가 간과 한 다른 위험은 무엇입니까?"
Robert Harvey

8

코드가 낮은 결합과 높은 응집력으로 잘 모듈화되면 효과적으로 분할됩니다. 여러 프로세스의 경우보다 한 프로세스 내에서 통신 오버 헤드가 낮아야합니다.

임베디드 시스템의 경우 하나의 프로세스만으로도 모든 프로세스를 실행하기 위해 O / S를 구현할 필요가 없습니다. 또한 실행중인 모든 프로세스를 확인하고 가능하면 다시 시작하기 위해 시스템을 구현해야합니다. 가능하지 않은 경우 적절하게 대응해야합니다.

코드를 별도의 실행 파일로 분할하면 모듈간에 모든 클라이언트 / 서버 코드를 구현해야하므로 소스 코드의 전체 크기가 늘어납니다. 이 코드를 처리하기 위해 더 많은 테스트 사례와 서버 프로세스가없는 경우도 필요합니다. 대규모 프로젝트는 규모가 크므로 여기에서 수행 한 것처럼 불필요한 복잡성을 제거하면 프로젝트를 최대한 작게 유지할 수 있습니다.

테스트는 문제가 여전히 있거나없는 테스트이므로 여기에서는 일종의 붉은 청어입니다. 두 가지 디자인 중 하나를 선택하여 테스트하는 것이 좋습니다. 필자는 모 놀리 식 코드로 테스트가 더 간단하다고 생각합니다.

모 놀리 식 실행 파일을 사용하면 필요할 때 충돌을 일으키는 것이 더 쉽습니다.


1
+1, 엔지니어링은 트레이드 오프에 관한 것이고 작은 바이너리도 비용이 있습니다
benzado

+1 전심으로 동의합니다. 여러 실행 파일을 보증 할 특별한 이유는 없습니다. 실행 파일 간의 커뮤니케이션 및 조정에는 가격이 있습니다.
Erick Robertson

+1 : 파손되지 않았다면 고치지 마십시오.
밥 머피

1

그런 거대한 모 놀리 식 응용 프로그램에서 작업한다면 캡슐화, 낮은 응집력, 높은 커플 링 및이 모든 것을 테스트하는 방법이 나를 놀라게 할 것입니다. 큰 모놀리스는 종종 적절한 건축물을 버리고 큰 진흙 덩어리로 내려가도록 초대합니다 .

그런 일이 발생하면 테스트가 악몽이되어 노후화에 빠지게됩니다.

그러나 코드가 잘 구성되고 유지 관리되고 높은 응집력, 낮은 결합 및 적절한 캡슐화 원칙을 준수하면이를 더 작은 단위로 리팩토링 할 이유가 거의 없습니다.

그래도 좋은 테스트를 원합니다.


1

이상적으로 대답은 '예'입니다. 바이너리가 여러 개 있으면 더 안정적으로 만들 수 있습니다 ....

... 그러나, 당신은 또한 모 놀리 식 코드베이스 내의 코드가 잘 작성되고 모듈화되었다고 언급했습니다.

전반적으로, 나는 적용 가능한 말은 "완벽을 선의 적으로 삼지 말라"고 말할 것입니다. 모 놀리 식 코드베이스가 나쁘다고 말하는 것이 맞다고 생각하지만 걱정할 가치가 없다고 생각합니다.

자신의 바이너리에 새로운 코드 조각을 넣어서 앞으로 나아가는 것이 합리적이지만 돌아가서 리팩토링하는 것은 아마도 가치가 없을 것입니다.


1

단일 프로세스를 사용하는 경우 하위 모듈 중 하나의 와일드 포인터가 중요한 메모리 조각을 손상시키고 전체를 충돌시킬 가능성이 있습니다.

다른 프로세스를 사용하는 경우 최소한 동일한 힙 또는 호출 스택을 사용하지 않으며 단일 하위 프로세스를 다시 시작하는 것이 더 쉬울 수도 있습니다.

소켓이나 공유 메모리를 통해 대화하는 대신 메소드를 호출하거나 변수를 읽을 수있을 때 내부 구조도 더 쉽습니다.

여러 프로세스에서 모든 것을 재정의하면 설계를 정리하고 모든 모듈이 다른 모듈의 내부 방법을 사용하지 않아도됩니다.

그것은 아마도 어려운 작업이라고 할 수 있습니다.

시작할 수있는 것은 모든 새 모듈이 분리 된 프로세스 여야한다고 결정하는 것입니다.


특히 하드웨어 및 임베디드 장치가 관련된 경우 런타임 하드웨어 및 OS 환경에 대해 많은 것을 가정하고 있습니다.
Patrick Hughes

0

한 번에 프로젝트를 시작하기에 너무 큰 영역에 들어가면 모든 큰 섹션과 레이아웃이 어떻게 결합되어 있는지 벽에 걸기 위해 차트를 작성합니다. 그런 다음 작업 할 때 집중하고있는 모듈을 참조하고 전체에 어떻게 적용되는지 시각적으로 상기시켜줍니다.

연결이 끊긴 여러 바이너리에 대해 빌드 및 버전 관리 시스템을 유지 관리하는 복잡성과 위험이 이러한 대규모 단일 프로젝트로 인해 불안감을 훨씬 능가 할 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.