Como os scripts "descartáveis ​​úteis" devem ser tratados?

Você sabe como é: existe uma pequena tarefa repetitiva para a qual você encontrou uma maneira de automatizar rapidamente 95% do trabalho. Você cria um script, executa-o, corrige manualmente a saída e pronto. É claro que você não confirma o script, pois ele não corresponde aos requisitos de qualidade da empresa (não possui documentação nem testes).

Algum tempo depois, você vê um colega trabalhando em uma tarefa semelhante. Você diz: "Ei! Eu fiz um script para isso. Deixe-me procurar. [Parece] Oh, ele foi armazenado no meu laptop anterior, então eu não o tenho mais. Que pena."

Esses scripts geralmente podem economizar muito tempo e, como líder da equipe, eu gostaria que eles fossem armazenados no controle de versão. No entanto, se eu impor os mesmos padrões rigorosos que o restante da base de código para esses scripts, receio que a maioria dos desenvolvedores os mantenha para si.

A única outra opção que posso encontrar é permitir que os desenvolvedores armazenem os scripts em uma parte especial do controle de versão, na qual não há controle de qualidade (como o GitHub Gists). O risco é que outras pessoas não consigam usar o código porque não conseguem encontrá-lo ou entendê-lo.

Como esse problema poderia ser resolvido? Ou não deveria ser resolvido?

A única outra opção que posso encontrar é permitir que os desenvolvedores armazenem os scripts em uma parte especial do controle de versão, na qual não há controle de qualidade (como o GitHub Gists). O risco é que outras pessoas não consigam usar o código porque não conseguem encontrá-lo ou entendê-lo.

Como esse problema poderia ser resolvido? Ou não deveria ser resolvido?

O problema não pode ser resolvido.

Há uma grande diferença entre compartilhar código pelo boca-a-boca quando você ouve que um colega está enfrentando uma dificuldade específica e compartilhá-lo simplesmente colocando-o em uma biblioteca à qual todos têm acesso.

A diferença é que, no primeiro caso, você está desempenhando o papel de criador e bibliotecário com conhecimento implícito do problema e o código que o possui para resolvê-lo, enquanto no segundo caso, esses papéis não estão presentes.

Seus padrões gerais de código podem ser projetados para eliminar o papel do bibliotecário em sua empresa e garantir que a biblioteca permaneça auto-navegável para todos os interessados.

Com um enorme edifício de código de longa duração (como caracteriza a maioria dos principais produtos de software), tempo e esforço são justificados para preservar a capacidade de várias gerações de trabalhadores de continuar trabalhando com todo o edifício. Nas empresas com alta rotatividade de pessoal, uma "geração" de funcionários pode ser tão pequena quanto a cada ano ou dois.

Mas é claro que atingir esses padrões "sem bibliotecas" custa muito tempo e esforço para quem cria a biblioteca e ainda exige tempo e esforço significativos daqueles que mais tarde vierem a usar e navegar na biblioteca (embora não é o mesmo esforço que recriar todo o edifício do zero, o que já pode ter levado várias gerações).

Por outro lado, a maioria desses scripts rápidos e sujos serão escritos para que as coisas simples sejam feitas rapidamente - talvez de forma única. Não são criações complexas ou robustas.

Você diz que eles "economizam tempo", mas é claro que isso só permanece verdadeiro quando não são gravados no padrão muito mais alto e sem bibliotecas. Eles são os gabaritos pessoais de construção daqueles que os criaram - as alavancas temporárias e os andaimes do esforço humano, não o produto durável final.

Deve ser possível verificá-los no controle de versão, para que o criador tenha um local para armazená-los e preservá-los sistematicamente - mas também deve ficar claro que eles representam produtos sobre os quais o criador ainda supervisiona.

Se você pode ler o código e ver imediatamente o que ele faz, tanto melhor. Mas é a biblioteca pessoal do criador, e eles não estão sendo mantidos no padrão de que outras pessoas devem poder ver o que ele faz sem referência ao criador.

Este não é um "risco" suportado pela equipe, assim como o arranjo de objetos pessoais em sua casa é um "risco" para aqueles que desejam pedir emprestado. Pelo contrário, ter que indexar todo o conteúdo da sua casa, organizá-los de uma maneira definida e fornecer um manual de instruções para cada item, é um risco sério para o seu uso contínuo e eficiente da casa.

