Problemas (como manutenção) no desenvolvimento com linguagem impopular

Estou desenvolvendo algum aplicativo com clojure (lisp) sozinho na minha equipe. Começa como uma aplicação pequena. Sem problemas. Mas, como possui recursos e amplia a área, está se tornando um programa importante.

Eu me preocupei com manutenção ou algo assim. Ninguém na minha equipe conhece clojure ou lisp nem se interessa por idiomas como eles.

Então, não é errado fazer programação em linguagens impopulares? (para minha diversão?) Devo usar idiomas mais populares? (pelo menos como python)

Eu tenho certeza que se eu deixar o time, - não estou dizendo que vou embora. :) - ninguém iria mantê-lo. Este programa será destruído e alguns serão desenvolvidos com outro idioma.

Estou gostando muito de desenvolver com o Clojure, mas me deparei que isso pode não ser para a minha equipe.

O que você pensa sobre isso? Eu acho que muitos programadores que adoram idiomas impopulares têm se preocupado com questões semelhantes.

Sinto sua dor, eu adoraria fazer mais codificação em programação funcional (Haskell parece tão divertido!). Sinto que acabei de arranhar a superfície porque ainda não a usei em um contexto de negócios.

Eu recomendaria fortemente contra fazê-lo embora . Se você programar apenas em um idioma que você conhece, somente você poderá apoiá-lo. A menos que você queira lidar com todos os problemas de suporte (mesmo quando você tiver outros prazos / prioridades), codifique em um idioma que sua equipe conheça e possa oferecer suporte. O que acontece quando algo quebra enquanto você está de férias? O que acontece se você deseja ser promovido?

Eu recomendo que você convide pelo menos um outro membro da equipe. Mostre a eles alguns recursos interessantes de linguagem. Com duas pessoas a bordo, torna-se viável e você não será carregado com todo o suporte.

Eu tenho certeza que se eu deixar o time, - não estou dizendo que vou embora. :) - ninguém iria mantê-lo.

Possivelmente falso.

Se o programa tem valor e a gerência vê o valor, eles encarregam alguém de aprender e manter o Clojure.

Acontece o tempo todo.

Este programa será destruído e alguns serão desenvolvidos com outro idioma.

Sempre verdade. Então, por que se preocupar com isso?

Todos os programas devem eventualmente ser substituídos.

Estou exatamente no ponto em que você imagina que seu sucessor esteja. Fui encarregado de adicionar recursos a um programa legado que usava Clojure e Erlang para fazer pesquisa assíncrona e transformá-lo em um programa que faz pesquisa assíncrona distribuída. Quando entrei nesse trabalho, tudo que eu sabia era Python e Java.

Meu conselho para você: use a melhor ferramenta para o trabalho . Se essa ferramenta é Clojure, que assim seja. Linguagens de programação não são tão difíceis de aprender. Código bem escrito em um idioma apropriado para a tarefa em questão é sempre mais fácil de ler do que o código que tenta fazer algo que o idioma não foi projetado para fazer. Será mais fácil para o seu sucessor ler Clojure limpo do que Java mutilado.

A adoção de novos idiomas ou o idioma " autônomo " de alguma tarefa é um alto risco em um projeto.

Se essa parte do sistema tiver um problema ou essa parte precisar ser descartada, você deverá encontrar um programador que precise aprender as habilidades sobre esse idioma. Nos dois casos, você perdeu muito tempo.

Em alguns casos, esse problema pode ser usado para melhorar e diversificar as habilidades de uma equipe por tarefas futuras.

O Clojure pode ter uma pequena base instalada no momento (apareceu em 2007), mas não é impopular - na verdade, é possivelmente a nova linguagem "mais quente" do mercado. Eu ficaria surpreso se você não conseguisse encontrar outras pessoas interessadas em aprender.

De qualquer forma, a adoção de um novo idioma deve sempre ser uma decisão com base no valor para os negócios . Você pode discutir com seu gerente ao longo das seguintes linhas:

Vantagens de adotar Clojure:

• Mais produtivo que outros idiomas usados ​​- como evidenciado pela quantidade de funcionalidades úteis que você entregou em um curto período de tempo e com menos linhas de código
• Já temos um aplicativo importante (o seu) escrito no Clojure, por isso vale a pena desenvolver habilidades do Clojure para mantê-lo (em vez de fazer uma reescrita cara)
• O uso do Clojure será visto como inovador e pode ser uma boa maneira de motivar desenvolvedores talentosos a ingressar / permanecer na empresa.

Desvantagens de adotar Clojure

• Um idioma extra para suportar
• Os desenvolvedores podem precisar de mais treinamento e tempo para se atualizar

Se eu fosse um gerente que avaliava essa decisão, provavelmente gostaria da ideia de maior produtividade da Clojure o suficiente para permitir algumas experiências limitadas e adiei a decisão até ficar claro o quão bem a equipe estava lidando com ela. Nesse caso, você provavelmente precisaria ser um advogado, atuar como um bom professor e ajudar a trazer os outros a bordo.

Não se preocupe, seja feliz.

Claramente, o programa tem valor ou você não o estenderia. Parabéns por um projeto bem-sucedido. Presumivelmente, você escolheu o Clojure porque isso economizou tempo e, portanto, economizou o dinheiro do seu empregador. Se você o tivesse escrito em Java, o programa seria, portanto, ainda mais difícil de manter. Mesmo que seus colegas pudessem entender mais facilmente o programa linha por linha, eles poderiam mantê-lo e estendê-lo?

Eu diria mais poder para você! Lisp é o avô das linguagens de computador e ainda é relevante hoje; o fato de não ser tão popular, acho que é devido ao fato de não possuir os IDEs fofos e quentes de C # e Java e a principal implementação do compilador no Windows é executada apenas no Cygwin (yuk!). O desenvolvimento parece ocorrer no Emacs e acho que ele funciona melhor com Linux ou Mac.

Esta competição de codificação foi vencida por um programa Lisp em 2010: http://planetwars.aichallenge.org/

No começo do dia, eles podiam depurá-lo em cerca de 100 milhões de milhas: http://www.flownet.com/gat/jpl-lisp.html

Você definitivamente está renunciando a uma bandeira vermelha de manutenção, mas pense nisso como uma oportunidade de aprendizado para outra pessoa. Se você estava usando alguma linguagem de pesadelo (como MUMPS) ou alguma linguagem tediosa (como TCL), acho que perguntas devem ser feitas. Mas acho que você deve ser considerado um cara tentando defender o melhor das antigas tradições :)

Há muitas boas respostas, mas gostaria de acrescentar um ponto.

Eu estive em situação semelhante, mas com um idioma diferente. Eu tive que aprender tudo da maneira mais difícil, ou seja, através do método de tentativa e erro devido à falta de orientação. O que aprendi com a minha experiência ao apontar manutenção / extensibilidade se tornaria um problema, pois talvez você não conheça abordagens eficazes devido à falta de orientação.

Sugiro que você converse com seu gerente para obter ajuda adequada, para evitar problemas no futuro.

Boa sorte!

Em alguns casos, uma linguagem como o Lisp pode tornar mais rápido ou fácil a implementação de funcionalidades que seriam muito difíceis em um idioma diferente. Também influencia a maneira como você olha para os problemas, dando a você uma perspectiva que outras pessoas da sua equipe podem não ter. Ter uma gama mais ampla de recursos e uma visão mais ampla do que é possível pode ser muito valioso para uma empresa capaz de entendê-los e usá-los. O preço desses recursos, no entanto, é a falta de padronização.

Muitas empresas tentam padronizar um ou dois idiomas porque isso lhes dá mais flexibilidade organizacional: eles podem mover os desenvolvedores de um projeto para outro sem precisar treiná-los novamente, eles têm uma reserva interna de conhecimento sobre os idiomas usados, e os gerentes não precisam considerar os pontos fortes e fracos do uso de um idioma ou de outro para um determinado projeto. Quando tudo que você tem é um martelo, tudo parece um prego.

Como descrevi, ambas as abordagens têm certos benefícios e desvantagens. Como costuma acontecer, não existe uma abordagem certa ou errada. Você está apenas trocando um conjunto de benefícios e desvantagens por outro. Uma empresa também não precisa ir inteiramente em uma direção ou na outra. É perfeitamente razoável fazer a maioria dos trabalhos em C ++ ou Java, mas mergulhe de vez em quando no Lisp ou Python para experimentá-los e ver o que funciona. Parece que pode ser o que sua empresa está fazendo.

Então vá em frente (mas não adiante), aprenda o máximo que puder e torne-se o especialista da Clojure em que seu gerente pode confiar para obter informações que seus colegas talvez não tenham. E não se sinta mal com isso ... se preocupar com o material organizacional é o trabalho de seus gerentes.

Eu recomendaria começar a reescrever seu programa em um idioma diferente (mais conveniente) quando você começar a achar que a manutenção tem grandes chances de ser um problema dominante.

Se você conseguiu escrevê-lo em encerramento (que você não sabia quando começou a criar seu aplicativo, como eu entendi), não haverá problema em reescrevê-lo usando uma linguagem mais familiar / conveniente. O fechamento usa conceitos completamente diferentes e, portanto, pode ser difícil transferir a implementação para outro idioma. Mas o importante é que, se você se divertiu ao escrever um novo aplicativo em encerramento, pode ser interessante transferir conceitos e idéias que você usou para outro idioma conveniente. Pode ser divertido comparar diferentes idiomas e seus recursos. Eu acho que seu caso é perfeito para essas experiências.

Certamente não é errado fazer programação em linguagens "impopulares". Por que você realmente se importa se eles são populares ou não? Concordo plenamente com o @quanticle sobre isso. Se o Clojure ou outro idioma não mainstream for a melhor ferramenta para o problema que você está resolvendo, escolha-o.

Não vejo por que a manutenção será um problema. Se você aplicar Unidade, Integração, etc. Testando e documentando seu código, qualquer programador interessado em programação funcional poderá manter seu programa. IMHO O fato de seus colegas não se importarem com o Clojure não é um bom argumento para não usá-lo, exceto se é uma política da empresa que você precisa respeitar.

Se o programa continua ou não após a sua partida, não lhe diz respeito. Você pode usar a linguagem de programação que você deseja para criar algo que seu chefe goste, me pareça muito bom. Preocupar-se com a continuação é algo que seu chefe deve fazer.

Organize um tutorial ou uma sessão de treinamento. Se os membros de sua equipe não quiserem agir como profissionais e aumentar seus conhecimentos, especialmente se o programa estiver se tornando mais importante, do que isso está fora de suas mãos. Na pior das hipóteses, você pode conversar com a gerência e eles podem exigir esse tipo de sessão de treinamento. Você pode parecer um idiota, mas pelo menos não será o único que precisa manter o programa. A outra opção é sugerir que um segundo programador que conheça clojure seja adicionado à equipe.