Имеет ли смысл переписывать Perl и shell-скрипты в Java?

Question

У меня есть несколько скриптов - некоторые на Perl, а некоторые на Bash - которые используются для:

• Создание базы данных (таблицы, индексы, ограничения, взгляды)
• Анализ электронных таблиц и загрузка данных в базу данных
• Получение информации о куче файлов и загрузка их в
  базы данных.

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

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

Единственный недостаток сценариев заключается в том, что при запуске в окнах для запуска требуется Cygwin. Поэтому я хотел бы дать встречное предложение, чтобы я переносил все сценарии bash на perl, чтобы они могли работать на окнах без Cygwin, и чтобы я тратил время на организацию и документирование сценариев.

Проблема в том, что ответа типа «внутренняя реакция» будет недостаточно, чтобы убедить моего менеджера. Я пришел из Linux, он из Windows, и у нас есть некоторые классические различия между Linux и Windows в подходах.

Итак, у меня два вопроса:

1. Правильна ли моя "реакция кишечника"? Является ли Java медленнее, более подробным и сложным в обслуживании для управления базами данных, анализа электронных таблиц и задач обработки файлов?
2. Если ответ на первый вопрос положительный, как лучше представить мой случай?

---

РЕДАКТИРОВАТЬ: Спасибо всем за идеи. Я хотел бы сделать одно уточнение: сценарии не являются полноценными приложениями, скрытыми в запутанных сценариях. По большей части это задачи, которые были выполнены вручную, которые я автоматизировал с помощью сценариев, а затем украсил по мере развития требований. И причина, по которой я начал использовать язык сценариев вместо java, заключается в том, что эти задачи были , поэтому намного проще выполнять в сценариях. Например, один скрипт запускает несколько запросов, форматирует результаты и выводит их в файл. Как вы думаете, сколько LOC потребуется, чтобы сделать это в Java?

Answer 1

Просто сделайте, как вы сказали: конвертируйте вашу оболочку в Perl и задокументируйте ее

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

• для вашего приложения, это Java,
• за упаковку вашего приложения, муравей или мавен или марку,
• для настройки среды, заполните базу данных, создавая отчеты из журналов, это язык сценариев (Perl, Python, shell).

Чтобы убедить своего босса:

1. http://en.wikipedia.org/wiki/Golden_hammer
2. переход с одного языка на другой сопряжен с риском: вам придется потратить много времени на проверку ошибок регрессии
3. По моему опыту, одна строка Perl = 20 строк Java (попробуйте: перенести один из ваших сценариев Perl). Таким образом, кодовая база будет умножена на 20, и больше кода для поддержки - это больше головных уборов

4. Perl поддерживает все свои модули и документацию в одном месте (cpan.org). Для Java не существует «контрольной точки». Вам придется тратить время в сети, чтобы сделать выбор между анализаторами электронных таблиц java, научиться использовать его (надеюсь, с документом все будет в порядке) и создать код java-cryptic-glue-code:

   SheetHolder = ParserFactory .newInstance (Configuration.asProperties ()) .parse (SheetReader.asStream ());

Answer 2

Если вы строите сарай и используете молот 80-90% времени, из этого следует, что вы должны использовать только молотки для строительства сараев? Нет, вы используете наиболее подходящие инструменты для каждой части работы, так же, как вы сделали!

Кроме того, средний уровень квалификации / опыта ИТ-персонала вырос в последние годы. Например. Этот опрос SO показал, что программисту среднего класса за 30 с опытом работы более 10 лет.

У вашего босса не возникнет проблем с набором программистов с широким спектром навыков и опыта.

Answer 3

Вы рассматривали муравья? Я должен признать, что никогда не пробовал, но всегда хотел перенести свои скрипты в Ant. Файловые операции просты, и есть даже задачи для создания операторов SQL. Конечно, если ваши сценарии больше похожи на программы, то есть на множество циклических конструкций, то это не тот путь. Просто предложение.

Answer 4

Всего одна точка. Во многих отношениях он имеет смысл, но ...

Perl (или bash-скриптинг) - это клейкий язык. Это один из лучших языков для работы с системами и улучшения их работы. Perl является полностью интерпретируемым языком, который предоставляет ему значительные возможности для перезаписи кода во время выполнения и более динамичных стилей программирования. Вы можете передавать блоки кода Perl как данные и изменять их до момента, когда вы вызовете «eval» в строке. Независимо от того, есть ли встроенная функция Java для встраивания Perl, вы можете легко создать такое встраивание самостоятельно, создавая чрезвычайно мощную систему.

