uma explicação profunda da complexidade do Código

não é um código secreto é uma coisa complicada para escrever, depurar e manter o que é necessário para a alta qualidade do software. Além disso, a alta complexidade do Código traz consigo um nível mais elevado de defeitos de código, tornando o código mais custoso de manter.

assim, ao reduzir a complexidade do Código, podemos reduzir o número de erros e defeitos, juntamente com o seu custo de vida. O que é exactamente um código complexo? Como podemos avaliar objetivamente como um pedaço de código é complexo, se isso é uma base de código inteira ou uma pequena função?

neste artigo, vou percorrer três métricas de complexidade para avaliar a complexidade do Código. Estes são:

• Cyclomatic complexidade
• instrução Switch e lógica condição de complexidade
• Desenvolvedor habilidade

eu também vou passar por alguns dos benefícios de avaliar e compreender a complexidade do código.

complexidade ciclomática

In 1976, Thomas McCabe Snr proposed a metric for calculating code complexity, called Cyclomatic Complexity. É definido como:

a quantitative measure of the number of linearly independent paths through a program’s source code…computed using the control flow graph of the program.

se não estiver familiarizado com um gráfico de fluxo de controlo:

é uma representação, usando notação de grafos, de todos os caminhos que podem ser percorridos através de um programa durante a sua execução.

Disse mais diretamente, quanto menos os caminhos através de um pedaço de código, e quanto menos complexos esses caminhos são, menor a complexidade ciclomática. Como resultado, o código é menos complicado. Para demonstrar a métrica, vamos usar três exemplos de código, um pouco arbitrários.

exemplo um

func main() { fmt.Println("1 + 1 =", 1+1)}

como há apenas um caminho através da função, ele tem uma pontuação de complexidade ciclomática de 1, que podemos encontrar executando gocyclo nela.

exemplo dois

func main() { year, month, day := time.Now().Date() if month == time.November && day == 10 && year == 2018 { fmt.Println("Happy Go day!") } else { fmt.Println("The current month is", month) }}

neste exemplo, estamos recuperando o ano atual, mês e dia. Com esta informação, verificamos então se a data atual é 10 de novembro de 2018 com uma condição if/else.

se for, então o código imprime ” Happy Go day!”para a consola. Se não for, então imprime “o mês atual é” e o nome do mês atual. O exemplo de código é tornado mais complicado como se a condição é composta de três sub-condições. Dado isso, tem uma pontuação de complexidade maior de 4.

exemplo três

func main() { _, month, _ := time.Now().Date() switch month { case time.January: fmt.Println("The current month is January.") case time.February: fmt.Println("The current month is February.") case time.March: fmt.Println("The current month is March.") case time.April: fmt.Println("The current month is April.") case time.May: fmt.Println("The current month is May.") default: fmt.Println("The current month is unknown.") }}

neste exemplo, estamos a imprimir o mês actual, com base no valor de month, recuperado da chamada para time.Now().Date(). Há sete caminhos através da função, um para cada uma das declarações de caso e um para o padrão.Como resultado, sua complexidade ciclomática é 7. Se tivéssemos contabilizado todos os meses do ano, junto com um padrão, no entanto,sua pontuação seria de 14. Isso acontece porque Gocyclo usa as seguintes regras de cálculo:

1 é a base de complexidade de uma função
+1 para cada ‘se’, ‘para’, ‘caso’, ‘&&’ ou ‘||’

com esses três exemplos, podemos ver que, por terem uma métrica padrão para calcular a complexidade do código, podemos avaliar rapidamente o quão complexo um pedaço de código.

podemos também ver como diferentes secções complexas de código são em comparação entre si. No entanto, a complexidade ciclomática não é suficiente por si só.

Switch Statement and Logic Condition Complexity

The next assessor of code complexity is the switch statement and logic condition complexity. No exemplo de código abaixo, eu peguei o segundo exemplo Go e dividi o composto se condição em três condições aninhadas; uma para cada uma das condições originais.

func main() { year, month, day := time.Now().Date() output := fmt.Sprintf("The current month is %s", month) if month == time.November { if day == 13 { if year == 2018 { output = fmt.Sprintf("Happy Go day!") } } } fmt.Println(output)}

Qual é mais fácil de entender( ou menos complicado), o original, ou este? Agora vamos continuar com isso, considerando as seguintes três perguntas.

• e se tivéssemos, como fazemos acima, múltiplas condições if e cada uma delas fosse bastante complexa?E se tivéssemos múltiplas condições e o código no corpo de cada uma delas fosse bastante complexo?
• o código seria mais fácil ou mais difícil de entender?

é justo dizer que quanto maior o número de condições aninhadas e maior o nível de complexidade nessas condições, maior a complexidade do Código.

nível de habilidade do desenvolvedor de Software

e o nível de habilidade do desenvolvedor? Dê uma olhada na versão C do segundo exemplo Go abaixo.Tecnicamente, faz o que os outros exemplos fazem. No entanto, é necessário mais código para alcançar o mesmo resultado. Para ser justo, se eu tivesse uma familiaridade maior com C, o código não poderia ser mais do que o exemplo Go.

