Como convencer a administração de que a reformatação de toda a base de código Java está segura

https://stackoverflow.com/questions/2420174

19-09-2019
|

Pergunta

Como se provaria provar a gerência que um reformato em lote de todos os arquivos .java em uma grande base de código (para colocar o código em conformidade com os padrões de codificação da empresa) é seguro e não afetará a funcionalidade.

As respostas teriam que apaziguar o não técnico e o técnico.

Edit: 2010-03-12Esclarecimento para o técnico entre vocês; Reformato = mudanças somente para espaço em branco - Não há "importações de importações" ou "reordenação de variáveis, métodos, etc."

Edit: 2010-03-12 Obrigado pelas inúmeras respostas. Estou surpreso que muitos dos leitores tenham votado pela resposta de Mrjoltcola, pois é simplesmente uma declaração sobre ser paranóica e de forma alguma propõe uma resposta à minha pergunta. Além disso, existe até um comentário do mesmo colaborador que reiterando a questão. WizzardOfodds apoiou esse ponto de vista (mas você pode não ter lido todos os comentários para vê -lo). -jtsampson

Edit: 2010-03-12 Vou postar minha própria resposta em breve, embora a resposta de John Skeet tenha sido certa com o dinheiro com a sugestão do MD5 (nota -g: nenhum para desligar a depuração). Embora apenas tenha cobriu os aspectos técnicos. -jtsampson

2010-03-15 Eu adicionei minha própria resposta abaixo. Em resposta ao que significa "seguro", eu quis dizer que a funcionalidade do código Java não seria afetada. Um estudo simples do compilador Java mostra esse o caso (com algumas advertências). Essas advertências eram "apenas espaço em branco" e foram apontadas por vários pôsteres. No entanto, isso não é algo que você deseja tentar explicar aos Bizops. Meu objetivo era provocar respostas "como justificar fazer esse" e recebi várias respostas excelentes.

Várias pessoas mencionaram o controle de origem e a "diversão" que acompanha isso. Não mencionei especificamente que, como essa situação já está bem compreendida (dentro do meu contexto). Cuidado com o efeito "posto de gasolina". Veja minha resposta abaixo.

Solução

Se estiver apenas reformatando, isso não deve alterar a saída do compilador. Pegue um hash (MD5 deve ser bom o suficiente) da construção antes e depois da reformatação - se for a mesma para cada arquivo, isso significa claramente que ele não pode ter um comportamento alterado. Não há necessidade de executar testes, etc. - Se a saída for byte para byte da mesma forma, é difícil ver como os testes começariam a falhar. (É claro que pode ajudar a executar os testes apenas para o show, mas eles não vão provar nada que os binários idênticos não.)

EDIT: Como apontado nos comentários, os binários contêm números de linha. Certifique -se de compilar com -g:none para omitir informações de depuração. Isso deve ficar bem com mudanças de numeração de linha - mas se você estiver mudando nomes Essa é uma mudança mais séria e que poderia realmente ser uma mudança de ruptura.

Estou assumindo você posso Reformato e reconstrução sem ninguém se importar - apenas verificar o código reformatado de volta ao controle da fonte deve dar qualquer caso por preocupação. Eu não acho Os arquivos da classe java têm qualquer coisa neles que dê uma data de construção, etc. No entanto, se a sua "formatação" mudar a ordem dos campos etc., que isso posso tem um efeito significativo.

Outras dicas

Em um ambiente de negócios, você tem dois desafios.

Técnico
Político

Do ponto de vista técnico, a Reformatters é uma tecnologia madura. Combinado com somas de hash/verificação, desde que o idioma não seja um espaço de branco sensível, você é tecnicamente seguro para fazer isso. Você também deseja ter certeza de que faz isso durante um tempo de inatividade, onde nenhum grande garfos está esperando para serem mesclados. Mudanças reais serão impossíveis de se separar da reformatação, assim como as separadamente. A fusão pode ser muito difícil para quem trabalha em um garfo. Por fim, eu só faria isso depois de implementar a cobertura completa do caso de teste. Por causa da razão 2 ...

Politicamente, se você não sabe convencer a administração, como você sabe que é seguro? Mais especificamente, é seguro para você. Para um desenvolvedor sênior e bem confuso, que está no controle dos processos em uma loja, é um trabalho mais fácil, mas para um desenvolvedor que trabalha em uma organização grande, política e gravada vermelha, você precisa cobrir todos os seus bases.

