외부 명령 줄 응용 프로그램을 호출하거나 해당 응용 프로그램의 논리를 내부화하는 것이 더 좋은 방법입니까?

10

"파이프 라인"종류의 프로세스가 있는데, 이는 본질적으로 워크 플로우를 자동화하기 위해 많은 기존 도구들을 서로 연결하는 것입니다. 단계 중 하나에 대해 해당 단계에서 수행해야 할 작업을 이미 수행하는 기존 명령 줄 도구가 있습니다.

외부 CLI 도구는 Java 기반이며 파이프 라인도 마찬가지이므로 도구를 파이프 라인 단계에 직접 통합 할 수는 있지만 도구는 매우 복잡하며 현재 명령 줄 입력 (예 : 37 구성 플래그 옵션).

문제는 : 단순히 외부 프로세스를 호출하고 호출하는 것이 더 좋은 아이디어입니까, 아니면 내 응용 프로그램에 외부 코드를 통합하는 것이 더 낫습니까?

통합과 외부 프로세스 호출의 장단점은 무엇입니까?

java architecture

— cdeszaq
소스

명령 줄 도구는 사용자가 제어하는 대상입니까, 아니면 다른 사람이 개발 한 것입니까?

— whatsisname

오픈 소스 (Mozilla 라이센스) dcm4che DICOM 툴킷이므로 다른 당사자가 개발했지만 원하는대로 할 수 있습니다.

— cdeszaq

12

단순히 외부 프로세스를 호출하고 호출하는 것이 더 좋은 아이디어입니까, 아니면 내 응용 프로그램에 외부 코드를 통합하는 것이 더 낫습니까?

이다 훨씬 이러한 것들을 통합하는 더 나은.

명령 행 인터페이스는 인터페이스 일 뿐이며 특히 끔찍한 인터페이스입니다. 그것은 필수적 이지만 합리적이지 않은 단점과 한계로 가득 차 있습니다.

"워크 플로우 자동화를위한 기존 도구"각각 에는 명령 행 옵션을 구문 분석 한 후 실제 작업을 수행하는 깔끔한 클래스 가 있어야합니다 .

이상적으로이 public static void main함수는 "기존 도구"각각에서 두 가지 작업을 수행합니다.

명령 행 옵션 / 인수 파서를 호출합니다.
실제 작업을 수행하는 깔끔한 클래스를 호출합니다. Ant 또는 Maven이 모든 구문 분석 및 의사 결정을 처리 한 후 실제 작업을 수행하는 Ant 태스크 또는 Maven 태스크를 생각해보십시오.

이러한 것들을 통합하려고 할 때 실제 작업을 수행하는 깔끔한 수업이 필요합니다.

그것들이 존재하지 않는다면, 모든 명령 행 파싱과 별개로 실제 작업을 수행하는 깔끔한 클래스를 만들기 위해 모든 도구를 다시 작성해야합니다.

이러한 깔끔한 클래스의 작동 방식에 대한 지침은 Ant (또는 Maven)를 읽고 다양한 작업자 작업을 정의하는 방법을 확인하십시오. 커맨드 라인으로 돌아 가지 않고 여러 이질적인 것들이 어떻게 통합되어 있는지에 대한 좋은 정신 모델입니다.

— 로트
소스

필자의 경우, 작업을 수행하는 클래스는 전체 도구이며 main메소드, CLI 구문 분석 메소드 등을 포함합니다. 다소 불쾌합니다. (

— cdeszaq

@ cdeszaq :이 경우 수정해야합니다. 그것은 매우 어려운 재 작성이 아니며 반드시 이루어져야합니다.

— S.Lott

3

마감일에 따라 기존 CL 인터페이스와 통합하여 시간이 지남에 따라 올바르게 통합 된 솔루션으로 포팅 할 수 있다고 덧붙였습니다. 지금이 문제를 해결하는 시간을 할 경우에, 다음 :-) 그렇게

— 마티 Verburg

1

@MartijnVerburg : 좋은 지적입니다. 종종 명확한 우선 순위가 있습니다. 일부 워크 플로는보다 긴밀하게 통합되거나 잠재적으로 "하위 워크 플로"로 별도로 사용될 수 있습니다. 이로 인해 가장 가치있는 것부터 가장 가치없는 것까지의 재 작업이 발생할 수 있습니다.

— S.Lott

