Administrando o código fonte usando Visual Studio Team System

As empresas reclamam com freqüência da real dependência que elas possuem das pessoas que realizaram a implementação do software, o que por muitas vezes vem a prejudicar ambas as partes. A empresa fica atrelada a uma pessoa específica para fazer a manutenção e o próprio profissional fica impedido de desempenhar uma nova função por causa dessas pendências de manutenção no código antigo.

por Ramon Durães

Introdução

As empresas reclamam com freqüência da real dependência que elas possuem das pessoas que realizaram a implementação do software, o que por muitas vezes vem a prejudicar ambas as partes. A empresa fica atrelada a uma pessoa específica para fazer a manutenção e o próprio profissional fica impedido de desempenhar uma nova função por causa dessas pendências de manutenção no código antigo.

Com o amadurecimento do mercado que se torna cada vez mais competitivo e do próprio usuário final que passou a ser mais exigente, está cada vez mais claro que desenvolver software de forma profissional é um dos grandes desafios no mercado atual.

Em função dos vários fatores que envolvem o desenvolvimento de um produto, conclui-se que não é uma tarefa fácil desenvolver software, principalmente pelos riscos envolvidos desde a concepção de um simples projeto até a sua entrega no prazo estipulado. Eu costumo dizer que na engenharia civil, em um primeiro contato, nós já podemos visualizar a entrega de uma tarefa que foi combinada como uma parede, por exemplo, assim como verificar no momento a qualidade com que ela foi produzida.

Quando falamos de software, entramos em um conceito de entrega difícil de ser visualizado e com dificuldades ainda maiores para se mensurar a qualidade de forma manual. Um dos maiores artefatos de uma empresa de software, é o próprio código fonte entregue. Em cima do mesmo que são feitas as averiguações de qualidade e futuras manutenções.

Visual Studio Team System

A partir desse momento, entramos em um ponto muito importante, que é como gerenciar o desenvolvimento desse código fonte e garantir uma padronização para que todos do projeto sigam o mesmo modelo de codificação, permitindo que mais pessoas sejam agregas ao projeto ou  garantir uma manutenção futura mais fácil, de forma a reduzir a dependência das pessoas que implementaram -  conforme já comentamos - ou como produzir um código mais fácil de ser testado.

Com o objetivo de atender a demanda do mercado por uma gerência mais efetiva do ciclo de desenvolvimento de aplicações (Application Lifecycle Management ou ALM), a Microsoft lançou no mercado desde 2005 a plataforma Visual Studio Team System (VSTS), que interagindo com todos os papéis envolvidos no projeto, permite uma gestão efetiva do ciclo, aumentando a previsibilidade no projeto de software, assim como a gestão estratégica com base nas informações coletadas que auxiliam os tomadores de decisão com ações mais rápidas de correção.

Incorporado a solução de  Visual Studio Team System (VSTS), temos um servidor dedicado a concentrar todas as informações do projeto. Esse servidor é conhecido como Team Foundation Server (TFS), que funciona como um repositório central de informações do projeto conforme a figura 01.

Figura 01 – Team Foundation Server

O Team Foundation Server gerencia toda a comunicação do projeto, oferecendo integração com as tarefas planejadas no Microsoft Project  por meio do recurso Work Item que são distribuídas para o Visual Studio dos desenvolvedores. Cada desenvolvedor vai trabalhar com suas tarefas (Work Item) que ao finalizadas serão automaticamente atualizadas no cronograma do projeto. Outro recurso importante, é a integração contínua baseada no servidor de automação de build que funciona como um robô para automaticamente obter o código fonte e executar toda a política de controle de qualidade e versão. A cada passo no projeto, as informações podem ser consultadas por meio de relatórios estratégicos. Mais um grande pilar e uma de suas atribuições, é o controle do código fonte incluindo as principais características encontradas no mercado:


- Check In / Checkout – Envio e recebimento de código fonte do repositório.
- History – Histórico de alterações.
- Label – Marca em bloco de código muito útil para gerar marco do projeto.
- Branch – Permite criar sub versões do código fonte mais conhecidos como ramificações: V1,V1.1,V1.2 para que se possa trabalhar em versões diferentes do mesmo projeto.
- Merge – Permite unit dois arquivos.
- Shelving – Funciona como Check In só que do usuário. Muito usado para realizar um backup pessoal do código que não pode ser enviado via Check In por ainda estar incompleto.

