Se você ainda não se convenceu de que métricas de código são aliadas de um arquiteto, conheça nos tópicos a seguir 2 exemplos simples.

Lines of Code (SLOC, LOC, ou linhas de código)

A mais simples das métricas. Consiste numa contagem de linhas existentes em uma determinada porção de código fonte. Geralmente sumarizadas por métodos, classes ou assemblies, LOC nos dá de imediato uma clara visão do "tamanho" do software.

Imagine-se na seguinte situação: Você deve dar manutenção num código que não conhece. Você utiliza uma ferramenta para lhe retornar alguns indicadores baseados na métrica LOC e obtém o seguinte resultado:

Obviamente, pela Lei de Murphy, sua incumbência será manutenir 3 dos métodos com mais de 1000 linhas de código. Seu gerente quer saber, com precisão de milissegundos, quando você terminará a atividade. Bacana, né? Vamos supor que esse código não possua testes de unidade escritos. Poxa, que legal, não é verdade?

Note que medir e produzir indicadores, por si só, não muda nada. Os métodos continuarão excessivamente grandes, os testes não surgirão do nada e nem a manutenção acontecerá sozinha. Contudo, você terá argumentos para fazer com que seu gerente reveja as estimativas, acrescendo algum grau de incerteza.

Ah, você não tem gerente? Não dá manutenção em sistemas desse "quilate"? Sorte sua. Ainda sim, os indicadores gerados com LOC seriam úteis, já que inevitavelmente, sempre existirá um usuário do sistema que precisa da manutenção executada o quanto antes (ainda mais se tratar de um erro). Ou seja, os indicadores ainda serão interessantes para:

• Analisar qualidade e produtividade do processo de desenvolvimento e manutenção bem como do produto de software construído;
• Qualificar a performance técnica dos produtos do ponto de vista do desenvolvedor;
• Qualificar a performance dos produtos pela perspectiva do usuário;
• Utilizadas para comparar a produtividade de diferentes técnicas e tecnologias;
• Entender e aperfeiçoar o processo de desenvolvimento;
• Determinar parâmetros como quantidade de teste necessário e impacto de mudanças;
• E várias outras razões explicadas aqui.

Quer ver outra medida transuda para usar no cenário acima?

Cyclomatic Complexity (CC, ou complexidade ciclomática)

Essa métrica nos diz quais os caminhos (decisões) possíveis de execução dentro de um código. De fato, é uma métrica que expressa a complexidade (notadamente, utilizadas em métodos). Para algumas ferramentas uma contagem de 15 pontos de CC sugere um código difícil de entender e manutenir. Quando obtemos como resultado 30 (ou mais) de CC, temos um código extremamente complexo de entender e manutenir. Considere o código abaixo:

Calculando a CC para o código acima, chegamos ao número 3. Observe abaixo:

Em linguagens como C#, as seguintes expressões são desconsideradas para cálculo da CC: else | do | switch | try | using | throw | finally | return | object creation | method call | field access. Isso pode variar para outras linguagens, mas no geral, é considerado dessa forma.

A Complexidade Ciclomática nos diz muito a respeito do código. No cenário exposto no tópico anterior, poderíamos entender melhor o quão difícil seria manter o software. A CC também pode demonstrar um design fraco ou mal pensado. Além disso, seria possível ter uma boa noção da quantidade de testes que deveriam (no mínimo) ser escritos levando em consideração uma cobertura de testes de 100% do código.

Convencido agora?!

Ainda não? Nos próximos posts, veremos outras métricas. ;)

Arquitetura Code Metrics

Há tempos estava querendo escrever a respeito de métricas de código. Trata-se de um assunto interessantíssimo e carente de informações, na minha opinião.

Um significativo óbice à criação de software com qualidade é a dificuldade que temos de visualizar o todo. Em geral, estamos confinados a diminuta visão que a IDE nos dá, através do editor de códigos ou de alguma outra abstração textual. É como se tentássemos contemplar a obra Guernica com um óculos de joalheiro, você dificilmente conseguirá entender o que está acontecendo e ficará atento apenas a detalhes "desconexos" do todo.

Visões de mais alto nível, com abstrações adequadas, podem dizer muito a respeito do código produzido. Essas abstrações podem ser conseguidas através de métricas de código, e a partir daí transformadas em gráficos, indicadores compostos, relatórios, matrizes ou até mesmo em um "banco de dados" indexado para consultas, potencializando seus significados.