O argumento que fiz em 2010 foi um pouco inteligente, talvez, mas analisadores, reformas, impressoras bonitas são apenas software; Eles podem ter bugs acionados pela sua base de código, especialmente se isso for C ++. Sem testes de unidade em todos os lugares, com uma base de código grande, talvez você não consiga verificar 100% se o resultado final é idêntico.

Como desenvolvedor, estou paranóico e a ideia me deixa desconfortável, mas desde que você esteja usando:

Fonte de controle
Cobertura de teste adequada

Então você está bem.

No entanto, refletir sobre isso: a gerência agora está ciente de que você está ciente de um projeto de um milhão de linhas com uma "mudança de massa". Um bug anteriormente não descoberto é relatado após o seu reformato. Agora você é o principal suspeito por causar esse bug. Se é "seguro" tem vários significados. Pode não ser seguro para você e seu trabalho.

Isso parece banal, mas há alguns anos, lembro -me de que algo acontece assim. Tivemos um relatório de bugs ocorrendo em um dia após uma janela de manutenção noturna, onde eu apenas fiz uma reconfiguração e reinicialização de um Iis servidor. Por vários dias, a história foi que eu devo ter estragado ou implantado novo código. Ninguém disse isso diretamente, mas recebi a aparência de um vice -presidente que dizia isso. Finalmente, rastreamos um bug que já estava no código, havia sido empurrado anteriormente, mas não apareceu até que uma pessoa de controle de qualidade mudou um caso de teste recentemente, mas, honestamente, algumas pessoas nem se lembram dessa parte; Eles apenas se lembram de vir no dia seguinte a um novo bug.

Editar: em resposta a Edições de Jtsampson. Sua pergunta não era sobre como fazê -lo; Foi "como convencer a administração de que é seguro". Talvez você devesse ter perguntado: "É seguro? Se sim, como fazê -lo, com segurança". Minha declaração estava apontando a ironia da sua pergunta, pois você assumiu que era seguro, sem saber como. Agradeço o lado técnico da reformatação, mas estou apontando que há riscos envolvidos em qualquer coisa não trivial e, a menos que você coloque a pessoa certa, isso pode ser realizado. Essa tarefa prejudicará as outras tarefas dos programadores, desviando -as por alguns dias? Ele entrará em conflito com as revisões não comprometidas de outros codificadores? A fonte está sob revisão? Existe algum script incorporado que seja o espaço em branco sensível, como Pitão? Qualquer coisa pode ter um efeito colateral inesperado; Para o nosso meio ambiente, seria difícil conseguir uma janela de tempo em que não há alguém trabalhando em um ramo, e a reformatação em massa tornará sua fusão bastante feia. Daí minha aversão pela reforma em massa, manualmente ou automatizada.

Use uma abordagem pragmática:

Construir o aplicativo.
Salve o aplicativo.
Reformate o código.
Construir o aplicativo.
Diff os binários.

Eu usaria quatro palavras.

Fonte de controle. Testes de unidade.

Bem, não é nada seguro e é improvável que você os convença. Falando como alguém que conseguiu muito desenvolvimento, eu nunca o consideraria em nenhuma base de código comercial da qual qualquer receita dependia. Não estou dizendo que não há vantagens para codificar formatadas como você gosta, mas as chances de sua formatação não envolverão algumas alterações de código são nulas. Isso significa que há um enorme risco de muito pouco ganho. Se você precisar fazer isso, faça isso aos poucos quando você corrige o código, não faça isso em um grande sucesso. Pode ser uma boa decisão para você como programadores, mas seria uma decisão terrível para eles como gerenciamento.

De que gerenciamento estamos falando aqui? Eles são experientes em tecnologia o suficiente para entender o que é a formatação de código e como o Java trata o espaço em branco? Porque se não forem, não acho que sejam qualificados para tomar uma decisão tão técnica (ou seja, essas perguntas devem ser delegadas a alguém responsável pelo código).

Mas se eles são ou você está tentando convencer seu "arquiteto" ou alguém semelhante, bem, então se trata de confiar em uma ferramenta de terceiros. Sugira um formatador que tenha uma boa reputação, exceto isso, não é muito que você possa fazer, pois você não codificou o formatador.

