Разработка Java в магазине Perl: Как правильно выбрать инструмент? - PullRequest
5 голосов
/ 02 октября 2008

Моя группа - магазин Perl в очень разнородной организации. Хотя мы поддерживаем нечетную установку на Java, PHP или Python, мы используем Perl для почти всех наших веб-приложений и задач маршалинга систем / данных. Все наши блоки - Linux, хотя мы также взаимодействуем с системами IIS.

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

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

У кого-нибудь есть подобный опыт? Если у меня есть выбор, какие задачи мы должны начать с применения Java? Какие задачи мы должны настаивать на том, чтобы придерживаться Perl? Есть ли разница? Почему или почему нет?

Ответы [ 8 ]

8 голосов
/ 02 октября 2008

Есть ли конкретная техническая причина для перехода на Java? Есть ли что-то, что вы можете сделать в Java, но не в Perl? Есть ли разница в производительности? Неужели какая-то другая группа / человек все о Java и не хочет изучать Perl?

Мой опыт показывает, что вам следует придерживаться того, что вы знаете. Ваша группа знает Perl очень хорошо. У вас скрежетала доля зубов, и некоторые из вас, вероятно, достигли статуса Uber Perl Guru.

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

4 голосов
/ 02 октября 2008

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

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

Руководству говорят, что Java - единственный способ, или "реальные предприятия используют Java", и поэтому они думают, что им нужно использовать Java. Я знаю, где я работаю, они думают, что Java - единственный язык, и такие вещи, как C #, предназначены только для «тактических» проектов, а не для «стратегических» - что бы это ни значило.

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

3 голосов
/ 02 октября 2008

Управление :-(

Дайте им анализ затрат / выгод от перехода на Java. Объясните, что ВЕСЬ коллектив разработчиков чувствует себя так.

3 голосов
/ 02 октября 2008

Я прошел через это, где я работаю, Это может быть очень болезненным процессом.

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

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

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

3 голосов
/ 02 октября 2008

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

2 голосов
/ 02 октября 2008

Преимущества для Java не в языке как таковом, а в поддержке инфраструктуры вокруг него. Библиотеки классов - это одно, но затем вы смотрите на серверы приложений, инфраструктуру обмена сообщениями, библиотеки с открытым исходным кодом и фреймворки, список можно продолжить.

Итак, выберите область и проведите небольшое исследование. Взгляните на исходные коды, apache, codehaus, java.net и Google. Найдите библиотеки и фреймворки, которые подходят для данной проблемы, и посмотрите, уменьшат ли они ваши затраты на разработку. Посмотрите на Spring, Hibernate и Struts2. Посмотрите на параметры IDE и посмотрите, не сделают ли они вас более продуктивными (лидерами являются Eclipse, NetBeans и IntelliJ IDEA). Слушайте подкасты, такие как Java Posse, чтобы получить идеи, и читайте сайты, такие как Java World, InfoQ и The Server Side.

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

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

Надеюсь, это поможет.

1 голос
/ 02 октября 2008

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

0 голосов
/ 02 октября 2008

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

Вы можете кодировать либо в классе и функциях Java, либо в динамических «скриптах» Perl / Ruby ..., либо в обоих.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...