É importante deixar claro que as métricas de código não estão relacionadas apenas com o software em si, mas também com os processos de desenvolvimento e manutenção. Consegue-se, a partir das métricas, dados quantitativos que oferecem uma boa informação sobre o andamento da construção sendo possível estimar custos, avaliar tendências, melhorar o design, ou até mesmo ter noção sobre a qualidade do sistema produzido.

O potencial das métricas de código

Através das métricas de código podemos conhecer a complexidade, tamanho, quantidade de métodos, nível de coesão, grau de acoplamento entre classes, dentre inúmeras outras possibilidades. Além disso, as métricas são usadas para:

• Analisar qualidade e produtividade do processo de desenvolvimento e manutenção bem como do produto de software construído;
• Qualificar a performance técnica dos produtos do ponto de vista do desenvolvedor;
• Medidas funcionais são necessárias para qualificar a performance dos produtos pela perspectiva do usuário;
• Utilizadas para comparar a produtividade de diferentes técnicas e tecnologias;
• Entender e aperfeiçoar o processo de desenvolvimento;
• Reduzir frustrações e pressões de cronograma;
• Embasar solicitações de novas ferramentas e treinamentos;
• Formar uma linha básica para estimativas;
• No nível técnico, as medições são importantes para determinar parâmetros como quantidade de teste necessário e impacto de mudanças.

Quando se pode medir aquilo sobre o qual se está falando e expressá-lo em números, sabe-se alguma coisa sobre o mesmo; mas quando não se pode medi-lo, quando não se pode expressá-lo em números, o conhecimento que se tem é de um tipo inadequado e insatisfatório; este pode ser o começo do conhecimento, mas dificilmente alguém terá avançado em suas idéias para o estágio de ciência.

Uma métrica deve ser válida, o que significa que ela deve quantificar o que queremos medir. Ela também precisa ser confiável, prozudindo os mesmos resultados dadas as mesmas condições. Por fim, métricas precisam ser produzidas facilmente, ou seja, devem ser baratas.

Diferenciando alguns jargões: medida, medição, métrica e indicador

Quando entramos no mundo das métricas tomamos contato com alguns termos que, em determinadas circunstâncias, geram algumas confusões. Vamos lá:

• Medida: Fornece uma indicação quantitativa da extensão, quantidade, dimensão, capacidade ou tamanho de algum atributo de um produto ou processo. Medida é uma função de mapeamento;
• Medição: Ato de determinação de uma medida;
• Métrica: Medida quantitativa do grau em que um sistema se encontra em relação a um determinado atributo;
• Indicadores: Métrica ou combinação de métricas que fornece uma compreensão de um processo/projeto/produto.

As métricas podem ser categorizadas de maneiras diferentes, tais como métricas diretas e indiretas, ou métricas orientadas a tamanho, ou funções, entre outras.

Enfim, uma grande aliada do arquiteto de software!

Claro, até mesmo desenvolvedores, analistas de teste, analistas de sistema, líderes técnicos (e pasmem, até mesmo gerentes de projeto) ou qualquer outro membro de um time pode se beneficiar das métricas de software. Contudo, elas são especialmente interessantes para um arquiteto de software (aqui, reforço o arquiteto de software por acreditar que seria o papel mais coerente para tal).

Idealmente, os dados necessários para se estabelecer uma linha básica foram compilados continuamente. Infelizmente, isso raramente acontece. Por conseguinte, a coleta de dados requer uma investigação histórica dos projetos passados para se reconstruir os dados exigidos. Logo que os dados foram coletados, a computação das métricas é possível. A avaliação dos dados concentra-se nas razões subjacentes para os resultados obtidos.

Sendo o arquiteto de software (tanto no exercício de um cargo ou papel) o indivíduo responsável pela estrutura e design de um produto e também o canal de comunicação entre time de desenvolvimento e arquiteto corporativo (cargo ou papel), podemos aferir que:

As medições e as métricas ajudam a entender o processo técnico usado para desenvolver um produto. O processo é medido num esforço para melhorá-lo, assim como o produto é medido num esforço para aumentar sua qualidade. Também são necessárias para analisar a qualidade e a produtividade do processo de desenvolvimento; bem como a manutenção do produto de software construído.

Em posts futuros veremos diversos exemplos de métricas de código. Até lá! ;)

Arquitetura Code Metrics

Registrando o meme que o @egomesbrandao fez hoje, onde fui “gentilmente” mencionado.

Off Eu mereço

Em minha (arrogante) opinião, em geral, existe algum consenso mínimo sobre o que é um código elegante de fato. No entanto, tenho visto alguns exemplos de “códigos elegantes” que adicionam complexidade, verbosidade e outras questões incômodas. É bem verdade que existem algumas coisas - em qualquer linguagem de desenvolvimento - que levam o código de "Que aceitável!" para o nível "Wow! Que impressionante!".

