Revisões de código elas realmente funcionam no verdadeiro Agile?

Então comecei a trabalhar para uma grande corporação, uma daquelas com três letras no nome, e elas estão tentando se tornar Agile, mas têm muitos processos, que eu não acho que sejam Agile.

O que mais me chamou a atenção são as revisões de código. Meu último trabalho foi em uma startup que eu diria que é a equipe de desenvolvimento mais ágil que eu já vi, participei e / ou já ouvi falar.

De qualquer forma, meu argumento é que as Revisões de Código são uma perda de tempo no desenvolvimento iterativo ou Agile, em que a UX / UI é extrema / intensa (pense na perfeição da Apple / Steve Jobs). Talvez alguém aqui possa ajudar a entender antes de me despedir?

Aqui está o meu processo de desenvolvimento e o da minha última inicialização ... muito ágil.

Fazemos o trabalho inicial de recursos para classificar tarefas de desenvolvimento / todos. Zombamos de algumas versões e apresentamos aos usuários, equipe e marketing para obter feedback. Em seguida, fazemos outra iteração de maquete para obter uma rodada das mesmas partes interessadas acima. Então dividimos o trabalho e começamos. Temos marcos e datas a cumprir, mas continuamos nos afastando. Não temos revisões de código durante nada disso. Várias vezes durante as semanas de nosso desenvolvimento, realizamos sessões com as partes interessadas novamente para verificar se elas ainda concordam que recursos / funções / UX / UI ainda são adequados e estão no alvo.

À medida que nos aproximamos do final do ciclo de iteração de oito semanas, o controle de qualidade começa a ser testado, depois ele é direcionado aos usuários alfa e, finalmente, aos usuários beta. Porém, durante os desenvolvedores alfa e beta, revisamos os novos recursos e os recursos mais antigos, fazendo alterações iterativas diárias ou de hora na interface do usuário para melhorar o UX. Portanto, um recurso que estava sendo desenvolvido nesta versão pode acabar sendo alterado mais três vezes nas últimas quatro semanas para aprimorá-lo e aperfeiçoá-lo ou adicionar alguns recursos minúsculos (por exemplo, tornar o componente um pouco mais inteligente ou mais inteligente). Às vezes, as alterações podem ser superficiais, o que significa que nenhuma operação CRUD é alterada ou modificada, mas todas as UI apenas são alteradas.

Portanto, com esse tipo de processo de desenvolvimento, Agile extremo, as revisões de código não seriam uma perda de tempo? Ou seja, se eu tivesse outro desenvolvedor ou dois revisando meu código, mas esse código for alterado mais três vezes antes de sair pela porta, por causa de todas as melhorias na UI / UX, não estamos perdendo tempo nas primeiras 3 vezes em que o revisaram código como esse código / componente / interface do usuário foi descartado?

Nunca tivemos muitos problemas de qualidade nesse processo e sim, se um desenvolvedor deixasse todo o conhecimento fora da porta, mas sempre encontramos desenvolvedores inteligentes para buscá-lo.

E sim, temos muitos testadores porque eles podem ter que testar novamente as coisas 3 ou 4 vezes. Além disso, não se preocupe em perguntar por que todas as alterações na interface do usuário / UX ... é exatamente assim que as coisas são feitas ... é por isso que o aplicativo ganha muitos prêmios por interface do usuário / UX e os usuários matam pelo aplicativo. O processo de pensamento é se eu posso fazer uma melhoria de até 2% em alguma coisa, porque eu tenho uma hora extra e faço isso. Os usuários ficarão mais felizes, o que significa mais $ ou usuários. E sim, nossos usuários estão bem com o aplicativo mudando continuamente, porque é assim que é feito desde o primeiro dia para que eles não o vejam ruim ou negativo.

Espero que este post não pareça pomposo, mas não consigo ver como as Revisões de Código não são um desperdício. Talvez 2% de todo o nosso código no código revisado tenha erros. Em cada versão, podemos encontrar 3 bugs via revisão de código. Portanto, acaba sendo 40 horas de revisão de código por desenvolvedor por versão (4 x 40 = 160 horas) para encontrar de 3 a 5 erros? As chances são de 50% de que de 3 a 5 bugs teriam sido detectados pelo controle de qualidade de qualquer maneira. Não seria melhor gastar 40 horas por desenvolvedor adicionando um novo recurso ou melhorando os existentes?

Existem algumas coisas que as revisões de código podem fazer por você e outras que não podem. Os argumentos a favor das revisões de código:

• Propriedade coletiva
• Localizar bugs (QC)
• Aplicar estilo consistente (QA)
• Mentoria

Muitos processos ágeis os enfrentam de diferentes maneiras:

• Propriedade coletiva: todos os membros da equipe são responsáveis ​​pelo projeto, o que significa que os olhos de todos estarão no código a qualquer momento.
• Livre para refatorar: isso leva as revisões de código para o próximo nível e permite que qualquer membro da equipe execute a refatoração conforme necessário.
• Testes de unidade (CQ): os testes de unidade são mais eficientes e menos propensos a erros humanos do que à inspeção visual. De fato, ainda não encontrei um meio mais eficiente.
• Programação em pares (QA): cuida da orientação e fornece conselhos de refatoração antecipados à medida que o código é escrito. Esse também ainda é um tópico controverso, mas acho que ajuda ao aumentar um novo desenvolvedor. Também é um bom momento para impor padrões de codificação.

Em essência, existem outras maneiras de cuidar dos ganhos potenciais que você normalmente teria ao fazer análises por pares. Minha experiência pessoal com revisões por pares é que eles são mecanismos muito ineficientes e não são eficazes para encontrar bugs ou falhas maiores de design. No entanto, eles têm seu lugar em algumas equipes e, em projetos em que o ágil não é viável (por qualquer motivo), eles são bastante necessários.