no entanto, digamos que este é o mínimo necessário para alcançar o mesmo resultado. Se você comparar os dois, dada a natureza mais descritiva da sintaxe de C quando comparado ao Go, é mais difícil de entender.

o que é mais, se você não tinha experiência prévia com C, apesar de uma pontuação de complexidade ciclomática comparativamente semelhante, qual seria a sua percepção?

consideraria o código menos ou mais complicado? Portanto, este é outro fator essencial para entender a complexidade do Código.

the Benefits of Measuring Software Complexity

There are four core benefits of measuring code complexity, plus one extra.

melhores testes

sabendo quantos caminhos independentes existem através de um pedaço de código, sabemos quantos caminhos há para testar.

eu não estou defendendo uma cobertura de código 100% a propósito—isso é muitas vezes uma métrica de software sem sentido. No entanto, defendo sempre um nível de cobertura de código tão elevado quanto possível e prático.Por isso, sabendo quantos caminhos de código existem, podemos saber quantos caminhos temos de testar. Como resultado, você tem uma medida de quantos testes são necessários, no mínimo, para garantir que o código é coberto.

risco reduzido

como diz O velho ditado::

é mais difícil ler o código do que escrevê-lo.

o que é mais:

1. Código é ler muito mais do que está escrito
2. Um bom desenvolvedor de software deve nunca ser avaliada pelas linhas de código que eles escreveram (ou alterado), mas pela qualidade do código que temos mantido.

dado que, ao reduzir a complexidade do código, você reduz o risco de introduzir defeitos; sejam pequenos ou grandes, ligeiramente embaraçosos ou induzidos por falência.

custos mais baixos

quando o risco de defeitos potenciais é reduzido, há menos defeitos para encontrar-e remover. Como resultado, o custo de manutenção também reduz.

todos nós vimos e estamos familiarizados com os custos associados a encontrar defeitos nas várias fases da vida de um software, como exemplificado no gráfico abaixo.

por isso faz sentido que, se entendermos a complexidade do nosso código, e quais seções são mais complicados do que outros, então estamos em uma posição muito melhor para reduzir disse complexidade.Por isso, ao reduzir essa complexidade, reduzimos a probabilidade de introduzir defeitos. Isso flui para todas as fases da vida de um software.

maior previsibilidade

ao reduzir a complexidade do software, podemos desenvolver com maior previsibilidade. O que quero dizer com isso é que somos mais capazes de dizer—com confiança—quanto tempo uma seção de código leva para completar. Sabendo isto, somos mais capazes de prever quanto tempo uma libertação demora a enviar.Com base neste conhecimento, a empresa ou organização é mais capaz de definir seus objetivos e expectativas, especialmente aqueles que são diretamente dependentes do referido software. Quando isso acontece, é mais fácil definir orçamentos realistas, previsões, etc.

ajuda os desenvolvedores a aprender

ajudar os desenvolvedores a aprender e crescer é o benefício final de entender por que seu código é considerado complexo. As ferramentas que usei para avaliar a complexidade até agora não fazem isso.

o que eles fazem é fornecer uma pontuação global ou granular de complexidade. No entanto, uma ferramenta abrangente de complexidade de código, como o Codacy, faz.

na imagem acima, podemos ver que, dos seis arquivos listados, um tem uma complexidade de 30, uma pontuação geralmente considerada bastante alta.

complexidade ciclomática é um grande indicador para entender se a qualidade do código se deteriora para qualquer alteração dada. A complexidade ciclomática pode ser mais difícil de raciocinar ao olhar para ela ou ao comparar módulos inteiros dada a sua escala infinita e não estando relacionada com o tamanho do módulo. No entanto, algo que você pode achar útil é olhar para a lista de arquivos do Codacy classificados por prioridade, o que irá ajudá-lo a entender quais arquivos são candidatos de má qualidade de código, e, em seguida, por consequência, seus módulos.

isso é um Wrap

também, esta tem sido uma discussão aprofundada sobre o que é a complexidade do código, como ele é avaliado, bem como os benefícios significativos de reduzi-lo. Embora haja mais para entender a complexidade do Código do que eu já cobri aqui, nós fizemos um longo caminho para entendê-la.Se esta é a sua primeira audição sobre o termo ou aprender sobre qualquer uma das ferramentas, encorajo-o a explorar os artigos e ferramentas ligados, para que saiba mais. Se você não codifica em Go ou C, em seguida, google “ferramenta de complexidade de código” mais sua linguagem de software(s). Você está certo de encontrar muitas ferramentas disponíveis.

para mais dicas para melhorar a qualidade do Código confira alguns outros posts do blogue do Codacy.

finalmente, se você quiser uma ferramenta abrangente para avaliar a qualidade do código, e uma que ajude seus desenvolvedores a aprender e crescer, então experimente o Codacy.

Codacy is used by thousands of developers to analyze billions of lines of code every day!

começar é fácil-e livre! Basta usar a sua conta GitHub, Bitbucket ou Google para se inscrever.

COMEÇAR