Возможно, вы захотите прояснить своему руководителю, какой потенциал вы потеряете, если удалите perl. На моей последней работе два разработчика добавили IronPython в наш «список допустимых языков», чтобы мы могли реализовывать библиотеки и тривиально передавать их через базу данных для масштабного проекта автоматизации, который превратился в очень простой, очень крошечный проект с кучей склеивания кода Python и приклеивания к скомпилированным модулям.

В общем, бывают случаи, когда миллион строк Java не может сделать то, что делает 10 строк скрипта Bash. Вот когда вы хотите использовать его. В остальное время ваш босс прав, если у вас есть время на это.

Answer 5

В прошлом проекте Perl-код был перенесен на Java, что привело к значительному увеличению скорости. В компании работали в основном Java-программисты, а наши инструменты Eclipse, Ant, JUnit и Maven не подходили для разработки на Perl. Я видел Perl-код во многих компаниях, но большую часть времени он имел в виду только временное решение, быстрое исправление, прототип, демонстрацию и т. Д. Имеет смысл переписать, но вы должны взглянуть на него в каждом конкретном случае иногда время или рабочая сила не позволяют этого.

Answer 6

Помните, что Java - не единственный язык JVM - возможно, что-то вроде Groovy или Jython будет компромиссом, который сделает всех счастливыми.

Answer 7

"Для манипулирования файлами и перемещения объектов вам нужна ОС на вашей стороне"

Будьте внимательны, следуя этому совету, не разбираясь в правильном контексте!

ОС поддерживает API программирования, такие как man (2) и (3) и пользовательские команды man (1).

Наличие сценария Perl, например, для запуска последовательности man (1) не будет работать так быстро как JVM эффективно выдает последовательность man (2) или man (3).

Рассмотрим этот пример:

В компании, к которой я присоединился, я обнаружил, что у них в цикле есть модуль Perl, вызывающий утилиту Java - часть гибридной сборки make / perl / java.

На первый взгляд, казалось бы, разумно читать perl в метаданных и выполнять exec / call в JVM для выполнения тяжелой работы (частная форма слияния файлов в цикле perl).

Издержки (настройка / разборка) этого многопроцессорного подхода были значительными и особенно плохими в ОС Windows.

Проблема перфекта должна быть решена.

Команды решили проблему перфорирования, "повторно" используя Java-программу размещение его в сервлете и создание протокола для отправки команд из perl в сервлет java. Теперь итеративная установка / разборка JVM в цикле была сокращена, и все были довольны, пока не возникли крайние случаи использования, такие как проблемы тайм-аута, когда команда добавляла спящие в микс.

Культура поощряет команды инструментов использовать Perl, а команду сервисов - Java. Лучший подход заменить Perl на Java и устранить все накладные расходы либо был потерян для всех, либо политические силы повлияли на решение rube-goldberg ...

Создание сборки на языке JVM, таком как ANT или Maven, позволяет избежать всего этого.

Опять предупреждаем: -)

Answer 8

Для меня это зависит от того, насколько плохо написан Perl (я никогда не видел Perl, который, я бы сказал, написано «ХОРОШО»), и от того, нужно ли вам когда-либо ЧИТАТЬ Perl.

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

Answer 9

Это сейчас много лет спустя, но я только что перешёл скрипты bash с некоторыми скриптами Perl. Я переписал систему для приложения Java, а также добавил Groovy. Java и Groovy хорошо работают вместе.

• Groovy работает с простым Java-кодом.
• Я могу получить доступ и манипулировать всеми моими java-объектами / структурами / данными в groovy. Я вызываю скрипты groovy, которые манипулируют данными в моей работающей java-программе.
• В groovy есть приятный синтаксис. Я могу легко открыть файл и записать в него одним вкладышем.
• groovy также имеет некоторый короткий синтаксис регулярных выражений.
• Файлы скриптов groovy интерпретируются во время выполнения, поэтому, пока моя java-программа все еще работает, я могу изменить код скрипта groovy, и при следующем вызове файлов он использует новый код.

Answer 10

Правильна ли моя "реакция кишечника"? Ява медленнее, многословнее и труднее поддерживать для управления базами данных, анализ электронных таблиц и обработка файлов задачи?

Нет.

Кажется, ваш менеджер поручает не тому человеку сделать это. Понятно, что вам неудобно писать на Java, и вам не следует этого делать. Почему один из разработчиков со стороны java не поможет вам?