Como pista lateral, deixe -me compartilhar uma anedota. Nosso arquiteto decidiu em um momento para reformar todos os arquivos. Dos milhares de arquivos Java, nem um único erro foi encontrado (e isso foi há mais de meio ano). Isso me faz confiar no formatador do Eclipse para o código -fonte Java. Os benefícios desta formatação foram:

Algumas classes mal formatadas agora são mais fáceis de ler.
Mesma formatação em todos os lugares.

Mas também tinha alguns lados negativos:

Um formatador de código não é perfeito. Às vezes, o código formatado manualmente é melhor. O formatador, em particular, lutas com código muito ruim (linhas longas, muitos ifs aninhados, etc.).
Você tem outros ramos de código, como uma versão antiga que ocasionalmente precisa ser corrigida? Porque você pode esquecer a fusão entre ramificações com diferentes estilos de código (pelo menos ao usar o SVN).
Você está tocando em todos os arquivos (e às vezes quase todas as linhas) e arruinando o histórico de todos os arquivos de uma só vez. Dói rastreabilidade.
Na verdade, há um pequeno benefício em que cada desenvolvedor tem sua própria formatação de código, porque você começa a aprender essa formatação e pode identificar imediatamente o autor de um pedaço de código

Pessoalmente, acho que o negativo supera o positivo. Parece uma ótima idéia, mas na realidade você não ganha tanto quanto pensa. Quando você se depara com um código terrivelmente formatado, reformate apenas essa classe ou apenas esse método e o vê como um pequeno passo em direção ao grande objetivo.

Seus testes de unidade passam após a reformatação? Nesse caso, você vendeu a ideia para a gerência!

Se você está se metendo com código não testado, terá um estojo muito mais difícil de se apresentar.

Você quer o "Código em conformidade com os padrões de codificação da empresa" sic] e quer convencer a administração?

Trivial: Instale Checkstyle, faça parte do seu processo, alimente -o suas diretrizes de codificação e mostre -lhes que toda a base de código miseravelmente Falha sobre Checkstyle.

Este é um bom exemplo da incompatibilidade técnica de negócios.

As pessoas técnicas querem fazer isso porque pode dificultar o código de leitura, mas a menos que seja excepcionalmente Ruim, a verdadeira razão é que ele ofende as sensibilidades e a estética tipicamente delicadas do programador médio.

As pessoas de negócios querem gerenciar riscos. O risco pode ser feito se houver algum benefício e não houver o negócio benefício aqui, a menos que você argumente que será mais barato, mais rápido e/ou menos arriscado fazer um desenvolvimento futuro com o código -fonte reformatado, que com toda a honestidade é uma venda difícil.

Quase por definição, qualquer alteração tem risco anexado. O risco aqui é remoto, mas também não existe (da perspectiva da administração), quase sem vantagem.

Também há outro problema a considerar: esse tipo de mudança pode causar estragos no controle da fonte. Torna -se mais difícil rastrear quem mudou o que, porque a mudança mais recente em qualquer linha será a reformatação, então você precisará comparar revisões, o que é um pouco mais tedioso do que um simples comando "culpa" ou "anotar".

Além disso, se você tiver várias filiais ativas, um reformato do seu código causará estragos com suas mescladas.

É seguro no sentido de que as alterações puras de formatação não farão diferença no que é compilado e, portanto, não há diferença para o comportamento do código em tempo de execução.

Vale lembrar que a reformatação em massa de código pode levar à "diversão" ao lidar com o controle de origem mais tarde - se vários colegas tiverem o código verificado e um membro da equipe aparecer e reformá -lo, todas essas cópias estão desatualizadas. Pior, quando atualizam suas cópias de trabalho, todos os tipos de conflitos aparecerão, porque essas mudanças de formatação afetarão grandes partes do código e a resolução que pode ser um pesadelo.

Reformatting Code é o mesmo que reformatar um documento no Word; Ele altera o layout e, portanto, a legibilidade, mas não o conteúdo.

Se todos os arquivos forem formatados da mesma forma, o código se tornará mais legível, o que torna a manutenção um pouco mais fácil e, portanto, mais barata. Além disso, as revisões de código podem ser mais rápidas e eficazes.

