Лучше ли вызвать внешнее приложение командной строки или усвоить логику этого приложения?

У меня есть «конвейерный» процесс, который по сути просто связывает воедино кучу существующих инструментов для автоматизации рабочего процесса. Для одного из шагов существует существующий инструмент командной строки, который уже делает суть того, что должен сделать этот шаг.

Внешний инструмент CLI основан на Java, как и мой конвейер, поэтому можно было бы интегрировать инструмент непосредственно в шаг конвейера, но инструмент очень сложен и в настоящее время тесно связан с вводом данных из командной строки (что-то вроде 37 опций флага конфигурации).

Вопрос заключается в следующем: лучше ли просто вызывать и вызывать внешний процесс или лучше интегрировать внешний код в мое приложение?

Каковы плюсы / минусы интеграции против вызова внешнего процесса?

Лучше просто вызывать и вызывать внешний процесс, или лучше интегрировать внешний код в мое приложение?

Это гораздо лучше , чтобы интегрировать эти вещи.

Интерфейс командной строки - это просто интерфейс, и особенно ужасный. Это важно, но оно также заполнено причудами и ограничениями, которые не имеют смысла.

Каждый из «существующих инструментов для автоматизации рабочего процесса» должен иметь аккуратный класс, который выполняет реальную работу после анализа параметров командной строки.

В идеале, public static void mainфункция делает две вещи в каждом из этих «существующих инструментов».

1. Он вызывает некоторую опцию командной строки / анализатор аргументов.

2. Он вызывает аккуратный класс, который выполняет настоящую работу. Подумайте о задаче Ant или задаче Maven, которая выполняет реальную работу после того, как Ant или Maven обработали весь анализ и принятие решения.

Когда вы собираетесь интегрировать эти вещи, вы хотите, чтобы аккуратные классы выполняли реальную работу.

Если они не существуют, вам придется переписать все эти инструменты, чтобы создать класс tidy, который выполняет реальную работу, отдельно от всего анализа командной строки.

Для получения инструкций о том, как должны работать эти аккуратные классы, прочитайте Ant (или Maven), чтобы увидеть, как они определяют различные рабочие задачи. Это хорошая ментальная модель для того, чтобы объединить несколько разнородных вещей, не возвращаясь к командной строке.

Я бы сказал, оставь это в покое, если это работает.

Как программист, вы приносите пользу своей организации, решая проблемы с программным обеспечением. Решение большего количества проблем как по качеству, так и по количеству за определенный промежуток времени напрямую связано с вашей ценностью в организации. Трата этого времени на создание кода снижает вашу ценность, так как отнимает у вас решение более важной проблемы.

Однако парой факторов, которые могут снизить затраты времени, будет масштабируемость и наличие каких-либо проблем со стабильностью внешних программ.

Это не «лучше» или «хуже». Есть просто разные затраты и выгоды.

Зачастую написание и обслуживание части программного обеспечения обходится дороже, чем больше точек интеграции приводит к дополнительной сложности.

• Функция, которую вы пишете, имеет очень небольшую стоимость интеграции.
• Сторонняя библиотека имеет немного большую стоимость интеграции.
• Отдельная программа, которую вы должны выполнить, будет иметь еще большую стоимость интеграции.

Обратите внимание, что это затраты на интеграцию, которые вы должны сопоставить с общей стоимостью, которая включает, помимо прочего, стоимость написания и обслуживания программного обеспечения.

Может случиться так, что вы очень неопытный программист, но длительный опытный пользователь.

• Если вы хотите «раскошелиться», ваши общие затраты могут быть низкими, несмотря на более высокие затраты на интеграцию, потому что вы можете снизить стоимость интеграции с помощью своего опыта и знаний.
• Если бы вы сами написали эту функцию, ваша общая стоимость могла бы быть довольно высокой, несмотря на низкую стоимость интеграции из-за вашей неопытности в программировании.

Лучший способ выяснить:

Лучше ли вызвать внешнее приложение командной строки или усвоить логику этого приложения?

Стоит рассчитать затраты для себя. Стоимость будет отличаться для разных сред, ситуаций и людей. Большую часть времени вызов в командную строку будет стоить дороже, но не всегда и единственный способ убедиться, что он выполняет анализ.

В идеале вы хотели бы интегрировать это. Особенно, если это приложение, которое распространяется, - уменьшение количества зависимостей и конфигураций сделает это проще. Но это, конечно, проблема затрат / выгод для вашего конкретного случая.

Тем не менее, одна вещь, чтобы рассмотреть это стабильность. Я столкнулся с чем-то похожим пару лет назад и сохранил программу Cli. Это было слишком нестабильно, и я не хотел, чтобы его сбой приводил к отключению родительского приложения, которое нужно было запускать 24/7. Теперь это не Java-приложение, но, тем не менее, если это проблема, которая может возникнуть, вы можете принять это во внимание.