Conselho / Abordagem para destilar código homogêneo e construir código comum para uma equipe

Eu trabalho para o estado da Califórnia. Nossa equipe de programação, na minha opinião, não é realmente uma 'equipe', pois geralmente trabalhamos sozinhos em projetos ao longo do ciclo de vida completo dos aplicativos / sistemas.

O resultado final é que muitos desenvolvedores estão 'reinventando a roda' ... escrevendo suas próprias camadas de dados, mesmo que a grande maioria de nós trabalhe no mesmo banco de dados Oracle ... escrevendo suas próprias coisas de segurança ... a lista continua em.

Não posso mudar a mentalidade de meus funcionários e não tenho ambições realistas em relação à mudança do processo de nossa equipe ... mas meu objetivo é fazer com que nossa equipe trabalhe um pouco mais, pelo menos para construir um edifício comum peças de bloco que todos nós podemos usar para a funcionalidade clichê.

Os benefícios óbvios são: teste e suporte são muito mais fáceis de manter quando todos os nossos usuários estão familiarizados com uma peça comum, o tempo de produção é menor quando você não está escrevendo o mesmo repositório que alguém já fez e podemos nos concentrar em fornecer melhores soluções para os problemas únicos que nossos aplicativos precisam resolver ... etc.

Estou pregando para o coral, tenho certeza.

O truque é que o Estado não gosta de mudanças, nem seus funcionários. Os gerentes geralmente desconsideram novas idéias simplesmente porque gostam de evitar atritos e preferem continuar como estão.

Existem perguntas semelhantes por aí, mas o que estou procurando é conselhos sobre como qualquer um de vocês pode ter enfrentado uma situação semelhante e qualquer direção para obter um tipo de esforço "de base" que facilitará a abordagem do gerenciamento.

EDIT: Apenas para esclarecer algumas coisas:

• o escopo que estou procurando está na loja de TI da minha agência estadual. Não estou tentando coordenar vários departamentos. Conseguimos tirar as pessoas do volante antes de pedir que elas andassem de moto.

• A segurança não é muito preocupante, a maioria de nossos aplicativos é interna e escrita em Windows Forms distribuído na Citrix (ugh.) E quase todos usam as mesmas tabelas corporativas no Oracle ... muito poucas, se houver, aplicativos que sejam "classificados" para falar. não deve dificultar a colaboração.

• Fui até o ponto de configurar um feed do NuGet, com algumas partes do código compactadas e escrevi alguns repositórios para a Oracle, enviei alguns e-mails, mas recebi pouco feedback. Eu tenho cerca de 1/3 da nossa equipe usando o ReSharper e envio e-mails de vez em quando com dicas ... novamente, sem muitos comentários.

O problema é...

os benefícios óbvios

pode não ser tão óbvio para as pessoas ao seu redor, especialmente se elas não forem desenvolvedores. Eu trabalhei para os governos estaduais e federal, para que eu possa simpatizar com a sua situação. Na minha experiência, você precisa mostrar o dinheiro . Comece igualando as alterações nos números ( por exemplo, métricas ) e depois iguale as métricas ao dinheiro. Sei que isso não é divertido e sei que você também não deveria gostar, mas esse geralmente é o caminho das coisas. Todos os estados estão em uma crise orçamentária e mostrando a eles como podem atender a demandas maiores sem precisar de mais dinheiro, mais atraentes serão suas idéias.

Ao longo do caminho, você pode achar que algo que você quer fazer soa ( ou sente ) melhor, mas os números não o apoiam. Se isso acontecer, você pode estar embarcando em um debate religioso sobre tecnologia que pode realmente perturbar; ou completamente descarrilar; outro progresso que você está fazendo. Nesse caso, desista e vá para a próxima idéia. Volte para aqueles quando todos estiverem mais abertos a mudanças.

Para métricas ... comece com os clássicos, eles funcionam bem na maioria dos casos.

