Introduzindo uma nova linguagem de programação JVM em um ambiente corporativo estabelecido

Imagine que seu local de trabalho atual é uma loja Java. Há muito conhecimento acumulado sobre a linguagem Java e existe um processo abrangente de construção e implantação para lidar com tudo de maneira ágil e suave.

Um dia, surge um projeto que grita para ser escrito, digamos, em Ruby. Somente os desenvolvedores seniores têm alguma pista sobre Ruby, mas existe uma noção geral de que, como o JRuby existe para a JVM, a infraestrutura existente pode continuar sendo usada e suportada. Além disso, o JRuby poderia mostrar o caminho para uma melhor maneira de implementar os aplicativos atuais com menos código, para que isso representasse uma migração em andamento.

Lembre-se de que o JRuby é apenas um exemplo, também pode ser Clojure ou Groovy ou qualquer outra coisa que seja executada na JVM.

A questão é como você introduziria esse tipo de mudança - se é que o faria?

Isenção de responsabilidade: sou tendencioso enquanto escrevo um livro sobre programação Polyglot na JVM (Shameless Plug !! - The Java-Grounded Java Developer) :)

Em primeiro lugar, você só deve introduzir a alteração onde ela for realmente justificada!

Um bom lugar para começar é considerar a pirâmide da linguagem de programação de Ola Bini. Ola fala sobre idiomas estáveis, dinâmicos e específicos de domínio.

Java é uma linguagem estável (digitada e gerenciada estaticamente) e, por várias razões (posso abordar isso mais tarde, se as pessoas estiverem interessadas) não é a escolha ideal para projetos de camada dinâmica (por exemplo, Rapid Web Development) ou projetos de camada específicos de domínio (por exemplo, modelagem o domínio Padrão de Integração Corporativa). Se você tem um projeto que se encaixa em uma dessas camadas, esse pode ser um bom lugar para começar.

Você também pode considerar a introdução de uma nova linguagem na camada estável para substituir o Java se houver um recurso fundamental que a linguagem alternativa ofereça. Por exemplo, o Scala simplesmente lida com a concorrência de maneira mais segura e natural do que o Java.

Conforme solicitado, um pouco mais sobre isso. WRT Java:

• A recompilação é trabalhosa
• A digitação estática pode ser inflexível e levar a longos tempos de refatoração
• A implantação é um processo pesado
• A sintaxe do Java não é um ajuste natural para a produção de DSLs

Nesse ponto, você pode estar se perguntando: “Que tipo de desafios de programação se encaixam nessas camadas? Qual idioma devo escolher? ”, Lembre-se de que não há uma bala de prata, mas tenho alguns critérios que você pode considerar ao avaliar suas escolhas.

Específico do domínio

• Construção / Integração Contínua / Implantação Contínua
• Dev-ops
• Modelagem de padrões de integração corporativa
• Modelagem de Regras de Negócios

Dinâmico

• Desenvolvimento rápido da Web
• Prototipagem
• Consoles administrativos / de usuário interativos
• Script
• Desenvolvimento Orientado a Testes / Desenvolvimento Orientado a Comportamentos

Estábulo

• Código concorrente
• Contêineres para aplicativos
• Funcionalidade de negócios principal

Comece com um pequeno módulo de baixo risco (lembre-se, essas linguagens da JVM geralmente interagem com o código Java existente lindamente) ou projeto. Deixe claro que este será um protótipo descartável.

Verifique se você investigou o ciclo de vida da programação e os aspectos de ferramentas para esse idioma. Você quer ter certeza de que pode TDD, executar ferramentas de construção e Integração Contínua, ter poderoso suporte a IDE e todos esses outros fatores. Para alguns idiomas, basta aceitar que determinadas ferramentas não existem ou são muito básicas. A força do desenvolvedor e o suporte de ferramentas podem superar a força de um idioma.

Verifique se há uma comunidade vibrante que possa ajudar sua equipe quando ficarem paralisadas. Grupos de usuários locais são ainda melhores para isso.

Certifique-se de que os desenvolvedores recebam o treinamento inicial de idiomas, especialmente se o idioma não for um estilo de OO (a mudança para o Clojure não é trivial).

É sobre isso, eu acho. Pessoalmente, usei Groovy, Scala e Clojure em meu desenvolvimento juntamente com Java para tarefas como processamento XML, criação de sites rápidos e processamento de dados.

Gostaria de acrescentar algumas idéias sobre o tópico levantado com a observação "se houver". De fato, por que alguém deveria introduzir idiomas adicionais para a equipe? É verdade que, se você estiver apenas olhando para um único projeto, o novo idioma poderá se destacar como a ferramenta ideal para a tarefa. Mas se você tiver muitos projetos, poderá acabar com alguns idiomas adicionais ao longo do tempo. Não conheço seus ciclos de manutenção e números de projetos, mas é provável que a equipe precise fornecer bastante experiência em mais idiomas do que antes.

Do ponto de vista comercial, adicionar idiomas significa adicionar complexidade e requisitos de conhecimento à equipe. Isso prolonga os períodos de ajustes vocacionais, torna mais difíceis as substituições de especialistas em sua equipe (ou permanentes) e exige treinamento adicional para os membros da equipe, o que significa lentidão no curto prazo.

A meu ver, uma estratégia para tornar a introdução bem-vinda deve abordar essas questões além de aspectos puramente funcionais. O ganho esperado vale o trabalho extra e as desvantagens como as mencionadas acima? Se isso puder ser provado, as taxas de aceitação podem ser muito maiores. Apontar esses bons investimentos na qualificação dos membros da equipe também pode ajudar.

Eu diria, comece pelas bordas. Exiba o idioma em alguns códigos que não sejam de produção, como scripts de construção, plugins automatizados, execução de relatórios etc. Depois de verem a utilidade e a simplicidade, eles podem estar mais inclinados a permitir projetos em pequena escala e assim por diante.