O Team Foundation Version Control (TFVC), utiliza o modelo de transações baseados no Microsoft SQLServer para armazenamento do código recebido garantindo uma identificação única para cada bloco de código recebido no repositório, gerando uma espécie de ticket conhecido como Changset.

A principal diferença de imediato do Team Foundation Version Control (TFVC) para outro controle de versão existente no mercado incluindo o próprio Microsoft Source Safe, é que ele não faz apenas controle de versão de código fonte. O TFVC é integrado ao ciclo de desenvolvimento da aplicação permitindo o uso de políticas associadas ao código fonte. Com essas políticas, você pode exigir, por exemplo, que para o código de um determinado projeto seja necessário vincular uma tarefa de solicitação do mesmo que dentro da plataforma do VSTS nós chamamos de Work Item e representa a mesma tarefa criada pelo gerente de projeto no Microsoft Project conforme a figura 02.

Então no momento do Check In conforme a figura 03 e a figura 04 é exigido a associação de um Work Item.

Figura 02 – Criando um workitem diretamente pelo Microsoft Project


Figura 03 – Realizando Check in



Figura 04 – Violação de política durante Check In

Na figura 04 você está acompanhando a violação de uma política do TFVC. Para prosseguir com esse Check In é necessário vincular um Work Item conforme demonstrado na figura 05.  Com essa primeira política, você já terá resposta a qualquer momento de quem mudou o código fonte e o porquê dessa mudança indicada pelo Work Item relacionado. Diversas outras políticas podem ser associadas, estabelecendo um rígido controle, recusando um código que esteja fora de um padrão de nomenclatura, por exemplo, ou que não contenha comentários descrevendo as funcionalidades implementadas nos métodos.

Figura 05 – Associando um Work Item ao Check In

Annotate

É muito comum nos clientes a dificuldade em realizar auditoria para saber quem mudou uma determinada linha de código e o porquê dessa mudança. Com o recurso Annotate do VSTS, nós temos essa resposta de forma imediata e sem complicações, inclusive ainda com a possibilidade de retornar à situação anterior a mudança quando necessário. Confira mais detalhes na  figura 06 e acompanhe o Annotate em ação exibindo o histórico de um código fonte com suas alterações linha a linha.


Figura 06 – Recurso Annotate em ação

O recurso Annotate conforme apresentado na figura 06, fornece informações preciosas para uma rápida auditoria em seu projeto, verificando o código do Changeset que é um identificador único gerado para cada Check In, o nome do responsável pela alteração e a data da mesma. Ao clicar no Changeset você pode verificar todos os arquivos que estão relacionados a essa alteração e os Works Items associados que representam a solicitação de alteração conforme figura 07.


Figura 07 – Visualizando um Changeset

Conforme você está acompanhando na figura 07 em Source Files, é possível visualizar todas as  informações desse Check in que inclui os arquivos, comentários, notas de Check in e um item importante que comentamos anteriormente, que é o Work Item. Ele traz a solicitação de alteração ou construção desse bloco de código e está diretamente ligado ao workflow de comunicação do Team Foundation Server e acessível via Microsoft Project garantindo integração com o gerente de projeto conforme demonstramos na figura 02.


Code Analysis

O VSTS traz incorporado uma ferramenta de análise estática de código que faz o papel  do Code Review no projeto auxiliando a revisão e a garantia dos padrões baseado em regras configuráveis. Com o uso integrado com as políticas do Team Foundation Server, toda vez que algum usuário for fazer ação de Check In ele será obrigado a compilar o projeto e a rodar o analisador de código e passar em todas as regras requeridas nas configurações do projeto, garantindo que o código recebido no Check In esteja seguindo os padrões estabelecidos. As regras são configuradas no servidor conforme figura 08 e vão desde questões de arquitetura, desempenho, segurança a padrões de nomenclatura utilizados no projeto. Ao fazer um Check In conforme figura 09, é requisitado que rode o Code Analysis para a liberação do Check In. O simples fato de você exigir a execução do Code Analysis já impede o envio de código quebrado (que não compila) para o TFVC. Um envio de um código quebrado pode prejudicar todo o time do projeto e resultar em perda de horas preciosas no mesmo, pois um outro desenvolvedor pode pegar esse código quebrado e parar sua atividade até descobrir como corrigir.