• Horário / horários ( pode incluir o desempenho do sistema )
• Dinheiro ( gasto e economizado )
• Material
• Defeitos ( taxas, gravidade, visibilidade para usuários finais )
• Confiabilidade ( em termos do governo, isso é Ao [disponibilidade operacional] e tempo médio entre falhas do MTBF )

Boa sorte!

Você poderia considerar a parceria com um ou dois de seus colegas de trabalho para ajudar a começar a construir uma estrutura comum? Essa seria minha sugestão para um ponto de partida, pois você precisará de aliados e alguns dos benefícios poderão se revelar depois de algum tempo trabalhando juntos, para que as coisas não fiquem tão isoladas. Talvez seja necessário ter algumas discussões com colegas de trabalho para ver como alguns são receptivos a essas idéias e quais são os primeiros adotantes que você pode usar para tirar isso do papel.

Meu tema principal seria considerar passos de bebê aqui. Pequenas mudanças periodicamente podem funcionar bem.

O primeiro passo será anunciar (entre qualquer pessoa interessada e trabalhando para o mesmo empregador) o que você possui .

Como os escritórios das faculdades, tenha pôsteres ilustrando a arquitetura, a funcionalidade e o design das peças que você possui. Este é o "inventário" ou "ativo" do Estado.

Uma segunda pergunta é se os empregadores têm permissão para ver o código fonte de outras pessoas. Se isso não for permitido, a colaboração será muito difícil (a menos que você possa obter suporte em nível estadual).

Quando se trata de segurança, é provável que o Estado já tenha alguns mandatos de segurança da informação que devem ser cumpridos por todos os projetos. Pode ser um bom ponto de partida para padronização.

Algum tipo de trabalho, esp. "projetos de customização", sempre serão trabalhos solo, porque é aqui que eles pertencem.

Começarei dizendo que sou um grande defensor e defensor do código reutilizável e da definição de blocos de construção legais, bacanas e poderosos que vários desenvolvedores precisam usar. No entanto, eu também apontaria que rolar seus próprios códigos / bibliotecas / estruturas reutilizáveis ​​às vezes pode ser uma faca de dois gumes muito afiada. E algo que você acha que deveria economizar tempo, às vezes pode fazer exatamente o oposto.

Esse foi o padrão que observei no passado: como um desenvolvedor continua trabalhando em um produto / recursos / lançamentos, alguns deles (talvez 10 a 25%) identificarão alguns componentes reutilizáveis ​​ou algumas classes que seriam tolas para continuar escrevendo de novo e de novo. O resto das pessoas, continue copiando / colando e reinventando a roda. Vamos esquecer aqueles, você não é um deles.

Portanto, quando você identifica códigos reutilizáveis, começa a criar sua própria biblioteca pessoal de coisas legais que, com o tempo, tornam sua vida mais fácil. Você pode ter classes de utilitário para ajudá-lo a trabalhar com XMLs, threads, registro ... o nome dele. Eu fiz isso e mostrei a qualquer um que estivesse disposto a ouvir e algumas pessoas aceitaram com prazer o fato de poderem analisar o que precisam de um documento XML com 6 linhas de código. Outras pessoas são definidas à sua maneira e adoram codificar centenas de linhas de MSXML direto.

Minhas descobertas:

1. com o tempo, à medida que sua biblioteca melhora, outras pessoas começarão a usá-la gradualmente.

2. À medida que outras pessoas começam a usá-lo, agora você se torna a pessoa de suporte sempre que há um problema e suspeita que seja seu código. Às vezes, eles encontram um bug no seu código porque usam a API de maneira um pouco diferente da que você usou, às vezes o bug está no código deles porque eles não entenderam como usar a API e às vezes o bug não está relacionado, mas a carga é alta. você porque eles estão convencidos de que, antes de adicionarem sua biblioteca, tudo funcionava.