Na verdade, cada desenvolvedor tem uma definição diferente de elegância e tudo pode estar correto dentro de uma determinada perspectiva - ou não.

Talvez o mais perto que consigamos chegar de um consenso sobre o tema, seja o que a engine Elegant Code Maker fez.

Sabe uma coisa que odeio?

Posts que, ao explicar algum conceito, colocam a definição do dicionário. Parece que o autor não sabe porcaria nenhuma e mesmo assim decidiu escrever a respeito. Como que se, durante o exercício de escrita, ele fosse elaborando o pensamento e consequente aprendizado. Boring!

Contudo, farei isso nesse post, veja só:

elegância
(latim elegantia, -ae, gosto, delicadeza, distinção)
s. f.
1. Gosto delicado no trajar, no falar, no adorno da casa, etc.
2. Graça, airosidade, delicadeza e distinção aliada à simplicidade e clareza.

Não sei quantos códigos airosos você tem visto ultimamente (ou mesmo codificado). Mas gosto muito da parte “aliada à simplicidade e clareza”. Talvez esse seja um bom ponto de partida (e término) para qualificarmos um código realmente elegante.

Dias atrás, lendo um post do amigo @elemarjr, deparei-me com uma comparação de códigos que realmente discordei. Veja a seguir:

Segundo o Elemar, o segundo código é mais elegante que o primeiro. Embora, como disse no início do post, esse tipo de discussão seja sujeita a inúmeros pontos de vista conflitantes e corretos dentro de alguma perspectiva particular, fiquei elucubrando a respeito.

Acabei codificando o Elegant Code Maker, como uma espécie de provocação (não ao Elemar, hehehe, mas a todos os desenvolvedores. Ah, e obrigado @vquaiato pelo fork e correções no meu código com jQuery e pelo apoio pra fazer o deploy no AppHarbor, foi muito divertido!).

Como eu defino um código elegante

Um código que seja ao mesmo tempo simples mas eficaz e construtivo, ou seja, uma pequena quantidade de código que consegue realizar um “grande efeito”: Esse é um código elegante.
Assim sendo, um código elegante deve:

• Ser de fácil entendimento e leitura, sem gerar dúvidas;
• Ser aderente ao padrão da plataforma ou ao padrão estabelecido dentro de um contexto. Entre dois códigos elegantes, o que mais se aproximar do padrão aceito por todos deve ser o escolhido;
• Ser correto, claro! De nada serve um código que não implementa plenamente o seu propósito;
• Ser oriundo de persistência e consistência. Isso é obtido com experiência e treino.

Aposto que você não concorda totalmente comigo, certo? E é por aí mesmo...

Sejamos felizes e busquemos o nosso melhor, sempre!

Dicas código elegante

No último episódio do Void Podcast, tocamos no assunto “ética no desenvolvimento de software” (em especial por parte de consultorias e fornecedores de produtos e serviços de software). Relacionamos a falta de ética como um dos grandes óbices para a reversão de um quadro de brownfield para greenfield.

Uma pequenina discussão foi iniciada nos comentários do episódio, onde um significativo depoimento foi colocado pelo Daniel Yokoyama. Embora quase que a totalidade das pessoas com quem converso a respeito sejam descrentes com relação a ética aplicada, gostaria de discorrer sucintamente sobre o tema.

Algumas (pouquíssimas, mesmo!) palavras sobre ensino de ética e a história recente do Brasil

Fui criado no longínquo século XX onde, por incrível que pareça, as empresas se preocupavam de fato em satisfazer seus clientes. Também peguei a época em que disciplinas como OSPB e EMC eram obrigatórias em qualquer escola.

Puxa, talvez você tenha pouca idade e desconheça essas siglas. Vamos lá:

OSPB (Organização Social e Política Brasileira) foi uma disciplina que, de acordo com o Decreto Lei 869/68, tornou-se obrigatória no currículo escolar brasileiro a partir de 1969, juntamente com a disciplina de Educação Moral e Cívica (EMC). Ambas foram adotadas em substituição às matérias de Filosofia e Sociologia e ficaram caracterizadas pela transmissão da ideologia do regime autoritário ao exaltar o nacionalismo e o civismo dos alunos e privilegiar o ensino de informações factuais em detrimento da reflexão e da análise. O contexto da época incluía a decretação do AI5, desde 1968, e o início dos ‘anos de chumbo’ - a fase mais repressiva do regime militar cujo ‘slogan’ mais conhecido era ‘Brasil, ame-o ou deixe-o’.