Figura 08 – Configuração de Políticas

Figura 09 – Check In requisitando política Code Analysis

Na figura 10, você confere uma verificação do padrão Microsoft.Naming e o analisador reclamado da violação da regra. Conforme já tratamos anteriormente, será necessária a correção do código que está violando esse padrão para que possa continuar com o Check In.

Figura 10 – Violando padrão de nomenclatura

Conforme a figura 10, o simples fato de escrever o nome do parâmetro  “SAlario” fora do padrão do projeto, ele foi identificado pelo analisador  e  está exigindo do desenvolvedor a correção para que o código seja aceito durante o Check in. Esse é mais um grande registro da integração do controle de código fonte ao ciclo de desenvolvimento. Você pode usar qualquer uma das regras existentes, ou caso deseje,  pode codificar uma nova regra e incorporar ao analisador.

Em um primeiro momento, você pode até estar se perguntando porquê se preocupar com um simples padrão de nomes. Quando falamos em projetos de software com várias pessoas participando e depois dando manutenção, o controle torna-se importantíssimo para fazer com que todos desenvolvam da mesma forma e você tenha a possibilidade, a qualquer momento, de substituir ou agregar mais pessoas ao projeto e essas tenham uma integração mais rápida, pois vão continuar desenvolvendo no padrão que já estão acostumados.

Vale ressaltar, conforme já tratamos no início, que temos a disposição um conjunto enorme de padrões, mas não implica que todos devam ser usados ao mesmo tempo para todos os projetos. Você deve avaliar juntamente com o arquiteto do projeto.

Code Metrics

O Code Metrics oferece mais um recurso para avaliação do código fonte, oferecendo métricas importantes que trazem informações valiosas sobre a complexidade do código implementado baseado nos seguintes índices para avaliação: Maintainability Index, Cyclomatic Complexity, Depth of Inheritance, Class Coupling e Lines of Code. Para utilizar, basta clicar em uma solução e com botão direito escolher Code Metrics e conferir o resultado apresentado na figura 11.


Figura 11 – Janela de resultado do CodeMetrics

Maintainability Index
O índice de manutenção do código fonte traz um indicador calculado conforme fórmula “Maintainability Index Technique for Measuring Program Maintainability” proposto pelo SEI (Software Engineering Institute) que é representado por um índice variando de 0 a 100 sendo que quanto maior melhor. Ele é representado  nas cores:  verde, amarelo e vermelho.

Cyclomatic Complexity
O Índice de complexidade baseado em ciclos, foi proposto inicialmente em 1946 por Thomas McCabe com objetivo de indicar a complexidade de um código. Ele é calculado identificando os pontos de decisão baseados no uso excessivo de muitas estruturas como: if, switch cases, do, while, foreache for. Esse indicador quanto mais alto representa, também uma maior dificuldade em testar esse código que pode resultar em muitos bugs devido às diversas possibilidades de desvios provados pelas estruturas implementadas que resultam em maior quantidade de código para se testar.

Depth of Inheritance
O índice de profundidade de herança é baseado na quantidade de heranças implementadas e identifica uso excessivo de orientação a objetos. Visualizando a figura 12 você pode observar a classe MeuListBox que depende de quatro outras classes gerando uma dependência muito grande levando a um código mais complexo de se testar e manter.


Figura 12 – Índice de profundidade baseado em heranças.

 Class Coupling

O índice de acoplamento traz o número de  dependências de outros tipos. Nesse índice não é adicionado os tipos primitivos como Int32,Strint,Object. Avaliando a figura 13 a Classe d é tem indice de 0 indicando uma boa classe para ser utilizada.

Figura 13 – Índice de acoplamento.

Lines of Code
Esse índice apresenta a quantidade de linhas por método. Com essa informação você pode atuar em um  outro ponto muito importante e bastante comentado que é a padronização do tamanho de linhas por método implementado. Já tive casos em projetos durante trabalho de auditoria que encontrei um simples botão com 5.000 linhas implementadas.  Ao conversar com o responsável pelo feito o mesmo se encontrava muito feliz por ter construindo quase um sistema todo em um método. Com muita cautela eu expliquei para ele que o resultado daquela implementação ia gerar um código difícil de ser mantido e complexo. Por padrão trabalhamos com 15 a 20 linhas por método. Passando disso é recomendável fazer um refactoring para quebrar esse método em um conjunto de outros menores de forma que caso tenha um problema a ser resolvido que se resolva em um pequeno bloco de código.



