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

Ответ 1

Проблема в том, что ваша реакция Gut может быть правильной, но это не значит, что ваш менеджер обязательно ошибается - у него, вероятно, есть очень веские причины для того, чтобы все это было сделано в java. Не в последнюю очередь, если вы попадаете под автобус, найти замену, кто знает java, perl и bash, будет намного сложнее найти кого-то, кто знает java. И это оставляет в стороне "их можно запустить только на ПК с установленной cygwin". И, по всей вероятности, производительность не такая большая проблема, как вы думаете.

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

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

EDIT: MCS, честно говоря, мне кажется, что эти скрипты лучше реализованы в perl и/или bash, а не в java, но это не совсем так. Как вы это продемонстрируете своему менеджеру. Если вы обращаетесь к этому вопросу, вы обращаетесь к вопросу "реакции кишки" (кстати, здесь подсказка - начните ссылаться на ваши реакции кишки как "суждение, основанное на опыте" ) и вопрос "лучший способ представить мой случай".

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

Итак, в чем его проблемы? Основываясь на вашем сообщении, и по моему мнению и опыту:-) Я бы сказал, что они:

• ремонтопригодность
• что он, просто ремонтопригодность

Я бы также предположил, что его проблемы не:

• производительности

Возможно, я ошибаюсь в этом последнем; в последнем месте, где я работал, у нас была проблема с производительностью SQL Server, связанная с репликацией, которая повлияла на способность бизнеса предоставлять клиентам поддержку, поэтому производительность была проблемой, поэтому мы обратились к ней. Но вообще говоря, производительность не такая уж большая проблема, как думают программисты. Если он на самом деле сказал вам, что производительность является проблемой, а затем учитывайте ее. Но если он не упомянул об этом, забудьте об этом - возможно, только вы думаете, что эти скрипты работают быстрее в perl/ bash, чем они, вероятно, вообще будет в Java.

Итак, ремонтопригодность. Это сводится к ответу на вопрос "кто будет поддерживать эти сценарии, если MCS попадет под автобус?" и дополнительный вопрос "вызовет ли я меня (т.е. вашего менеджера) проблемы?" (Кроме того: не повесить на всю вещь автобуса. "Падение под автобусом" - полезная и дипломатическая стенограмма для всех видов рисков, например "что произойдет, если кто-то соблазнит его зарплатой, которую моя компания не может матч?", "что произойдет, если он решит эмигрировать на Бермудские острова?", "что будет, если я хочу его уволить?", "что произойдет, если я хочу его продвигать?" и, конечно же, "что произойдет, если просто он перестает работать на работу в течение одной неизвестной, возможно связанной с автобусом причины?" )

Помните, что ваша задача менеджера учитывать и смягчать эти риски.

Итак, как это сделать?

Во-первых, продемонстрируйте, насколько реально поддерживаются эти сценарии. Или, по крайней мере, насколько они удобны в обслуживании. Документируйте их (в соответствующих документах, а не в коде). Обучите коллегу поддерживать их (выберите кого-то, кто хотел бы приобрести/улучшить свои навыки perl и bash, и кому доверяет ваш менеджер). Рефакторируйте их, чтобы сделать их более читаемыми (приносящие в жертву производительность и умные приемы скриптинга, если необходимо). Если вы хотите продолжить использование bash, создайте документ, в котором содержатся пошаговые инструкции по установке cygwin и bash. Независимо от того, документируйте процесс установки perl и запустите скрипты.

Во-вторых, выберите один из скриптов и поместите его в java. Не стесняйтесь выбирать script, который лучше всего демонстрирует преимущества perl/bash над java, но выполняет лучшую работу, которую вы можете портировать. Используйте java.util.regex, чтобы сделать то же самое умные вещи, которые вы делаете в своем perl. Документируйте его на стандарте, который документирует другие внутренние утилиты java. Если производительность на самом деле является фактором, измерьте ее производительность относительно perl/ bash script.

В-третьих, пройдя через это упражнение, будьте честны с самим собой относительно их относительной ремонтопригодности. Спросите парня, которого вы обучили тому, что он думает. Если вы все еще считаете, что сценарии perl/ bash более или менее поддерживаются как версии java, оцените работу, связанную с переносом оставшихся скриптов в java так точно, как вы можете (вы сможете сделать это довольно точно теперь, потому что вы действительно портировали один). Затем возьмите сравнительные сценарии и документацию и оценки (и показатели производительности, если это необходимо) вашему менеджеру и пройдите через них вместе с ним. Представьте свои встречные предложения (a) оставьте их в perl и bash, но запишите их и подготовьте коллегу, и b. Запустите скрипты bash, чтобы перенести их, задокументировать их и обучить коллегу).

Наконец, пусть ваш менеджер взвешивает всю информацию и принимает решение, и соблюдает свое решение. На самом деле, не просто соблюдайте его решение, признайте тот факт, что он может быть прав. Просто потому, что вы знаете больше о perl/ bash/java, чем он, не означает, что вы обязательно знаете больше об управлении командой/отделом, чем он. И если его решение - придерживаться perl/bash, или порт для perl, радуйтесь! Поскольку вы не только получили свой собственный путь, вы поднялись в оценке своего менеджера и изучили бесценный урок на этом пути.

Ответ 2

Это зависит. Я обнаружил, что обработка текста на Java может занимать до 8 или 9 раз больше кода, чем в Perl. Если эти скрипты должны быть тесно интегрированы в приложение, я бы согласился с вашим менеджером, но если бы были только фоновые задачи, я бы изучил использование ActiveState в Windows и переписал сценарии bash в Perl.

Ответ 3

Лично я считаю, что управление db, управление файлами сложнее, чем с java, но может быть проще поддерживать их после их написания.

Но стоит ли это? Если это работает, не исправляйте его.

Лично мне все равно - если я получу работу, я делюсь с профессионалами и против моего менеджера, и если она настаивает, я делаю это и получаю оплату. Обычно она приходит в себя, и дает мне более важную работу.

Ответ 4

Я думаю, что ваша первая реакция правильная. Один из аргументов: если он работает, не исправляйте его. Другим аргументом является то, что один разработчик может писать почти такое же количество SLOC независимо от используемого языка. Это звучит странно, если вы знаете, насколько Java многословен, но подумайте о том, как тщательно вы должны разработать свой Java-код, чтобы получить тот же результат, используя функции perl как закрытие, динамический сгенерированный код, мгновенные регулярные выражения и другие. И теперь, когда отношение Java к Perl SLOC к одному результату составляет более 10: 1. Каждая строка кода вы должны читать, понимать и поддерживать. Java быстрее. Да. Java быстрее, поскольку некоторые думают, как хруст числа и некоторая обработка текста. Perl быстрее для регулярных выражений и некоторой другой обработки текста и намного более продуктивен, чем Java в целом. Perl хуже обслуживается, если сравнивать с SLOC, но с той же или лучше, чем Java, если сравнивать по характеристике. Если Perl написан с использованием лучших практик и поддерживает стиль кодирования, чем может бить Java в ремонтопригодности, особенно если используется для коротких скриптов.

Ответ 5

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

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

Вы говорите, что скрипты нуждаются в запуске cygwin. Я сделал много Perl как для Unix/Linux, так и для Windows, и, если вы не делаете много конкретных материалов Unix, мой опыт в том, что скрипты можно легко преобразовать для запуска под Windows Perl, например ActiveState. Возможно, это может быть вариант в вашем случае.

Ответ 6

Из моего собственного опыта (который включает в себя смешение Java и Perl в одной системе), я бы предложил следующее:

1) "Java медленнее" не обязательно является истиной, но также не имеет значения (даже если она истинна), если дополнительное время выполнения не вмешивается в некоторый критический рабочий процесс.

2) Долгосрочная ремонтопригодность является законной проблемой. При наличии, например, один слой DAO, который не должен поддерживаться на двух языках, может окупиться в долгосрочной перспективе. Какую часть вашего кода Java и текущего скрипта нужно будет изменить (дважды), чтобы покрыть рефакторинг в базе данных?

3) Если вы действительно предпочитаете более легкую нотацию, но ваш менеджер хочет Java, можете ли вы скомпрометировать библиотеки Java (с предыдущей точки) в сочетании с одним из взаимодействующих языков сценариев, которые работают на JVM и может поделиться использованием стандартных библиотек, которые вы пишете, например доступ к базе данных? Я думаю о чем-то в спектре JRuby- Groovy - Scala -Jython.

Ответ 7

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

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

Тем не менее, в зависимости от того, что вы подразумеваете под "используемым в сочетании" (то есть, насколько тесно связаны разные биты), может быть просто, что эти задачи станут более понятными, поскольку библиотеки Java будут вызываемый остальной частью приложения.

Ответ 8

Преобразовать во все Perl

Ваше право думать, что Java Regexp работает медленнее. Вариант Perl Regexp претерпел множество изменений, чтобы убедиться, что он как можно быстрее.

Преобразование из BASH в Perl должно быть легко выполнено, Perl может легко выполнить то, что вы делаете в BASH.

Избавляясь от файлов BASH, вы также можете избавиться от Cygwin.

Ответ 9

Должны ли они быть переписаны? Это зависит. Самый сильный аргумент, который имеет ваш босс, заключается в том, что остальная часть приложения написана на Java, и похоже, что это может быть так, как руководит организация. Сокращение числа различных языков, которые должны поддерживаться организацией, на самом деле является довольно умным долгосрочным решением. Я знаю, я знаю, правильный инструмент для правильной работы, но с точки зрения стоимости вполне возможно, что для организации будет больше денег, чтобы нанять кого-то, кто знает как PERL, так и JAVA, чем просто Java. Даже если сценарии прекрасны, их все равно нужно поддерживать, и это означает, что он должен держать по крайней мере одного человека в штате, который знает, как это сделать. Другое дело, что ему (и организации) приходится беспокоиться в конце дня.

Ответ 10

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

Кроме того, как только все это будет на Java, у вас будет больше шансов на улучшение интерфейса пользователя/консоли управления.

Если вам действительно нравится язык сценариев, возможно, вы можете встретить предложение groovy. Этот синтаксис очень прост для программистов Java, и он совместим с 100% Java (включая расширение классов java в groovy и т.п.), Но это язык сценариев - такой же мощный, как любой - со всей властью и отсутствием из компиляции, что подразумевается.

Кстати, Java отлично справляется с регулярными выражениями.

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

Ответ 11

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

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

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

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

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

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

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

Ответ 12

Только одно очко. Во многом у него есть точка, но...

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

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

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

Ответ 13

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

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

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

Ответ 14

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

Ответ 15

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

Ответ 16

"Для управления файлами и перемещения файлов вокруг вы хотите, чтобы ОС на вашей стороне"

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

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

Наличие Perl script, например, привод последовательности людей (1) не будет работать так быстро поскольку JVM эффективно выдает последовательность человека (2) или человека (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, избегает всего этого.

Снова, будьте предупреждены: -)

Ответ 17

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

Ответ 18

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

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

Ответ 19

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

Нет.

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

Ответ 20

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

Perl часто является Write Once, Read Never language. Если все работает, и вам вряд ли понадобится его изменить, я бы сказал, не трогайте его.