Dessa forma, as duas matérias foram condenadas pelos Parâmetros Curriculares Nacionais (PCN), estabelecidos pela Lei de Diretrizes e Bases da Educação (LDB) de 1996, por terem sido impregnadas de um ‘caráter negativo de doutrinação’.

Julgue esse período como quiser, pois não é foco deste post ponderar sobre o tema. O que gostaria de ressaltar é que dentre todo o conteúdo passado nessas matérias o que mais ficou marcado pra mim foi justamente o que tratava a ética. Fora a primeira ocasião em minha vida onde apresentaram tal assunto.

Tenho minhas dúvidas se, no “mundo politicamente correto de hoje”, algum conteúdo sobre ética é passado nas escolas. E principalmente, esse conteúdo é passado a tempo? Ou seja, estamos contribuindo de forma adequada para a formação do caráter de nossas crianças?

Se a pergunta “Qual a conduta correta para um indivíduo em sociedade?” é muito complexa, talvez você consiga me responder...

... Qual a conduta correta para profissionais de TI?

O desenho abaixo ilustra três facetas da ética no dia a dia de um profissional de TI.

Mesmo sendo a ética alvo de longas discussões, gostaria de chamar sua atenção para uma definição de Código de Ética em Engenharia de Software resultante dos esforços de uma equipe de trabalho multinacional liderada pela IEEE/ACM.

Existe uma versão longa deste código, contudo, acho suficiente destacar o seguinte resumo:

1. Público. Engenheiros de Software devem atuar consistentemente com os interesses públicos.
2. Clientes e empregados. Engenheiros de Software devem atuar de modo a atender os melhores interesses dos seus clientes e empregados, consistentemente com os interesses públicos.
3. Produto. Engenheiros de Software devem assegurar que seus produtos e modificações relacionadas atendam os melhores padrões profissionais possíveis.
4. Julgamento. Engenheiros de Software devem manter a integridade e independência nos seus julgamentos profissionais.
5. Administração. Administradores e líderes de Engenharia de Software devem aderir e promover uma abordagem ética ao gerenciamento do desenvolvimento e manutenção de software.
6. Profissão. Engenheiros de Software devem desenvolver a integridade e reputação da profissão consistentemente com os interesses do público.
7. Coleguismo. Engenheiros de Software devem ser justos e dispostos a auxiliar seus colegas.
8. Identidade. Engenheiros de Software devem participar do aprendizado de suas vidas valorizando a prática da sua profissão e devem promover uma abordagem ética à prática da profissão.

Perceba que, mesmo com a versão resumida do código, após um exercício individual de reflexão, podemos constatar se estamos inseridos em um ambiente ético (ou se estamos chafurdados no brownfield plus, como foi dito no episódio do Void).

Um ponto de vista sobre a ética empresarial

Como mencionei anteriormente, o assunto é extenso, mas acho oportuno trazer aqui um ponto de vista colocado pelo advogado Joaquim Manhães Moreira, autor do livro “Ética na gestão empresarial”:

O único lucro moralmente aceitável é aquele obtido com ética. A moral impõe que a empresa aja com ética em todos os seus relacionamentos, com clientes, fornecedores, competidores e seu mercado, empregados, governo e público em geral.

Ainda dentro de seu pensamento:

• Uma empresa ética incorre em custos menores do que uma antiética. A empresa ética não faz pagamentos irregulares ou imorais, como subornos, compensações indevidas e outros.

 

• Por não efetuar subornos, ela consegue colocar em prática uma avaliação de desempenho de suas áreas operacionais, de forma mais precisa do que a empresa antiética. Um exemplo da dificuldade de avaliar o desempenho quando não se age com ética está na possibilidade de aceitação de desculpas de que uma venda não pôde ser realizada, porque o concorrente ofereceu um suborno maior ao cliente.

 

• O lucro gerado para os acionistas não fica sujeito a contingências futuras, como, por exemplo, condenações por procedimentos indevidos.

 

• Ao aderir a um código de ética consistente e claro, praticando uma conduta ética, a empresa empresta legitimidade aos seus negócios, envolvendo todos os seus empregados e administradores neste clima de lealdade e dedicação.

 

• A empresa ética tem o respeito de seus parceiros, fornecedores e clientes, elevando a sua marca e facilitando sua expansão.

 

• A empresa deve ser responsável por ajudar a melhorar continuamente a sociedade da qual obtém lucro, não somente no aspecto material, mas também abstrato, adotando práticas de ética.

A conclusão é sua :)

Fique à vontade para comentar.

Carreira Ética