Numa avaliação mais detalhada da figura 11 encontramos o método cujo nome é “MetodoRuim” que apresenta conforme os indicadores visuais alta dificuldade na sua manutenção. Em uma rápida visualização do código fonte conforme figura 14 podemos ir diretamente ao bloco de código com o problema.


Figura 14 – Verificando implementação de método com problemas de implementação

A dificuldade em manter um código conforme a figura 14 também implica na dificuldade em testar o mesmo. Ou seja, quanto mais complicado mais sujeito a bugs devido a complexidade em atingir todas as situações previstas. Daí com o Code Metrics você já pode combater o problema desde o inicio.



Unit Test

A criação de testes unitários integrada no VSTS garante a qualidade do código produzido de forma automatizada. Caso seja necessário alguma manutenção você terá a disposição todos testes já criados para rodar e verificar imediatamente se a mudança gerou algum tipo de impacto. Ao encontrar erros os mesmos são registrados como bugs no TFS e passam a constar nos relatórios de qualidade. Você pode facilmente criar um caso de teste clicando em cima de um método com botão direito e escolhendo a opção create Unit Teste conforme a figura 15. Na figura 16 você verifica o teste em ação validando seu bloco de código.


Figura 15 - Criando teste unitário

Figura 16 -  Teste em ação

Code Coverage

A falta de ferramentas adequadas leva a muitos erros e um deles muito comum é liberação de uma versão que aparentemente foi testada mais ao rodar no cliente em pouco tempo o mesmo já retorna “insatisfeito” porque aconteceu algum tipo de ação inesperada e você verifica em seu projeto refazendo seu passo a passo e diz pra ele “Aqui funciona”. Esse é um cenário comum de bloco de código não testado ou não coberto pela sua bateria de testes seja manual ou usando testes unitários.

Para tirar essa eterna duvida se realmente você está conseguindo testar todos os seus blocos de código principalmente se contém muitas instruções “if” você tem a disposição a ferramenta de cobertura de código com informações sobre a quantidade de código não testado e o referido bloco conforme figura 17 e figura 18 levando você diretamente ao código.

Figura 17 – Resultado da cobertura de código.

Figura 18 – Código colorido indicando a cobertura de código.

Analisando o código apresentado na figura 18 marcado em vermelho nós temos um bloco de código não testado que foi identificado pela ferramenta, agora você precisa realizar casos de testes complementares para atingir um nível de cobertura aceitável para seu projeto.

Relatórios

Conversamos no inicio que o Team Foundation Server funciona como um repositório acumulando as informações do ciclo de desenvolvimento. Essas informações após coletadas são disponibilizadas em diversas visões por meio do SQL Report Services que integrado ao portal do projeto funciona como grande base de consulta sobre a saúde do projeto. Confira na figura 19 um exemplo de relatório disponibilizado.

[
Figura 19 – Relatório sobre Bugs

Esse relatório trás o total de bugs ativos, novos bugs e bugs resolvidos. Um alto número de bugs encontrados já representa queda de qualidade em seu projeto que combinado a outros relatórios indicadores de qualidade como testes realizados  e cobertura de código você pode emitir um parecer imediato sobre a situação do projeto e como está o código fonte desenvolvido. Os gestores do projeto agora tem os mecanismos para cuidar da qualidade e já podem tomar providencias de imediato. Vale lembrar que esse é apenas um dos diversos relatórios oferecidos pela plataforma Team System.

Considerações Finais

Conforme você pode observou no decorrer desse artigo com a plataforma do Visual Studio Team System você terá a sua disposição um grande conjunto de ferramentas integradas que visão auxiliar a gestão do seu projeto proporcionando amplo controle sobre as atividades e sobre o código fonte desenvolvimento que é o principal bem do seu negócio e deve ser acompanhando em todas etapas do projeto para que se possa controlar os prazos e a qualidade do mesmo.

Referências
DURÃES, Ramon. (2009). Gerenciando projetos de software usando o Visual Studio Team System. Brasil: Brasport