마지막 고용주에서 유틸리티 exe를 실행하는 데 문제가있었습니다 (우리는 전혀 코드가 아닙니다). "고급"개발자가이 exe가 실행되지 않는 이유를 진단하는 데 도움이되도록 bat 파일을 작성하여 시작하는 것이 좋습니다. 효과가있었습니다. 그는 문제를 찾는 것을 그만두고 그것이 문 밖으로 나간 방법입니다. 내가 배운 교훈은 1입니다. 의사 결정을 내리는 사람에게 문제를 해결하는 나쁜 생각을 제안하지 마십시오. 2. 라이브러리를 사용하거나 가능한 한 자신의 논리를 내면화하십시오. 이 "수정"에는 일부 시스템에서 많은 기술 지원 비용이 들었습니다. 그는 또한 테스트 또는 소스 제어를 믿지 않았으므로 놀라운 것은 아닙니다.

— Rig

8

나는 그것이 작동한다면 그것을 내버려 두라고 말할 것입니다.

프로그래머는 소프트웨어 문제를 해결하여 조직에 가치를 부여합니다. 주어진 시간 내에 품질과 수량 모두에서 더 많은 문제를 해결하는 것은 조직의 가치와 직접 관련이 있습니다. 코드를 작성하는 데이 시간을 소비하면 더 중요한 문제를 해결하지 않아도되므로 가치가 줄어 듭니다.

그러나 시간 소비를 줄일 수있는 몇 가지 요소는 확장 성과 외부 프로그램 안정성에 대한 우려가있는 경우에 해당합니다.

— 빅 테크
소스

동의한다. 타사 프로그램 / 코드를 앱에 통합하려고하면 많은 어려움을 겪을 수 있습니다. 때로는 필요할 수도 있지만, "파산하지 않으면 해결하지 마십시오"라는

— 말이 나오듯이

5

문제를 해결하는 것이 좋습니다. 다른 문제의 문을 여는 동안 일부 문제를 해결하는 것은 그리 좋지 않습니다.

— yfeldblum

5

"더 나쁘거나"더 나쁘지 않습니다. 단순히 다른 비용과 혜택이 있습니다.

복잡도를 높이기 위해 통합 지점 수가 많을수록 소프트웨어를 작성하고 유지 관리하는 것이 더 비쌉니다.

작성하는 함수는 통합 비용이 거의 없습니다.
타사 라이브러리는 통합 비용이 약간 더 큽니다.
실행해야하는 별도의 프로그램에는 더 큰 통합 비용이 있습니다.

이는 소프트웨어 작성 및 유지 관리 비용을 포함하여 총 비용과 비교해야하는 통합 비용입니다.

당신은 매우 경험이 부족한 프로그래머이지만 오랫동안 파워 유저입니다.

경험과 지식으로 통합 비용을 완화 할 수 있기 때문에 높은 통합 비용에도 불구하고 총 비용을 "쉘 아웃 (shell out)"할 수 있습니다.
함수를 직접 작성한다면 경험이 부족한 프로그래밍으로 인해 낮은 통합 비용에도 불구하고 총 비용이 상당히 높아질 수 있습니다.

알아내는 가장 좋은 방법 :

외부 명령 줄 응용 프로그램을 호출하거나 해당 응용 프로그램의 논리를 내부화하는 것이 더 좋은 방법입니까?

스스로 비용을 계산하는 것입니다. 환경, 상황 및 사람에 따라 비용이 달라집니다. 대부분의 경우 명령 행을 호출하는 데 비용이 많이 들지만 분석을 수행 할 수있는 유일한 방법은 아닙니다.

— 다이어트
소스

내 경우에는, 그것은 외부 응용 프로그램 본질적으로 발생하는 오픈 소스와 마찬가지로, 자바로 작성된 것으로 내 응용 프로그램. 불행히도 외부 응용 프로그램이 사용하는 라이브러리 는 없습니다. 라이브러리는 CLI 인터페이스 자체에 단단히 묶여 있기 때문입니다. 그 외에는 모든 좋은 점이 있습니다.

— cdeszaq

1

이상적으로는 통합하고 싶을 것입니다. 특히 이것이 배포되는 앱인 경우 종속성 및 구성 수를 줄이면 더 쉬워집니다. 그러나 물론 특정 사례에 대한 비용 / 혜택 문제입니다.

한 가지 고려해야 할 것은 안정성입니다. 나는 몇 년 전에 비슷한 일을 겪어 클리 프로그램을 유지했습니다. 너무 불안정 하여 충돌이 발생하여 부모 응용 프로그램을 중단하고 싶지 않아 24/7을 실행해야했습니다. 이제 이것은 자바 응용 프로그램은 아니지만 적용 할 수있는 문제가 있다면 그것을 고려하고 싶을 수도 있습니다.

— 그랜드 마스터 B
소스