Eu sinto sua dor. Eu diria que ter uma parte separada do seu repositório é provavelmente a opção para armazenar esses scripts. No entanto, isso resolve apenas uma parte do problema. Agora você os armazena em algum lugar, mas não é uma boa maneira de seus colegas saberem que eles estão lá.

Na minha experiência como consultor de uma empresa onde os scripts são abundantes e escritos para diferentes clientes e geralmente no local, descobrir o que já está lá é difícil!

Você deve encontrar uma maneira de compartilhar o que criou.

Em nossa empresa, como não somos tão grandes, verificamos coisas como scripts em nosso repositório, mas também enviamos um email para toda a empresa para informar nossos colegas sobre uma nova solução. Dessa forma, pelo menos todos sabem o que já existe e com quem entrar em contato, caso precisem.

Outros já explicaram como e por que garantir que seus scripts 'descartáveis ​​úteis' sejam suficientemente bons para serem repo. Eu só vou me intrometer e dizer que é tão importante garantir que, se não forem bons o suficiente para ir no repo, eles devem ser jogados fora.

Em outras palavras, eles são bons o suficiente para entrar no repositório ou não são e devem ser jogados fora. Se não forem jogados fora, tornam-se um fardo de manutenção não gerenciado e, eventualmente, incontrolável.

Começaria dizendo que, se seus desenvolvedores relutam em contribuir com o código por causa de seus padrões, eles são muito rigorosos ou você deve melhorar a qualidade e a ética de trabalho de seus desenvolvedores. Se esses scripts são pequenos, não deve haver muito esforço extra para colocar alguns comentários. Os desenvolvedores devem escrever código legível por padrão e, se não estiverem, seu problema real estará na sua equipe.

Para responder sua pergunta, você tem algumas opções:

1. Se os scripts forem genéricos o suficiente, você poderá hospedá-los em um repositório separado. Se os scripts forem muito centrados no projeto, isso pode não funcionar.
2. Hospede os scripts no mesmo repositório em um diretório próprio. Por exemplo, na minha empresa, nossos projetos costumam ter um cli/diretório que contém vários scripts de linha de comando, geralmente destinados a serem executados pontualmente para inicializar ambientes, importar determinadas partes de dados e assim por diante.
3. Essa pode ser uma opção ruim, dependendo de quais são suas necessidades, mas se você tiver algum motivo, não poderá confirmar um código que não siga expressamente seus padrões e / ou você terá desenvolvedores que não estão dispostos a escrever scripts se Se você seguir esses padrões, poderá hospedar os arquivos em uma unidade compartilhada ou algo semelhante. Essa pode não ser a melhor solução se você precisar de todos os benefícios do controle de origem - no entanto, pode ser benéfico em algumas circunstâncias (obrigado Doc Brown por esta edição)

Com qualquer uma das duas primeiras opções, você pode optar por aprovar mais padrões de codificação relaxados no outro repositório ou no diretório.

Comece a formalizar seus processos.

Você não fornece muitas pistas sobre o uso desses scripts, mas presumo que você tenha várias tarefas de implantação e manutenção, ou correções de dados comuns que são enviadas aos desenvolvedores, porque são elas com conhecimento suficiente para corrigir coisas?

Você deve tentar se tornar mais profissional sobre isso.

• Anote quais são essas tarefas e as etapas para concluí-las.
• Publique esse documento em algum site interno ou intranet
• Registre com que frequência a tarefa é realizada e quanto tempo leva em um sistema de emissão de bilhetes.
• Automatize as etapas manuais com um programa, mas não pule o controle, o teste, o suporte da fonte etc. Desenvolva uma ferramenta administrativa adequada.
• Tente usar ferramentas de terceiros em vez de desenvolver suas próprias soluções sempre que possível. Facilitará as novas contratações

O objetivo é tornar o processo puramente uma função rotineira que qualquer pessoa pode executar seguindo o documento ou executando a ferramenta.

Em seguida, você pode mudar seus desenvolvedores para os recursos de gravação do seu produto e contratar uma equipe de suporte para lidar com os problemas do dia a dia.

Quase qualquer script pode ter potencial de reutilização de uma maneira ou de outra. Mas esse potencial não será aparente inicialmente - e é exatamente por isso que é considerado descartável na época.

