Os padrões / estilo de codificação devem ser aplicados pelo servidor de integração contínua executando ferramentas de análise estática (por exemplo, PMD, StyleCop / FxCop) e falhando na construção se os padrões não forem seguidos? Quais tipos de regras não devem ser usados para falhar na compilação?
Respostas:
Os padrões de codificação devem estar lá por um motivo ... e a não conformidade deve ser verificada.
No entanto, nem todas as violações devem ser consideradas como erros - assim como nem todas as violações de compilação. Onde você desenha a linha deve ser uma empresa e uma decisão da ferramenta.
Por exemplo, o MISRA define suas regras como Necessário e Consultivo ... Eu sugeriria que os Avisos permitissem que a construção continuasse.
Não é totalmente inédito e você saberá se funcionará para você apenas experimentando. Existem algumas etapas que você pode tomar antes disso.
Primeiro, a equipe deve decidir sobre os padrões juntos. Em seguida, ferramentas como ReSharper devem ser usadas para informar aos desenvolvedores se eles não estão aderindo aos padrões. Fazer revisões por pares em todas as tarefas pode ajudar ainda mais.
Após essas etapas, pode-se considerar colocar verificações padrão de codificação no servidor de CI. No entanto, ainda deve ser considerado se é sensato ter uma quebra de compilação por não aderir aos padrões de codificação. O risco é que você tenha muitas construções quebradas, o que pode reduzir o significado de construção quebrada.
Em vez de interromper a construção, você pode executar as ferramentas e fazê-las criar relatórios. Se as violações padrão da codificação parecem estar aumentando, você pode reunir a equipe e descobrir por que isso está acontecendo.
Os padrões / estilo de codificação devem ser aplicados pelo servidor de integração contínua executando ferramentas de análise estática (por exemplo, PMD, StyleCop / FxCop) e falhando na construção se os padrões não forem seguidos?
Essas verificações contínuas de integração precisam ser muito, muito rápidas. Qualquer atraso significativo significará que seus programadores irão confirmar e perder o controle de seu processo de pensamento enquanto aguardam os resultados. Aumente o tempo e eles se comprometem e tomam uma xícara de café ou conversam com seus colegas de escritório sobre o mais recente desempenho estragado de alguma equipe esportiva. Esses atrasos são altamente contraproducentes. É melhor deixar algumas coisas para a construção noturna ou a revisão de código.
Quais tipos de regras não devem ser usados para falhar na compilação?
Os subjetivos, para começar. Como você aplica a regra "O código deve ser auto-documentado ou bem comentado"? A regra "sem números mágicos"? É melhor deixar essas coisas para a revisão de código.
Outra categoria são violações às regras que já foram concedidas uma renúncia. Dada qualquer base de código considerável, inevitavelmente haverá um pedaço de código em que violar o padrão é exatamente a coisa certa a se fazer.
Como parte de um plano de melhoria da qualidade de software, recentemente codificamos uma série de farejadores de código para integrar nosso processo de compilação.
Construímos muito, sendo um aplicativo PHP, não há compilação real; portanto, a compilação é realmente um teste de unidade / análise estática / corredor, e podemos dar ao luxo de gastar alguns ciclos nisso.
Tivemos alguns problemas de qualidade de código e algum código legado com muitos problemas.
Começando com base no fato de que, se a falha não ocorrer, a confirmação será ignorada, e começamos a confirmar confirmações contra nosso padrão de codificação 'desejado' e a falha confirma com erros que não atendiam ao padrão.
A manutenção foi interrompida, mesmo a correção mais simples de um componente legado exigiu que o desenvolvedor reformatasse grandes quantidades de fontes, e a construção foi interrompida com mais frequência. Escusado será dizer que alteramos os erros para avisos, e agora eles são ignorados e 'na maior parte' inúteis.
Então, eu diria isso (aprendido com experiências difíceis).
Certifique-se de que o padrão da sua base de código esteja próximo o suficiente do padrão que você impõe, para que não seja necessário que os desenvolvedores reformatem volumes de código instantaneamente. Ou .. Você está preparado e espera o aumento de esforço.
Sendo uma equipe pequena com um enorme requisito de entrega, não podíamos dar ao luxo de mudar a equipe para uma enorme operação de re-fatoração. Nossos padrões de codificação agora são tratados principalmente por revisão manual, e o legado está sendo reescrito como parte de um plano de melhoria contínua.
Quando eu disse que os avisos são "praticamente inúteis", agora os usamos para registrar estatísticas que nos permitem medir os kpis que devem continuar mostrando melhorias.
Quando aplicarmos o código farejar novamente, iniciaremos a luz e introduziremos alguns farejadores de cada vez até que tenhamos o padrão imposto.
Vai depender do seu objetivo e estratégia finais .
Forçar todos os padrões mencionados no servidor de IC pode parecer muito lucrativo. No entanto, pode não ser prático para a grande equipe de desenvolvimento (mais de 6 desenvolvedores), se isso for feito em cada confirmação no servidor. Esperar que o servidor responda após a confirmação NÃO deve demorar muito. Isso pode causar algum tempo de inatividade.
No entanto, é totalmente legítimo bloquear uma confirmação se o código (o conjunto de alterações realmente) tiver problemas de dependência ou não for compilado. No entanto, a falha no código devido ao layout do código e a alguma convenção de nomenclatura pode ser muito severa e não é uma restrição vital para as regras de confirmação do servidor de IC.
Mas é muito provável que seja uma regra útil se aplicada durante a compilação noturna.
Além disso, as ferramentas de refatoração podem auxiliar na implementação e no aprendizado de padrões - como o uso do Resharper ou JustCode pelos desenvolvedores.