Имеет смысл переписывать Perl и сценарии оболочки в Java?
Кроме того, другое решение гарантирует, что ваши элементы управления создаются в потоке пользовательского интерфейса, а не потоком рабочего потока, например.
17 ответов
Проблема, Ваша реакция Пищеварительного тракта могла бы быть правильной, но это не означает, что Ваш менеджер обязательно неправ - у него, вероятно, есть очень серьезные основания для желания всего этого сделанного в Java. Не в последнюю очередь при подпадании под шины, находя замену, кто знает Java, жемчуг и удар будут намного более твердыми, чем нахождение кого-то, кто знает Java. И это не принимает во внимание, "они могут только быть выполнены на ПК с cygwin установленная" проблема. И по всей вероятности, производительность не является столь большой проблемой, как Вы думаете, что это.
Однако Ваш лучший выбор состоит в том, чтобы провести немного времени, оценивая время, которое потребуется для портирования их всех на Java, таким образом, он сможет сделать обоснованное решение. И в то время как Вы в нем, оцениваете, сколько времени это взяло бы для портирования сценариев удара на жемчуг , и документируют их. Затем позвольте ему решить. Помните - он не добирается для расходов большинства его времени, кодируя, как Вы делают, таким образом, только справедливо, что он добирается для принятия некоторых решений вместо этого.
, Если он решает возобновить опцию Java, портируйте один из сценариев, а также Вы можете, затем сообщить с этими двумя версиями и, если Вы правы относительно краткости perl/bash сценариев, необходимо смочь получить некоторый пробег от исследования этих двух версий рядом.
РЕДАКТИРОВАНИЕ: MCS, честно говоря, это звучит мне, как будто те сценарии лучше реализованы в жемчуге и/или ударе, а не Java, но это не действительно точка - точка - то, как Вы демонстрируете это своему менеджеру. При обращении к этому Вы обращаетесь к обоим "вопрос" реакции пищеварительного тракта (btw, вот подсказка - начинают называть Ваши реакции пищеварительного тракта "решением, на основе опыта"), и "лучший способ представить мой случай" вопрос.
Теперь, первая вещь, которую необходимо понять, состоит в том, что менеджер (вероятно), не спускается по этому пути только, чтобы взбесить Вас. У него почти наверняка есть подлинные опасения по поводу этих сценариев. Учитывая, что они - вероятно, подлинные проблемы (и нет никакого смысла в движении дальше, если они не - если он составил свой ум, чтобы сделать эту вещь по некоторой политической причине затем, Вы не собираетесь передумать, независимо от того, что, поэтому просто продолжите его и добавьте его к своему CV) из этого следует, что необходимо предоставить ему информацию, которая обращается к его проблемам, если Вы собираетесь добраться где-нибудь. Если можно сделать это затем, Вы - больше, чем на полпути к получению Вашего собственного пути.
Так, каковы его проблемы? На основе Вашего сообщения, и на моем решении и опыте :-) Я сказал бы, что они:
- пригодность для обслуживания
- вот именно, просто пригодность для обслуживания
я также предположил бы, что его проблемы не :
- производительность
я мог бы быть неправ относительно этой последней, конечно; в последнем месте я работал, у нас была проблема производительности SQL Server, чтобы сделать с репликацией, которая повлияла на способность бизнеса обеспечить поддержку клиентов, таким образом, производительность была проблемой, таким образом, мы обратились к ней. Но вообще говоря, производительность не является таким количеством проблемы, как программисты думают. Если он на самом деле сказал Вам, что производительность является проблемой, то фактор это в. Но если он не упомянул это, забудьте это - это - вероятно, только Вы, который думает то, что эти сценарии работают быстрее в perl/bash, чем они, вероятно, будут в вопросах Java вообще.
Так, пригодность для обслуживания. Это сводится к ответу на вопрос, "кто поддержит эти сценарии, если MCS подпадет под шину?" и дополнительный вопрос, "который вызовет меня (т.е. Ваш менеджер) проблемы?" (В стороне: не добирайтесь завис на целой вещи шины. "Подпадание под шины" является полезным и дипломатическим сокращением от всех видов рисков, например, "что происходит, если кто-то переманивает его с зарплатой, моя компания не может соответствовать?", "что происходит, если он решает эмигрировать в Бермуды?", "что происходит, если я хочу уволить его?", "что происходит, если я хочу продвинуть его?", и, конечно, "что происходит, если просто он заделывает превращение для работы однажды для некоторых неизвестных, возможно связанный с шиной, причина?")
Помнят, это - задание Вашего менеджера, чтобы рассмотреть и снизить эти риски.
Так, как сделать это?
Первый, продемонстрируйте, насколько удобный в сопровождении эти сценарии на самом деле. Или по крайней мере насколько удобный в сопровождении они могут быть. Зарегистрируйте их (в надлежащих документах, не в коде). Обучайтесь коллега для поддержания их (выберите кого-то, кто хотел бы получить/улучшить их жемчуг и навыки удара, и кому менеджер доверяет). Осуществите рефакторинг их для создания их более читаемыми (принесение в жертву производительности и умных приемов сценариев при необходимости). Если Вы хотите продолжить использовать удар, создавать документ, который предоставляет пошаговые инструкции для установки cygwin и удара. Независимо, зарегистрируйте процесс установки жемчуга и запущения скриптов.
1115-секундный, выберите один из сценариев и портируйте его на Java. Не стесняйтесь выбирать сценарий, который лучше всего демонстрирует, что преимущества perl/bash по Java, но делают лучшее задание Вы банка портирования его. Использование java.util.regex, чтобы сделать те же умные вещи Вы делаете в своем жемчуге. Зарегистрируйте его к стандарту, что документируются другие внутренние утилиты Java. Если производительность является на самом деле фактором, измерьте его уровень относительно perl/bash сценария.
В-третьих, будучи посредством того осуществления, быть честным с собой об их относительной пригодности для обслуживания. Спросите парня, Вы обучили то, что он думает. Если бы Вы все еще думаете, что perl/bash сценарии более или менее так удобны в сопровождении, как версии Java были бы, оценить работу, вовлеченную в портирование остающихся сценариев к Java так точно, как Вы можете (Вы смочь сделать это довольно точно теперь, потому что Вы на самом деле портируете один). Затем возьмите сравнительные сценарии и документацию и оценки (и числа производительности, если соответствующий) Вашему менеджеру, и пройдите их с ним. Представьте свои встречные предложения (a., оставляют их в жемчуге и ударе, но документируют их и обучают коллегу и b. порт сценарии удара к жемчугу, документируют их и обучают коллегу).
Наконец, позвольте своему менеджеру уравновесить всю информацию и решить и выполнить его решение. На самом деле только выполните его решение, примите то, что он мог бы быть прав. Просто, потому что Вы знаете больше о perl/bash/java, чем он, не означает, что Вы обязательно знаете больше об управлении командой/отделом, чем он. И если его решение состоит в том, чтобы придерживаться perl/bash или порта к жемчугу, радоваться! Поскольку Вы не только получили свой собственный путь, Вы поднялись по оценке своего менеджера и извлекли неоценимый урок по пути.
Для меня это зависит от того, как плохо записанный Perl (я никогда не видел Perl, который, как я сказал бы, был "ХОРОШО" записан), и необходимо ли будет когда-либо ЧИТАТЬ Perl.
Perl является часто Записью Однажды, Чтение Никогда язык. Если бы все это работает, и Вы будете должны вряд ли изменить его, я сказал бы, не касаются его.
моя "реакция пищеварительного тракта", корректная? Java медленнее, более подробный, и тяжелее поддержать для управления базой данных, парсинга электронной таблицы, & задачи обработки файла?
№
кажется, что Ваш менеджер определяет задачу для неправильного человека, чтобы сделать это. Его ясное, что Вы не удобный Java записи и что Вы не должны делать так. Почему не делает одного из разработчиков со "стороны Java", выручают Вас?
Вы рассмотрели Муравья? Я должен признать, что никогда не пробовал, но всегда хотел портировать свои сценарии на Муравья. Операции файла легки и существуют даже задачи создать SQL-операторы. Конечно, если Ваши сценарии больше похожи на программы, т.е. много конструкций цикла, то это не способ пойти. Просто предложение.
Если Вы создаете сарай и используете молоток 80-90% времени, он следует за этим, необходимо ли использовать только молотки для создания сараев? Нет, Вы используете самые соответствующие инструменты для каждой части задания, так же, как Вы сделали!
Также средний уровень навыков/опыта трудовых ресурсов IT увеличился в последние годы. Например, Это ТАК Опрос показало носитель, ТАКИМ ОБРАЗОМ, программист находится в их 30-х с опытом более чем 10 лет.
Вы распоряжаетесь, не будет иметь никакой проблемы при пополнении программистов с широким соединением навыков и опыта.
Просто делают, как Вы сказали: преобразуйте свою оболочку в Perl и зарегистрируйте его
код, который Вы упоминаете, кажется, не часть приложения, это, кажется, код "установки" или код "обслуживания". Как одно уведомление ответа, "одно задание = один инструмент":
- для Вашего приложения, это - Java,
- для упаковки Вашего приложения, это - муравей или знаток, или сделайте,
- для установки среды, заполните дб, делая отчеты из журналов, это - язык сценариев (Perl, Python, оболочка).
Для убеждения босса:
- http://en.wikipedia.org/wiki/Golden_hammer
- мигрирует от одного языка до другого, опасно: необходимо будет потратить партию времени для проверки на ошибки регрессии
- , По моему опыту, одна строка Perl = 20 строк Java (дайте попытку: переместите один из своего сценария Perl). Таким образом, кодовая база будет умножена на 20, и больше кода для поддержания является большим количеством headakes
Perl, поддерживают все его модули и документ в том же месте (cpan.org). Для Java нет никакой "контрольной точки". Необходимо будет напрасно тратить время в сети, чтобы сделать выбор между синтаксическими анализаторами электронной таблицы Java, учиться использовать его (надейтесь, что документ будет в порядке), и сделайте некоторый java-cryptic-glue-code:
SheetHolder = ParserFactory .newInstance (Configuration.asProperties ()) .parse (SheetReader.asStream ());
Всего одна точка. Во многих отношениях у него есть точка, но...
Perl (или сценарии удара) является языком связующего звена. Это - один из лучших языков там для того, чтобы придерживаться систем и заставить их работать лучше. Perl является полностью-интерпретируемым-языком, который предоставляет ему значительное питание для стилей более динамического программирования и run-time-code-rewrite. Можно раздать блоки кода жемчуга как данные и изменить их вплоть до момента, который Вы называете "оценкой" на строке. Существует ли собственная функциональность Java для встраивания жемчуга, можно легко создать такое встраивание себя, делая для очень мощной системы.
Вы могли бы хотеть ясно дать понять к своему супервизору, какой потенциал Вы потеряете при удалении жемчуга. В моем последнем задании два из разработчиков добавили IronPython к нашему "списку поджигательских речей" так, чтобы мы могли реализовать библиотеки и тривиально передать их через базу данных для проекта автоматизации крупного масштаба, который превратился в очень простой, очень крошечный проект с набором склеивания кода Python и быть склеенным к скомпилированным модулям.
, В целом, существуют времена, когда миллион строк Java не может сделать то, что 10 строк сценария Bash делает. Именно тогда Вы хотите использовать его. Остальная часть времени, Ваш босс прав, пока Вы выкроены время, чтобы сделать это.
Они должны быть переписаны? Это зависит. Самый сильный аргумент, что Ваш босс имеет, - то, что остальная часть приложения записана в Java и кажется, что это могло бы быть способом, которым направляется организация. Сокращение количества различных языков, которые должны поддерживаться организацией, является на самом деле довольно умным долгосрочным решением. Я знаю, я знаю, правильный инструмент для правильного задания, но с точки зрения стоимости, совершенно возможно, что это будет стоить организации большего количества денег для найма кого-то, кто знает и Perl и JAVA, чем просто Java. Даже если сценарии красивы, они все еще должны поддерживаться, и это означает, что он должен сохранить по крайней мере одного человека штатным, кто знает, как сделать это. Именно другая вещь он (и организация) должен волноваться о в конце дня.
Преобразуйте в весь Perl
Ваше право думать, что Java Regexp медленнее. Perl Regexp вариант претерпел много изменений, чтобы удостовериться, что это максимально быстро.
Преобразование от BASH до Perl должно оказаться легким выполнить, Perl может легко сделать то, что Вы делаете в BASH.
Путем избавления от эти BASH файлы, можно также избавиться от Cygwin.
В целом я понимаю требование Вашего менеджера минимизировать и стандартизировать на различных языках/платформах, используемых в Вашей среде.
Однако там определенные задачи, для которых язык сценариев намного лучше подходит, чем язык как Java. Если Вы чувствуете, что это имеет место со сценариями, которые Вас просят переписать, возможно, вместо того, чтобы предложить использовать Perl в качестве одноразового языка для этой конкретной задачи, Вы могли предложить принять Perl (или другой язык сценариев, если Вы думаете, что получили бы лучшее закрытие сделки) как "поддерживаемый" язык для сценариев задач.
Тем не менее в зависимости от того, под чем Вы подразумеваете "используемый в сочетании с" (то есть, насколько сильно связанный различные биты), может просто иметь место, что эти задачи имели бы больше смысла, записанного как библиотеки Java быть названным остальной частью приложения.
На основе моего собственного опыта (который включает смешивание Java и Perl в единой системе), я предложил бы следующее:
1) "Java медленнее", не обязательно верно, но также и не релевантен (даже если верный), если дополнительное время выполнения не вмешивается в некоторый строго ограниченный во времени рабочий процесс.
2) Долгосрочная пригодность для обслуживания является законной проблемой. Наличие, например, единственный уровень DAO, который не должен сохраняться на двух языках, может заплатить в долгом пути. Сколько из Вашего кода Java и текущего scriptage должно было бы быть изменено (дважды) для покрытия рефакторинга в базе данных?
3), Если у Вас действительно есть предпочтение нотации более легкого веса, но Ваш менеджер хочет Java, Вы могли пойти на компромисс на библиотеках Java (от предыдущей точки) объединенный с одним из совместимых подобных сценариям языков, который работает на JVM и мог совместно использовать использование стандарта, освобождает Вас запись для, например, доступ к базе данных? Я думаю о чем-то в JRuby-Groovy-Scala-Jython спектре.
Я, конечно, соглашаюсь, что для всех легче, если Вы работаете с рядом инструментов, которые знает большинство из Вас. Однако, так как у Вас есть и Java и код Perl, я предполагаю, что по крайней мере некоторые из Вас знают обоих, и как таковой, я честно не вижу большой проблемы с наличием и Java и код Perl.
, Если бы сценарии Perl работают как ожидалось и могут сохраняться, я не провел бы время, переписывая их в Java. Сценарии намного легче в Perl, чем это находится в Java imo, поэтому если Вы действительно не должны преобразовывать, я не вижу точку. Я предпочел бы проводить часы на что-то, что на самом деле увеличивает стоимость того, что Вы делаете.
Вы говорите, что для сценариев нужен cygwin для выполнения. Я сделал много Perl и на Unix/Linux и на Windows, и если Вы не делаете много определенного материала Unix, мой опыт состоит в том, что сценарии могут легко быть преобразованы для выполнения в соответствии с Windows Perl как ActiveState. Возможно, это могло быть опцией в Вашем случае.
Я думаю, что Ваша первая реакция является правильной. Один аргумент , Если он работает, не 'фиксируйте' его. Другой аргумент - то, что один разработчик может записать почти ту же сумму SLOC независимо от языка, который использовал. Звучит странным, если Вы знаете, как Java является подробным, но думайте о том, как тщательно необходимо разработать код Java для получения того же результата, использующего функции жемчуга как закрытия, динамический сгенерированный код, момент regexps и другой. И теперь когда Java к Perl отношение SLOC к тому же результату является больше, чем 10:1. Каждая строка кода необходимо считать, понять и поддержать. Java быстрее. Да. Java быстрее для некоторых, думает как перемалывание чисел и своего рода обработка текста. Perl быстрее для regexps и некоторой другой обработки текста и обычно далеко намного более продуктивен, чем Java. Perl хуже удобный в сопровождении, если сравнено SLOC, но тем же или лучше, чем Java, если сравнено функцией. Если Perl записан с помощью лучших практик, и сохраните стиль кодирования, чем может разбить Java в пригодности для обслуживания особенно, если используется для коротких сценариев.
Лично я нахожу, что дб, управление файлами тяжелее делает с Java, но может быть легче поддержать, после того как они записаны.
, Но действительно ли это стоит того? Если это работает, не 'фиксируйте' его.
Лично я не забочусь - Если я заставляю работу делать, я обсуждаю за и против со своим менеджером и если она настаивает, я делаю это и заплачен. Обычно она приходит в себя, хотя, и дает мне более важную работу, чтобы сделать.
Это зависит. Я нашел, что обработка текста в Java может взять до 8 или 9 раз объем кода в качестве в Perl. Если бы эти сценарии должны быть тесно интегрированы в приложение затем, я согласился бы с Вашим менеджером, но если там просто фоновые задачи я изучу использование ActiveState на окнах и перезаписи сценариев удара в Perl.
Я вижу то, что Вы говорите, но коротки, и краткий не всегда удобно в сопровождении - иногда подробный, и явный удобно в сопровождении.
кроме того, после того как это - все в Java, у Вас, более вероятно, будет чувство UI/пульта управления, которое могло бы быть улучшением.
, Если Вам действительно нравится чувство языка сценариев, возможно, Вы могли бы противосделать предложение отличный. Это - синтаксис, очень легко для программистов Java взять, и это - 100% совместимого Java (включая расширение классов Java в отличном и т.п.), все же это - язык сценариев - столь же мощный как любой - со всем питанием и отсутствием компиляции, которая подразумевает.
Между прочим, Java обрабатывает прекрасные регулярные выражения.
Также между прочим, Если Вы записали все эти сценарии и являетесь единственным, знакомым с ними, Вы могли бы хотеть начать наводить справки о новом задании. К сожалению это, но просьба, чтобы Вы сделали Ваши "Специальные небольшие приемы" зарегистрированными и удобными в сопровождении, часто является что-то, что они не думают о пока непосредственно перед тем, как временного увольнения.
В прошлом проекте код на Perl был перенесен на Java, что привело к значительному увеличению скорости. В компании работали в основном Java-программисты, а наши инструменты Eclipse, Ant, JUnit и Maven не подходили для разработки на Perl. Я видел Perl-код во многих компаниях, но в большинстве случаев он был предназначен только для временного решения, быстрого исправления, прототипа, демонстрации и т.д.. Имеет смысл переписать, но вы должны рассматривать это в каждом конкретном случае, иногда время или трудовые ресурсы не позволяют это сделать.