Ofereça à sua equipe a solução de repositórios do Github Gist, sem controle de qualidade, para incentivar seu uso e impedir a perda desse potencial.

Mas também tenha um ou mais repositórios para ferramentas / utilitários compartilhados, com controle de qualidade apropriado em vigor.

Somente quando os scripts armazenados nesse repositório descartável são referenciados, seu potencial de reutilização começa a se desvendar. É aí que a reutilização formalizada deve começar, iniciada por desenvolvedores individuais que reconhecem esse potencial ou por você, se as referências ocorrerem em um contexto de equipe. Isso pode acontecer na primeira referência, ou talvez nas subsequentes (ou seja, quando se confirmar que o potencial de reutilização é maior), dependendo da capacidade da equipe, cronograma, carga, etc.

O risco é que outras pessoas não consigam usar o código porque não conseguem encontrá-lo ou entendê-lo.

A própria referência cuida do findproblema. O autor do script e / ou a pessoa que faz a referência pode ser capaz de ajudar com o understandproblema. Caso contrário - o potencial de reutilização não existe realmente ou o entendimento do código seria apenas parte do esforço / custo formalizado de reutilização.

Uma vez iniciado, o esforço formalizado de reutilização deve aparecer na tela do radar da equipe e o resultado deve acabar no repositório compartilhado de ferramentas / utilitários. É quando os scripts descartáveis ​​equivalentes dos quais a reutilização se originou podem ser excluídos (se o potencial deles estiver esgotado).

Focar especificamente no código mal escrito, mas funcional; existe um argumento muito forte para não colocá-los em um repositório.

Eu tenho uma coleção de trechos na minha pasta pessoal do Dropbox. Ele contém coisas que acho úteis:

• Um exemplo genérico de repositório EF
• Um serializador / desserializador simples
• Um pequeno aplicativo que une dois arquivos CSV e gera um novo arquivo CSV.

Contudo:

• O exemplo da EF não possui uma implementação de unidade de trabalho e contém apenas as opções CRUD mais rudimentares.
• O serializador é baseado no antigo XmlSerializer e é quase impossível trocá-lo por qualquer outra coisa. Ele também tem um enorme problema de referência circular.
• O aplicativo é codificado permanentemente para procurar a.csv e b.csv no diretório do aplicativo e gera um ab.csv codificado no mesmo diretório. Não há verificações se existem arquivos, não há tratamento de referência nula.

Embora eu ainda use esses trechos regularmente quando preciso implementar algo rapidamente, eles não são reutilizáveis ​​ou bem construídos. Há muitas razões pelas quais isso não pode ser colocado no controle de versão da nossa empresa:

• Não é auto-documentado.
• Pouco ou nenhum estilo de codificação que não seja o meu próprio hackstyle.
• Sem manipulação de erros.
• Nem todas as armadilhas são óbvias (por exemplo, as referências circulares no serializador)

Mas a característica mais compartilhada de todos esses trechos:

• Mesmo se eu fosse criar documentação, provavelmente levaria mais tempo para ler e entender do que para criar algo você mesmo!

Esses trechos são bons para eu usar, porque eu pessoalmente me lembro para que eles foram usados, como usá-los e quaisquer armadilhas que encontrei.
Mas se eu desse a outra pessoa acesso a esses trechos, sem que eu esteja presente, eles não vão pensar que esses trechos são de alguma forma úteis.

Os trechos são apenas uma extensão da minha experiência como desenvolvedor. Sem mim, esses trechos são lixo. Uso apenas os trechos porque não consigo lembrar a sintaxe de uma classe inteira até o último caractere. Mas me lembro da intenção e das armadilhas, mesmo muito tempo depois de ter usado o trecho pela última vez.

Pense desta maneira:

A fita adesiva é incrivelmente versátil, pode resolver muitos problemas. No entanto, as coisas que foram resolvidas usando fita adesiva são geralmente consideradas feias. Se a IKEA incluísse fita adesiva em todas as suas embalagens planas, embora possa realmente ajudar algumas pessoas que precisam, também faria uma forte declaração sobre a confiança da IKEA na qualidade dos móveis que eles venderam para você.

Pelo mesmo motivo, as empresas não devem permitir trechos de hackers em seu controle de versão, pois isso questiona a qualidade do produto em geral.