Tudo bem usar um idioma que não é suportado pela sua empresa para algumas tarefas?

Eu trabalho para uma empresa que suporta várias linguagens: COBOL, VB6, C # e Java.
Eu uso essas linguagens para o meu trabalho principal, mas geralmente codifico alguns programas menores (por exemplo, scripts) em Python, porque achei a melhor ferramenta para esse tipo de tarefa.

Por exemplo: Um analista me fornece um arquivo CSV complexo para preencher algumas tabelas de banco de dados; portanto, eu usaria o Python para analisá-lo e criar um script de banco de dados.

Qual é o problema?
O principal problema que vejo é que algumas partes desses scripts rápidos e sujos estão lentamente ganhando importância e:

1. Minha empresa não suporta Python
2. Eles não são controlados por versão (eu os apoio de outra maneira)
3. Meus colegas de trabalho não conhecem Python

Os analistas começaram a fazer referência a eles por e-mail ("iniciam o script que exporta ..."), portanto são necessários com mais frequência do que eu pensava inicialmente.

Devo acrescentar que esses scripts são apenas utilitários que não fazem parte do projeto principal; eles simplesmente ajudam a realizar tarefas triviais em menos tempo. Para minhas pequenas tarefas, elas ajudam muito.

Em resumo, se eu fosse o vencedor da loteria em um acidente , meus colegas de trabalho precisariam manter o projeto vivo sem esses scripts; eles gastariam mais tempo corrigindo erros de CSV manualmente, por exemplo.

Esse é um cenário comum? Estou fazendo algo errado? O que devo fazer?

Você precisa formalizar a situação, pois não deveria ter chegado a esse ponto. No entanto, essas coisas acontecem, então você precisa explicar ao seu chefe que criou esses scripts para uso pessoal, mas eles "escaparam" a uma circulação mais ampla. Admita (se necessário) que você estava culpado por não trazer isso à atenção dele mais cedo.

No mínimo, os scripts devem ser colocados sob controle de origem "apenas por precaução" - pelo menos se você não estiver disponível (por qualquer motivo), seus colegas de trabalho terão acesso aos scripts.

Então, você precisa convencer seu chefe de que o Python é o caminho a seguir ou aceitar que você precisará reescrevê-los em um idioma suportado. Se o custo de documentar os scripts e educar seus colegas de trabalho em Python for menor que o da reescrita, você pode até ganhar o argumento.

Não posso lhe dar uma resposta completa sobre o que você deve fazer. Só posso dar uma sugestão que você pode usar para começar:

Verifique os scripts em um repositório que todos os desenvolvedores (necessários) possam acessar. Mas certifique-se de anotar o fato de que você primeiro escreveu esses scripts para seu próprio objetivo, ou seja, para executar uma tarefa que lhe foi dada. Em seguida, adicione que você está apenas verificando esses scripts para permitir que outras pessoas os usem.

Depois disso, você só precisa ver como as outras pessoas respondem a isso.

Encontrei problemas semelhantes nos quais trabalho. Ouvi "O que é PHP?" vários anos atrás. Eles não entendem ou não querem aprender nada fora da pilha do MS. Se o python é a ferramenta certa para o trabalho, eu apenas falo para meus supervisores e estou pronto para muitas comparações e explicações sobre por que o python foi a escolha certa. Será frustrante, mas acho que a maioria concorda que python é uma boa opção para manipulação de texto.

A primeira coisa que você precisa fazer é conversar com a equipe e seu chefe. No momento, você tem um enorme fator de caminhão (se você fosse atropelado por um caminhão, ninguém mais seria capaz de manter seus scripts). Parece que ter scripts para executar essas tarefas é importante, mas também é importante que qualquer pessoa que precise editar e manter esses scripts. Você precisa explicar como o uso do Python agrega valor - como economiza tempo, esforço, recursos, dinheiro e assim por diante.

Segundo, coloque-o no controle de versão do projeto. Agora. Nada do que você produz para um projeto deve estar fora do controle de versão desse projeto.

Esteja preparado para a reação - as pessoas geralmente não gostam de mudanças. Fugir por conta própria, usar tecnologias não suportadas e desconhecidas (para a equipe / organização) foi uma má ideia, sem consultar pelo menos os outros desenvolvedores e determinar a melhor (para o projeto, não apenas você) a maneira de automatizar essas tarefas para todos usar.

Eu acho que esse é provavelmente um bom caso de

É mais fácil pedir perdão do que obter permissão.

Parece que você fez o trabalho, mas terá que lidar com as repercussões agora.

Minha regra geral é:

Tudo o que potencialmente afeta o trabalho de outras pessoas deve ser discutido com seus colegas e superiores o mais rápido possível.

Mas, se for para você e você, contanto que não cause nenhum dano à infraestrutura ou à segurança da sua empresa , você pode fazer o que quiser para realizar o trabalho.

Você tem duas opções:

1. Faça disso um padrão
2. Traduzir para uma ferramenta padrão

Dependendo da organização, o número 1 pode ser desafiador (afinal, limitar a lista de tecnologias padrão evita uma explosão combinatória dos requisitos de treinamento e habilidades de suporte).

A segunda opção ajudaria o seu conjunto de habilidades, e você poderá encontrar terceiros (e provavelmente código-fonte aberto com licenças comerciais) para fazer parte do trabalho árduo. Por exemplo, uma pesquisa por "LINQ to CSV" deve receber alguns hits úteis.

BTW, as ferramentas de desenvolvedor do VB6 (IDE, compilador) não são suportadas (nem mesmo as correções de segurança), portanto é provável que o padrão precise ser atualizado de qualquer maneira. (O tempo de execução do VB6 é suportado como parte - e incluído na instalação - das versões atuais do Windows). Talvez isso possa ser usado como um auxiliar na abordagem nº 1: o conjunto de ferramentas padrão precisa atingir um alvo em movimento devido às dependências do fornecedor.

Se você recebe uma tarefa e é a única maneira de realizá-la no prazo, você realmente não tem escolha. Eu acho que é sensato deixar os responsáveis ​​saberem o que você está fazendo. Você não deve sair do controle de origem necessário (a menos que absolutamente não funcione?) Teste e documentação.

Às vezes, uma empresa pode ter que deixar um único desenvolvedor começar a procurar uma nova área de desenvolvimento. Infelizmente, o código pode chegar à produção mais rapidamente do que qualquer outra pessoa.

Bem, eu tenho que admitir que trabalhar com 20 idiomas diferentes cheira mal, MUITO.

Você tem um script Bash que chama script Python que chama script Perl que chama Java binário que chama C dll ...

Então, algo atinge o ventilador em todo o pipeline e você passa por - O QUE É DAT KODEZ? Especialmente em Perl ... E a depuração simples, digamos, do problema de codificação, se transforma em uma confusão de pesadelo. Você não pode depurar 5 de 7 idiomas de maneira eficaz, e isso se torna uma verdadeira dor de cabeça.

Ou você precisa adicionar uma alteração simples, mas cria 10 erros porque o Perl tem dicas, Java tem dicas etc.

E essa cadeia de mais de 7 idiomas inicia um passo de cada vez.

Pise com cuidado, aqui estão dragões ...

Se essas são as ferramentas que você usa para si mesmo, você é livre para fazer qualquer coisa que o torne mais produtivo.

Na verdade, você deve ser incentivado a criar e usar essas ferramentas, que acabarão se tornando uma extensão de seus braços.

Eventualmente, eles reconhecerão a importância de ter essas ferramentas, independentemente do idioma em que foram escritos , e começarão a implementar em seu ambiente de trabalho.

Quando você é instruído a escrever código executando sth., O idioma geralmente é especificado ou implícito (a regra nas empresas).

Mas quando você precisa executar uma tarefa única, como importar dados para o DB, pode escolher a ferramenta que, na sua opinião, se encaixa melhor, porque é necessário fazer algo correto e rápido, e o resultado é importante, não as ferramentas.

Então, eu usaria essa regra:

1) Se você for solicitado a executar alguma tarefa, como importação de dados, eu usaria as ferramentas / idioma / etc. isso seria o mais conveniente para mim e o mais rápido para a tarefa.

2) Se você for instruído a escrever uma ferramenta para executar alguma tarefa, como importar alguns dados, eu discutirei qual idioma / ferramenta usar com o gerente (com exceção quando eu uso uma linguagem implícita no padrão, por exemplo, quando a empresa usa [quase ] apenas Java).

3) Se a tarefa parecia única, mas se tornava repetível, você deve conversar com o gerente para alterá-la de 1) para 2) e reescrever do seu idioma preferido para o suportado pela empresa.

Suponho que você não esteja em posição de decidir (ou então não faria a pergunta). O que seu chefe pensa sobre esse problema? Você deve conversar com ele e tentar convencê-lo de que o Python é o caminho a seguir ...

Obviamente, a questão é sobre o que acontecerá quando você sair. Não conseguir manter o código é provavelmente um motivo bom o suficiente para parar de usar o Python. Ou você pode começar a educar seus colegas para esse idioma ...