ti-enxame.com

Há algum problema em usar um idioma que não seja compatível com sua empresa para algumas tarefas?

Trabalho para uma empresa que oferece suporte a várias linguagens: COBOL, VB6, C # e Java.
Eu uso essas linguagens para meu trabalho principal, mas muitas vezes me pego codificando alguns programas menores (por exemplo, scripts) em Python porque achei que é a melhor ferramenta para isso tipo de tarefa.

Por exemplo: um analista me deu um arquivo CSV complexo para preencher algumas tabelas de banco de dados, então eu usaria 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 oferece suporte a Python
  2. Eles não são controlados por versão (eu os apoio de outra forma)
  3. Meus colegas de trabalho não conhecem Python

Os analistas até começaram a fazer referência a eles por e-mail ("lançar o script que exporta ..."), então eles 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 próprias pequenas tarefas eles ajudam muito.

Em suma, se eu fosse um vencedor da loteria estar 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.

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

27
systempuntoout

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

No mínimo, os scripts devem ser colocados sob controle de origem "por precaução" - entã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 Python é o caminho a seguir ou aceitar que terá que reescrevê-los em uma linguagem compatível. Se o custo de documentar o scripts e educar seus colegas de trabalho em Python é menor do que reescrever você pode até ganhar o argumento.

42
ChrisF

Não posso dar uma resposta completa sobre o que você deveria 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 (obrigatórios) possam acessar. Mas certifique-se de anotar o fato de que você primeiro escreveu esses scripts para seu propósito próprio, ou seja, para executar uma tarefa que lhe foi atribuída. Em seguida, adicione que você está apenas fazendo check-in desses scripts para permitir que outros tenham a vantagem de usá-los.

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

6
Giel

Já tive problemas semelhantes onde trabalho. Eu ouvi "O que é PHP?" vários anos atrás. Eles não entendem ou se preocupam em aprender nada fora da pilha MS. Se python é a ferramenta certa para o trabalho, eu apenas contaria a meus supervisores sobre ela e estaria pronto para muitas comparações e explicar porque python era a escolha certa. Será frustrante, mas acho que a maioria concordaria python é uma boa escolha para manipulação de texto.

5
Ryan

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

Em segundo lugar, 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, nunca.

Esteja preparado para reações adversas - as pessoas geralmente não gostam de mudanças. Ficar por conta própria, usando tecnologias sem suporte 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 para você) a maneira de automatizar essas tarefas para todos usar.

Eu acho que este é provavelmente um bom caso de

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

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

5
Thomas Owens

Minha regra prática é:

Qualquer coisa que potencialmente afete o trabalho de outras pessoas deve ser discutida com seus colegas e superiores o mais rápido possível.

Mas, se for para você e apenas você, desde que não cause nenhum dano à infraestrutura ou segurança de sua empresa, você é livre para fazer o que quiser para concluir o trabalho.

3
Vector

Se você recebe uma tarefa, e é a única maneira de realizá-la a tempo, você realmente não tem escolha. Acho que é sensato deixar os responsáveis ​​saberem o que você está fazendo. Você não deve sair do controle de origem requerido (a menos que ele simplesmente não funcione?) Testes e documentação.

Às vezes, uma empresa pode ter que permitir que um único desenvolvedor comece a procurar uma nova área de desenvolvimento. Infelizmente, o código pode entrar em produção mais rápido do que qualquer outra pessoa.

2
JeffO

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 de requisitos de treinamento e habilidades de suporte).

A segunda opção ajudaria em seu conjunto de habilidades, e você poderia encontrar terceiros (e provavelmente código aberto com licenças comercialmente amigáveis) para fazer parte do trabalho árduo. Por exemplo. uma pesquisa por "LINQ to CSV" deve obter alguns resultados úteis.

BTW, as ferramentas de desenvolvedor do VB6 (IDE, compilador) não são suportadas (nem mesmo correções de segurança), então é provável que o padrão precise ser atualizado de qualquer maneira. (O tempo de execução VB6 é compatível com - e incluído na instalação - das versões atuais do Windows). Isso talvez pudesse ser usado como um auxiliar para a abordagem nº 1: o conjunto de ferramentas padrão precisa aumentar um alvo móvel por causa das dependências do fornecedor.

2
Richard

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

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

Eventualmente, eles reconhecerão a importância de ter tais ferramentas, não importa em qual idioma elas estejam escritas, e começarão a implementar em seu ambiente de trabalho.

1
Jose Faeti

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

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

Então algo atinge o ventilador em todo o pipeline e você passa - WTH IS DAT KODEZ? Especialmente em Perl ... E depurar um problema simples, digamos, de codificação, se transforma em uma bagunça de pesadelo. Você não pode depurar 5 de 7 linguagens com eficácia, e isso se torna uma verdadeira dor.

Ou você tem que adicionar uma mudança simples, mas você cria 10 erros porque Perl tem pegadas, Java tem pegadas, etc.

E essa cadeia de idiomas 7 + começa um passo de cada vez.

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

1
Coder

Quando você é instruído a escrever código fazendo sth., A linguagem geralmente é especificada ou implícita (a regra em corporações).

Mas quando você tem que fazer alguma tarefa única, como importar dados para o DB, você é livre para escolher a ferramenta que em sua opinião se encaixa melhor, porque você tem que 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 fazer 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 realizando alguma tarefa, como importar alguns dados, eu discutirei qual linguagem/ferramenta usar com o gerente (com exceção quando eu uso uma linguagem que é padrão implícito, por exemplo, quando a empresa usa [quase ] apenas Java).

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

1
Danubian Sailor

Suponho que você não esteja em posição de decidir (do contrário, não faria a pergunta). O que seu chefe pensa sobre esse assunto? Você deve falar com ele e tentar convencê-lo de que Python é o caminho a seguir ...

Claro, a questão é sobre o que acontecerá quando você partir. Não ser capaz de manter o código é provavelmente uma razão boa o suficiente para parar de usar Python. Ou você pode começar a educar seus colegas neste idioma ...

0
Xavier Nodet