Além disso, dado um bom estilo de formatação, os bugs podem ser encontrados com mais facilidade, pois não podem se esconder; Pense nas declarações IF sem aparelhos encaracolados e 2 declarações dentro desses aparelhos imaginários.

Seja inteligente e verifique o código e marque -o antes de reformatar, para que você tenha um estado para voltar (e diga às pessoas como seria fácil), reformate e check -in e marque novamente, sem outras alterações.

Responda a essas perguntas para a gerência, e você terá um longo caminho para convencê -las, é uma mudança segura?

Por que a boa formatação é importante?
Que mudanças serão feitas? (Se você não pode responder, não sabe o suficiente sobre a reformatação para saber que será seguro)
Nossos suítes de teste de unidade provarão que as mudanças não tiveram efeitos negativos? (Dica a resposta precisa ser sim)
O código existente será marcado no repositório de origem, para que tenhamos uma opção rápida de recuperação? (sugere a resposta melhor seja sim)

Isso sobre cobre isso.

Na verdade, eu provavelmente estaria do lado deles. As unidades de reformato enquanto você as abre para correções ou aprimoramento quando serão bem testadas antes de voltar à produção. Eles deveriam ter sido formatados corretamente na primeira vez, mas se estiverem em produção, parece desnecessário e imprudente reformatá -los apenas pelo bem de Style.

A consistência é boa, mas "uma consistência tola é o hobgoblin de pequenas mentes".

Estou vestindo meu chapéu de gerente ...

Para fazer isso como um grande projeto, eu não deixaria você fazê -lo, não importa o argumento. No entanto, eu estaria aberto a estimativas mais longas sobre as alterações porque você está modificando os arquivos existentes para incluir essas alterações de formatação. Eu exigiria que você fizesse as alterações de formatação de seu próprio check-in.

Obrigado por todas as suas respostas.

Meu argumento final para convencer a administração; Bits de todas as suas respostas incluídas. Obrigado pela assistência.

Técnico:

Reformato consiste em mudanças no espaço em branco (sem reordenação de importação, sem membro/método)
Reformat usará [especificar ferramentas e processos
Reformatado ocorrerá [especificar tempo dentro do ciclo de codificação para minimizar o impacto da mesclagem

Antes e depois de um reformato:

Todos os testes de unidade passarão
Todos os testes de integração passarão
Todos os testes funcionais passarão
Todos os testes de sabão-UI passarão
O código de byte é o mesmo (um md5 dos arquivos .class seguindo Javac (-g: nenhum))

O negócio:

Objetivo: cumprir os padrões da empresa que prescrevem que nossos arquivos de origem representam com precisão a estrutura lógica do nosso código.

Mudança de reformato vs. Alteração do código (exemplo do documento do Word como acima)
Reformato usará [Processo Geral
Reformatado ocorrerá [especificar tempo dentro do ciclo de negócios para minimizar o impacto

Teste de piloto:

Confirmado "O lote do formato" resultou em menos conflitos de mesclagem e "formato ao codificar". .
Confirmou que o código executável (arquivos 4K+ .Class) permanece o mesmo. (Teste MD5)
A funcionalidade confirmada não será afetada (testes automatizados/testes de fumaça)
As configurações confirmadas do formatador contêm apenas mudanças no espaço em branco.

Observação: No meu caso, um teste piloto foi realizado por mais de 6 meses por um subconjunto dos desenvolvedores usando uma ferramenta automatizada para "formatar conforme você codifica" (conforme prescrito por algumas das respostas acima). Enquanto alguns perceberam que a reformatação causou mais conflitos de mesclagem, esse não era o caso.

Essa percepção foi baseada na coincidência temporal do reformato. Por exemplo, considere a pessoa que não sabe nada sobre carros. Um dia, seus freios falham. A que eles atribuem a causa? O gás, é claro. Foi a última coisa que eles colocaram no carro (o efeito "posto de gasolina"?). Claramente, no entanto, os freios e um sistema de combustível são sistemas díspares, assim como as alterações de formatação e código. Descobrimos que check-ins inadequados no contexto de nosso processo de construção estavam em falta.

A última vez, eu esperava que alguém tivesse fornecido um bom link para um estudo que mostra ganhos de produtividade relacionados ao código comum, pois é difícil mostrar ROI ao negócio. Embora no meu caso, como era um padrão da empresa, eu tinha "conformidade" do meu lado. Eu só tive que mostrar que era mais demorado para "formato ao codificar" vs. "formato de lote"

Se você está usando Eclipse Como sua plataforma de desenvolvimento, você pode carregar todo o código na área de trabalho localmente. Demonstrar à gerência Não há problemas ao mostrar a guia Problemas.

Em seguida, clique com o botão direito do mouse e formate cada um dos projetos um por um - demonstrando novamente nenhum problema é introduzido.

Você pode fazer isso em sua estação de trabalho local sem nenhum dano ao seu repositório.

Honestamente, se o seu gerenciamento não é tão técnico que tenha medo de formatar o código-fonte, demonstrando que nenhum problema aparece na guia Problemas após um formato deve ser suficiente para mostrar que o código ainda está bem.

Sem mencionar que você presumivelmente terá a versão antiga marcada no controle de origem, certo?

Uma escola de pensamento poderia ser fazê -lo sem perguntar e depois poder dizer "ver!"

Claro que se você destruir tudo, será demitido. Você faz suas escolhas ...

Como alternativa, o controle de origem (ou backups simples), então você sempre pode rolá -lo de volta.

Se o seu código tiver quase 100% de cobertura de código suficiente, acho que o risco pode ser reduzido um pouco.

No entanto, mesmo que a administração tenha concordado que a base de código é segura, acho que eles teriam os olhos para justificar o pagamento de um funcionário para passar horas reformatando o código apenas para aderir a um padrão que (presumo) foi introduzido por muito tempo no desenvolvimento ciclo da vida.

Usamos o Jalopy aqui no meu trabalho atual. É um produto bastante sólido e produz uma saída realmente arrumada. O desenvolvedor mais sênior aqui reformatou toda a base de código quando ele a migrou do CVS para o SVN, e ele teve que realizar alguns testes para garantir que funcionasse desde o início ao fim, e agora temos ganchos para garantir que o verificado- no código é formatado corretamente.

Dito isto, não acho que você possa convencer ninguém de que qualquer ferramenta seja tolo (ou falha) à prova, porque não existe essa ferramenta. Se você acha que o benefício vale o tempo e o risco (muito pequeno), tente convencer sua administração a maior vantagem que você vê ao fazer isso. Para mim, a maior vantagem virá se:

Todos os desenvolvedores têm as mesmas configurações de formatação;
A formatação do código-fonte é verificada no check-in por um gancho no seu SCM.

Porque se você fizer o acima, se o seu código já estiver formatado, quando você comparar revisões no seu SCM, verá alterações reais na lógica do programa e não apenas formatando alterações.

Se você tiver uma boa cobertura do teste de unidade, os resultados do teste antes e depois serão suficientes.

Apenas um aviso específico: se a política da sua empresa incluir a classificação alfabética, esteja ciente de que a ordem dos campos estáticos importa. Portanto, se você incluir uma regra de limpeza ou limpeza que faça isso, poderá quebrar seu código.

Tecnicamente, durante a primeira fase da compilação, Lexer tira todos os comentários e o espaço em branco da fonte. Isso é muito antes de qualquer semântica do código estar sendo reconhecida pelo compilador. Portanto, qualquer espaço em branco ou comentários não pode alterar nada na lógica do programa. Pelo contrário, de que uso seria o idioma e quem gostaria de usá -lo se adicionar alguns espaços ou novas linhas mudasse a semântica?

No lado dos negócios, você provavelmente usará algumas ferramentas especializadas para isso. Tenho certeza de que eles anunciam em seus sites que funcionam muito bem.

Nota final: se você precisar convencer sua administração disso, talvez deva encontrar uma maneira de trabalhar com pessoas mais inteligentes?

Eu perguntava à gerência qual é a base atual deles para acreditar que o código funciona - depois demonstrará que a mesma ferramenta (testes, documentação, pequenas vozes ...) funciona exatamente também para o código reformatado. Eu gostaria que a resposta deles fosse "testes" ...

Eu sei que as respostas anteriores estão tudo bem, mas aqui está outra possível: faça um CRC na versão compilada antes e depois de um reformato. Como a compilação ignoraria os espaços, guias, feeds de linha, etc., a versão compilada deve ser idêntica ao original, e isso provaria aos gerentes semi-técnicos que tudo está bem.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow