Tenho certeza de que você já viu meus comentários e meu outro post, então não vou fingir que realmente sei a resposta. O melhor que posso oferecer é um resumo do que ouvi / li de outras pessoas e acrescente um pouco da minha própria experiência à mistura.
Primeiro, quero dizer que, há pouco tempo, deparei-me com um blog que pertence a um de nossos próprios membros do Programmers SE, Martin Blore e IMO. Este post específico sobre a auto-atualização do TDD é muito preciso. TDD é o último nível mais alto que une tudo, mas sem níveis anteriores, especialmente o maior, princípios e práticas de produção de código claro e legível, será muito difícil, se não impossível, fazer o TDD funcionar.
Na minha empresa, o Agile e o TDD nos foram impostos pela gerência e, a princípio, simplesmente os fizemos porque nos disseram (o que é o oposto do ágil). Tentamos o TDD duas vezes e, embora eu seja um grande defensor do uso de testes automatizados, pessoalmente joguei fora todos os que a equipe deu no último lançamento. Eles eram frágeis, gigantescos, copiavam / colavam o wazoo e crivavam de declarações de sono que os faziam correr muito lenta e imprevisivelmente. Meu conselho para sua equipe: NÃO FAÇA TDD ... ainda.
Não sei qual é a sua situação, porque você mencionou que está na empresa há apenas 6 meses e que é contratado. Seus objetivos de longo prazo para permanecer nesta empresa ou o contrato terminará? Estou perguntando, porque mesmo que você faça algo, pode levar algum tempo para realmente ver os resultados.
Além disso, quando você ingressa em uma equipe, geralmente leva tempo até você obter credibilidade e respeito suficientes da equipe, onde eles (desenvolvedores e gerenciamento) considerariam qualquer coisa que você propusesse. Na minha experiência, ajuda se você apagar alguns incêndios e demonstrar que possui habilidades e conhecimentos dos quais outros podem confiar. Não tenho certeza se 6 meses é suficiente. Com frequência, uma pessoa nova e ambiciosa se junta à equipe e depois faz um post aqui perguntando como eles podem mudar o mundo. A triste realidade é que eles simplesmente não podem.
Então, supondo que você tenha o respeito e a atenção de sua equipe. O que agora?
Primeiro, o gerenciamento e os desenvolvedores precisam estar cientes de que há um problema. A gerência mede os resultados em termos de trabalho entregue. Se eles estão satisfeitos com a quantidade e a qualidade atuais dos recursos, a triste realidade é que eles não vão ouvir. Como outros salientaram, sem o apoio da gerência, será extremamente difícil introduzir qualquer tipo de mudança.
Depois de obter suporte de gerenciamento, o próximo passo é aprofundar e identificar as causas do motivo pelo qual a equipe opera da maneira que funciona. Este próximo tópico é algo que tem sido uma busca pessoal minha há pouco tempo. Até agora, essa foi minha jornada:
- Depois de ter o apoio da gerência. Você pode começar a introduzir muitas práticas / processos ditados centralmente que a MainMa sugeriu em resposta à minha pergunta . Fizemos muitos deles (exceto programação emparelhada) e você definitivamente vê benefícios. As revisões de código ajudaram especialmente a padronizar o estilo, a documentação e também nos permitiram compartilhar conhecimentos / técnicas entre a equipe. Mesmo assim, as revisões de código foram ditadas, a equipe realmente gosta delas e analisamos todas as funcionalidades que foram registradas. No entanto ...
- Você percebe que o código geralmente escrito ainda é muito acoplado, o design é ruim ou completamente inexistente. As análises de código capturam parte disso, mas há muito que você pode reescrever. Por que o design é ruim em primeiro lugar? - Muitos desenvolvedores nunca foram apresentados a boas práticas e nunca foram formalmente ensinados OOD em primeiro lugar. Muitas pessoas "simplesmente codificaram" qualquer tarefa que recebessem.
- Com o suporte da gerência, você pode introduzir mais processos, como discutir o design antes de qualquer codificação. Mas você é apenas uma pessoa e parece que, assim que não presta atenção, a equipe volta ao que sempre fez. Por quê?
- Melhores práticas ou hábitos podem ser introduzidos e ensinados para que você não precise monitorar constantemente? - Acontece que esta parte não é tão fácil.
- Por que outros membros da equipe relutam em aprender e adotar novas práticas e por que eles são tão resistentes ao SOLID ou DRY quando se escreve sobre tanta coisa na literatura moderna de metodologia de software? Com todas as mudanças positivas que tivemos em minha equipe, há duas semanas, tive uma discussão: refatorei duas funções com 15 linhas de código idênticas e o revisor chamou de esforço heróico e desnecessário, porque não há nada errado em copiar / colar apenas 15 linhas. Discordo totalmente de tais opiniões, mas por enquanto decidimos concordar em discordar. - e agora? Agora chegamos ao tópico do meu outro post .
- Como maple_shaft e nikie apontaram em suas respostas (desculpe, MainMa , você obteve o maior número de votos, mas está a 5 passos :) :), você alcançou um estágio em que o "processo" não pode mais ajudar você e ninguém neste fórum pode lhe dizer qual é a "correção". O próximo passo é abordar indivíduos, talvez um a um, talvez em equipe, provavelmente ao mesmo tempo ou conversar com eles. Pergunte a eles, o que funciona e o que não funciona. A única maneira de identificar a causa raiz do que os motiva é agora conversar com eles individualmente e descobrir isso. Como parte dessa etapa, deparei-me recentemente com um problema de equipe completamente diferente, mas acho que a resposta de Joel aqui, que é muito detalhado e perspicaz, também se aplicaria a esse caso. Em resumo, embora usar o gerenciamento como "trela curta" seja uma abordagem possível para praticamente qualquer coisa, precisamos lembrar que estamos lidando com seres humanos, para entender verdadeiramente as motivações que temos que cruzar mais na psicanálise do que pura gerência ou liderança técnica.
- Então agora você está falando com seus colegas de equipe? O que você pergunta a eles? Não tenho certeza sobre esta próxima parte, porque nunca estive aqui. Aqui está um cenário possível: P: Como é que não há SOLID? A: Eu não preciso disso. P: Isso pode ajudar. A: Eu estou bem como está. - de alguma forma, você precisa gerar uma série de sons que deixariam sua boca e levariam o ouvinte a reconhecer que as coisas poderiam ser melhores se derem uma chance ao que você está vendendo. Se você falhar aqui, eles nunca ficarão convencidos de que qualquer que seja o "processo" que os faça fazer, realmente tem algum valor. Por outro lado, se você passar desse ponto, provavelmente descobrirá que não precisa mais do "processo".
- Na IMO, seus colegas de equipe não aprenderão se não virem nada de errado com seus hábitos / práticas atuais. Talvez o próximo passo seja encontrar uma maneira de ilustrar, destacar os problemas e torná-los óbvios. Afinal, não estamos escrevendo código legível, usando os princípios do SOLID / DRY ou mantendo a documentação apenas porque isso nos dá uma sensação calorosa e confusa. Fazemos isso porque produz código de melhor qualidade e, francamente, nos torna mais rápidos. Isso pode ser medido? Talvez seja aí que entram as métricas de software?
- Aqui está uma ideia maluca e eu não tenho idéia se ela realmente funcionaria (pode ser uma prática padrão da indústria ou talvez completamente inválida. Eu inventei isso nas últimas 24 horas), mas estou muito tentada a trazê-la para a mesa assim que o próximo ano começar:
- Contra a opinião de muitos outros , apresente a idéia de Autor / Proprietário para todos os arquivos de origem. Como sugere o Programador Pragmático, isso dará um senso de propriedade e responsabilidade a uma única pessoa que será responsável por um código-fonte. Isso não significa que outras pessoas não podem modificar o código, estamos todos trabalhando em equipe, mas no final do dia, a pessoa que possui o código é responsável por revisar as alterações.
- Crie um gatilho de repositório de origem que monitore todos os check-ins e procure especificamente aqueles que são correções de bugs. Faça um processo para que toda correção de bug tenha um identificador de referência logo na descrição do check-in. Agora escreva um script que analise uma lista de arquivos que foram alterados e retire o "Autor" do bloco de comentários do cabeçalho do arquivo. Crie um banco de dados SQL que rastreie o número de defeitos registrados por arquivo / por projeto / por autor.
- Depois de ter estatísticas suficientes, esperamos que você observe que seu código tem menos defeitos / alterações que alguns dos outros códigos. Esses são dados concretos que você pode usar. Se um único projeto tiver uma taxa de defeitos significativamente acima da média, traga-o como candidato para o próximo esforço de limpeza / refatoração para pagar alguma dívida técnica.
- Se um projeto ou arquivo tiver uma taxa de defeitos significativamente acima da média e tiver um proprietário, converse individualmente com essa pessoa. Pergunte a eles, muito educadamente e sem confronto, o que eles podem fazer para resolver isso. Como eles são os proprietários, eles devem conduzir a mudança, mas oferecer toda e qualquer ajuda do seu lado. Felizmente, o proprietário rastreará muitas das causas de seu próprio código de espaguete e, assim que pedir ajuda, é quando você entra em ação e estabelece algum SOLID.