3. (na verdade, isso foi de um post / blog diferente, mas não foi possível encontrar o link): se você escreveu algum "código reutilizável" e levou três semanas para fazê-lo. Geralmente, você precisa passar mais 3 semanas limpando-o para que outras pessoas possam consumi-lo e fornecendo documentação clara e mais 3 semanas escrevendo extensos testes de unidade e também cobrindo cenários de uso geral, não apenas os cenários de uso. Outras pessoas acharam a mesma coisa, estruturas / bibliotecas exigem três vezes a quantidade de esforço que o desenvolvimento original sozinho.

4. Espero que você não precise enfrentar isso. Parte do meu código se tornou tão reutilizável que as pessoas começaram a usá-lo em uma configuração mais ampla. Então, há cerca de 9 meses, a gerência decidiu dividir nosso produto em 2 diferentes, cada um com seu próprio ciclo de lançamento. O que você acha que aconteceu com essa biblioteca de estrutura / utilitário? Ambos os produtos dependem disso, mas agora você deve ter cuidado com a modificação da biblioteca se estiver desenvolvendo ativamente o produto A enquanto o produto B estiver prestes a ser lançado. Nossa solução foi criar a estrutura em si, produto C, que teria seu próprio ciclo de lançamento independente. Então, aqui estou 9 meses depois e ainda estou sentindo os tremores secundários de todos os problemas de compilação / integração contínua / empacotamento que isso causou.

5. Você pode ser extremamente cuidadoso ao escrever suas classes de utilitários e entender todas as implicações de fazer essa alteração e aquilo. Mas quando outras pessoas começarem a usar seu código, em algum momento elas desejarão modificá-lo. Se houver outros 20 componentes que dependem da sua biblioteca, quando alguém modifica a biblioteca, eles podem potencialmente quebrar outros 19 componentes (suponho que eles tenham feito a alteração para que seu código funcione). À medida que o código se torna mais amplamente usado, fica muito mais caro modificá-lo.

6. Embora eu seja a favor da reutilização, há dias em que, na hora do almoço, começo a desejar para mim mesmo que minha biblioteca de utilidades pessoais permaneça minha biblioteca de utilidades pessoais.

Então, com base na minha experiência, alguns conselhos que posso pensar:

1. Procure bibliotecas externas de terceiros que façam o que você precisa e construa seus aplicativos sobre elas o máximo possível. Cada uma dessas bibliotecas já tem uma equipe de pessoas apoiando-a. Apresente-os a um local global em seu ambiente, onde qualquer pessoa possa chegar até eles.

2. Em vez de pedir a todos que usem suas coisas, aproxime seus colegas de equipe e outros engenheiros individualmente e veja quem tem a mesma mentalidade que você. Tenho certeza de que você encontrará poucas pessoas que compartilham seus valores e poderá iniciar uma equipe principal não oficial que trabalhará em prol de um bem comum.

3. Não sei se este funcionará e / ou é uma boa ideia, mas quero tentar isso em minha própria empresa: Em vez de criar estruturas / bibliotecas que são globais e pertencem / são usadas / usadas por várias pessoas / equipes. Trate todo o seu código como "código aberto interno". Configure um repositório semelhante ao github, em que diferentes pessoas / equipes possam enviar o código da biblioteca / utilitário / auxiliar. Torne o repositório visível para todos, para que, se você escrever algo bom, qualquer um fique livre para pegar seu código e usá-lo. Se eles decidirem fazer uma alteração no seu código, assim como o código-fonte aberto, poderão criar sua própria ramificação, que eles manterão, ou devolver a alteração para voltar ao tronco principal. Se você não confia no trabalho deles ou não concorda com a mudança, já que o projeto ainda é seu, você tem a palavra final se quiser aceitá-lo. Se alguma equipe inicia um projeto e o abandona, mas uma equipe diferente considera útil, eles podem se ramificar em seu próprio repositório e continuar o trabalho. Eu estive pensando em usar o Redmine para fazer algo assim, mas ainda não tive a chance de configurá-lo.