Programando em equipe – Parte1

O desenvolvimento de um software consiste em um grupo de pessoas manuseando os mesmos arquivos fontes e componentes. Se um indivíduo deste grupo não conseguir escrever a sua parte de forma clara, de fácil compreensão e manutenção, o projeto estará comprometido a uma série de conseqüências problemáticas. Entendo que isso é uma situação de peso, uma vez que a manutenção representa em média 80% do tempo de vida de um sistema.

Ao longo das consultorias em projetos de que venho participando, diagnostiquei que os programadores em geral não sabem o significado de se “Programar em Equipe”. Percebo que é um problema de nível cultural e acredito que isso possa ser revertido se cada um pensasse da seguinte forma:

Eu estou trabalhando em uma equipe, por isso eu tenho que me esforçar ao máximo para implementar este requisito da forma mais simples, clara e de fácil manutenção possível…porque haverá algum momento no ciclo de vida do desenvolvimento que um companheiro de equipe precisará alterar ou complementar o que eu fiz e inevitavelmente eu também precisarei manusear algum código que foi construído por outra pessoa.

Acredito que o fato acontece por 3 motivos:

  • Pessoas remanescentes de outras tecnologias/ferramentas nas quais não existiam esta filosofia.
  • O desconhecimento de que na tecnologia Java existe um padrão de codificação.
  • A falta de uma sólida base de princípios de projeto orientado a objeto.

1. Pessoas remanescentes de outras tecnologias/ferramentas nas quais não existiam esta filosofia:

Eu percebo que atualmente existe uma galera muito inteligente e esforçada que vem migrando de outras tecnologias para o Java e que realmente tem conseguido produzir softwares funcionais, entretanto 100% deles deixam muito a desejar neste ponto. Percebo que o pessoal traz seus costumes e hábitos de programação para dentro do Java.

2. O desconhecimento de que na tecnologia Java existe um padrão de codificação:

Em Java existe uma forma padrão de como se deve ser escrito um código fonte. Ou seja, o autor não tem a liberdade de ficar usando/inventando uma série firulas, gafs, comentários, regras de espaçamentos sem coerências, delegação de nomes para identificadores completamente malucos etc….. Existe um documento chamado “Java Code Conventions” que possui todas as regras e diretrizes previamente estudadas e estabelecidas para que qualquer pessoa em qualquer lugar no mundo possa escrever o mesmo código fonte. Isto quer dizer o que? Quer dizer que uma pessoa de um lado do mundo pode abrir o código fonte de uma outra pessoa, do outro lado e ter a sensação de que ela mesma que escreveu! Sendo que ambos devem seguir a convenção de codificação.

3. A falta de uma sólida base de princípios de projeto orientado a objeto:

Fácil manutenção está intimamente ligada à utilização de princípios e diretrizes da filosofia orientada a objetos e é aqui onde o galera mais deixa a peteca cair! Como é incrível ver o pessoal mesmo usando uma tecnologia OO conseguir programar usando conceitos procedurais/globais e fazer uma coisa simples OO virar um monte de macarrão trançado. Sempre lembrando que a POO é uma filosofia e pode ser furada fácil, fácil, em qualquer parte do projeto.

Segue abaixo a lista resumida dos erros mais comuns:

* Estado do objeto – Não use variáveis de instâncias para controle de fluxos locais! Variável de instância é usada para definir estado do objeto durante seu ciclo de vida. Caso precise controlar algo localmente, use variáveis locais.

* Declaração de variáveis – Somente declare e inicialize as variáveis locais antes (o mais próximo o possível) de serem usadas! Único momento onde é aceitável declarar uma variável muito longe de sua utilização é em caso de utilização fora de escopos de controle de fluxo ou loop. Mesmo assim, mantenha em mente que você deve declarar sempre o mais perto possível.

* Escopo de variáveis – Sempre reduza os escopos das variáveis o máximo possível! Nunca declare uma variável fora de um escopo lógico (while, if, do/while, for) se você só vai precisar da variável dentro dele.

* Nomeação de variáveis – Independente do seu escopo (instância ou local), os nomes das variáveis devem ser auto-explicativos! Não coloque nomes sem sentido ou com apenas um caractere! Único lugar aceitável para se colocar uma variável com um único caractere é no contador de um for, o resto tem que possuir um nome significativo dentro do contexto de implementação. Outra coisa, não faça nomes grandes demais, resuma ou procure um sinônimo menor.

* Nomeação de classes e métodos – Nome de classe geralmente é um substantivo que reflete a abstração da automação de alguma coisa do mundo real, e os nomes dos métodos devem ser verbos que refletem ações que um objeto da classe faz. Qualquer coisa que passar disso fará com que o projeto fique completamente ilegível e confuso! Única possibilidade de exceção a este caso seria a possível utilização de design patterns dentro da arquitetura.

fonte: fernando franzini-imasters

:: LUCIANA COSTA ::

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s