As revisões de código são apenas para encontrar bugs? Você parece pensar que é verdade e eu não.

Eu argumentaria que as revisões de código podem ser mais sobre a propriedade coletiva do código, garantindo que o conhecimento esteja em várias cabeças e preparando outros para herdar o código, que pode ser para novos recursos e também para bugs. Gosto de revisões de código como uma maneira de verificar e equilibrar o sistema, pois você nunca sabe quando alguém pode ter uma idéia de onde algo pode ser reescrito para manter as convenções.

A programação em pares é a resposta do XP para revisões de código. Essencialmente, cada linha de código é revisada à medida que é escrita. São revisões de código levadas ao extremo.

As análises e testes de código geralmente não detectam os mesmos tipos de bugs, e os bugs detectados pela revisão de código provavelmente são mais fáceis de corrigir, pois a localização do bug é conhecida.

Você não pode saber se o código está livre de erros apenas porque passa no teste com nenhum gravado. "Os testes podem apenas provar a presença de bugs, não a ausência." (Dijkstra?)

A revisão de código também mantém o estilo do código igual e é capaz de encontrar locais onde o código não é bom, mas funciona por enquanto. Economiza custos de manutenção no futuro.

Além disso, as demandas de uma grande corporação e de uma startup são diferentes. As startups normalmente falham e precisam se mover rapidamente. As grandes empresas obtêm muito mais valor ao fazer as coisas da maneira certa, do que o mais rápido possível. Você pode preferir trabalhar em startups do que grandes empresas, mas essa não é uma razão para tentar impor estratégias de inicialização onde elas não se encaixam.

Suas revisões de código sempre exibem alterações na interface do usuário / UX? Eu diria que não é uma revisão de código, é um teste de usabilidade. As revisões de código têm muito mais a ver com os problemas que os usuários / testadores / empresas / o que nunca vêem, porque estão no código. A pista está ali no nome.

Agora vou concordar com você que há uma linha a ser traçada em algum lugar. Você revisa 4 iterações da mesma alteração na interface do usuário? Ou você passa por 4 iterações disso, com cada uma potencialmente tornando o código menos sustentável? Eu diria que tente medir as duas abordagens e encontre o equilíbrio certo para sua equipe, mas não abandone completamente as revisões de código.

Mesmo que uma revisão de código nunca seja um problema, você tem um benefício que você raramente nota até que não esteja lá: cada parte do código é analisada por dois desenvolvedores, para que dois desenvolvedores saibam qual foi a mudança e o que ela pretendia alcançar. . Então um deles fica doente no dia seguinte e fica de folga por uma semana, o outro pode pegar qualquer trabalho urgente que estava fazendo.

Costumo concordar que a propriedade e o emparelhamento coletivos de código, juntamente com TDD e CI, são os antídotos ágeis para as sessões formais de revisão de código.

Mesmo na UP / Spiral, eu não era um grande fã de uma etapa específica do processo, sendo "revisão de código", porque me parece que os tipos de problemas que provavelmente encontrarão são encontrados mais tarde do que poderiam ser, se a mesma energia fosse investida em algumas ações iniciais colaboração e alguma automação simples.

Eu senti que, porque havia: - alguma revisão compartilhada do design (geralmente expressa em UML pelo menos em um quadro branco) significava que problemas de design em larga escala ou mau uso de APIs etc. eram capturados antes que muito código fosse escrito. - FxCop, CheckStyle, FindBugs (ou similar) executando junto com compilações de integração contínua automatizada para capturar nomes, estilos, visibilidade, duplicação de código, etc.

Fomos capazes de falhar mais cedo e obter feedback mais rapidamente do que um hábito de revisão de código downstream teria produzido.

Não estou dizendo que é uma perda de tempo sentar e dar uma olhada na sua base de código de vez em quando, mas tornar a revisão de código um passo importante para chamar algo feito parece que cria muito trabalho em andamento que poderia ter sido evitada com melhor inspeção / colaboração a montante.

Um dos principais objetivos que espero das revisões de código é aumentar a facilidade de manutenção do código. As revisões de código devem ajudar todos a escrever códigos claros, razoavelmente compatíveis com os bons padrões de codificação. A maioria dos códigos recebe muita manutenção, especialmente em grandes empresas. O retorno do código de manutenção deve começar antes do lançamento do código e continuar depois.

As análises de código por si só nunca devem resultar em alterações de código. Se a revisão do código indicar que são necessárias alterações, a implementação da alteração resultará em uma alteração no código.

O estado do código pode mudar como resultado da revisão, mas isso deve ser principalmente irrelevante para os problemas mencionados.

Se a revisão de código estiver resultando em várias alterações de código, algo será quebrado no seu processo de desenvolvimento. Dado o número de testadores que você possui, pode ser jogado por cima do muro e permitir que os testadores encontrem a mentalidade do problema.

As coisas devem estar indo para os testadores no estado concluído. O maior número possível de testes deve ser automatizado, para que os testadores não testem novamente as mesmas coisas várias vezes.

A UI / UX exige algum tempo de teste, mas ter especialistas em design / desenvolvimento no front-end deve reduzir isso. Também requer um rosto na frente da tela. No entanto, em todos os aplicativos com os quais trabalhei, era uma parte relativamente pequena do código.

O custo para implementar alterações (incluindo correções de bugs) geralmente aumenta para cada estágio em que passa. Encontrar bugs no desenvolvimento geralmente é mais barato do que corrigi-los após o teste.