Capítulo 4 - Fundamentos do Desenvolvimento de Software (parte 3)
Autor: Alexandre de Miranda | Publicado: 2011-07-21T01:33:00-03:00

Design

Algumas vezes é traduzido como projeto, outras, como desenho. Nenhuma das duas palavras, na minha humilde opinião, expressa com precisão o que deve ser realizado nesta atividade.

Projeto é uma palavra de origem latina (pro- + jecto), cujo significado literal seria algo como "lançado (jecto) adiante (pro-)". Costuma ser empregada para descrever qualquer atividade que envolva alguma preocupação em avaliar/estabelecer/limitar outras atividades futuras. O resultado é o seu emprego em situações muito diversas, o que conduz a um relativo esvaziamento semântico e a uma imprecisão conceitual.

A palavra desenho, por outro lado, sugere fortemente a existência de algum artefato gráfico, o que não é necessariamente verdade. 

A meu ver, tanto projeto quanto desenho não se prestam ao jargão técnico por não serem capazes de delimitar, com satisfatória precisão, as preocupações com as quais deve lidar esta atividade. Pessoalmente, evito empregar palavras estrangeiras quando há equivalentes no português (os fãs do Aurélio que me perdoem, mas leiaute é uma das maiores excrescências que já tive o infortúnio de ver) mas no presente caso, estamos diante de uma escolha difícil.  Talvez esboço, por indicar que ainda se trata de um rascunho, de  uma expectativa, de linhas gerais, fosse mais adequada, porém o seu  emprego entre profissionais de TI não é comum na acepção de "descrição de algo que se pretende construir e como se pretende construir".

De certo modo, a falta de um nome adequado sugere a falta de importância que esta atividade tem. Interessante notar que o autor aponta que também nos EUA esta é a atividade mais relegada. Durante seis anos, 200 pessoas foram entrevistadas para o cargo de projetista na Microsoft e destes, apenas cinco foram capazes de descrever razoavelmente os significados de modularização e&nbsp; ocultação de informações.

Sem o adequado domínio destes conceitos, não é possível discutir consistentemente a divisão em subsistemas, a organização em camadas, componentização.

Dentre as grandes preocupações do projeto/design podemos citar:
 Metodologia de projeto: orientada a objetos, desenvolvimento estruturado, orientado a dados
Arquitetura de software: uso de frameworks, divisão em camadas, divisão em subsistemas
Adoção de padrões: tratamento de situações complexas mas corriqueiras tais como tratamento de exceções, internacionalização, portabilidade entre plataformas
Tratamento de requisitos críticos: baixo tempo de resposta, alta disponibilidade,&nbsp; segurança, baixo consumo de recursos

Grandes sistemas foram desenvolvidos sem projeto/design, mas a custos bem superiores ao necessário. O projeto/design é fundamental para as outras atividades e para o aumento da velocidade de desenvolvimento.

Construção

Tanto a gerência de requisitos quanto o projeto/design podem reduzir mais significativamente os custos do projeto do que a construção. A construção oferece poucas oportunidades para a redução de prazos, mas se não for convenientemente conduzida, pode acarretar em aumentos drásticos dos custos e dos prazos de entrega.

Omissões no levantamento de requisitos ou falhas de projeto/design levam a reconstrução de grandes partes dos sistemas. Falhas na construção levam a programas confusos e de difícil depuração.

Aspectos tipicamente concernentes à atividade de construção:
 normas de codificação e documentação
orientações quanto ao emprego de tipos de dados: CPF é sempre string, por exemplo
regras de empacotamento de código
normas para teste unitário e depuração
estratégia de integração
estratégia para otimização
recomendações de emprego específicas da linguagem adotada: boas práticas da linguagem
A adoção de padrões de construção consome algum tempo, mas economiza tempo quando consideramos o projeto com um todo. Boas práticas de construção possibilitam que qualquer codificador do projeto altere ou corrija um programa, mesmo quando o "dono" do programa não está disponível.

Trabalhei com manutenção de sistemas por alguns anos. Eram programas com 5 ou 6 anos de idade, desenvolvidos e alterados por diversas pessoas com níveis técnicos e estilos de codificação variados. Uma prática simples mas que me ajudou bastante foi passar a executar um formatador de código nos fontes antes de proceder qualquer alteração. Infelizmente, outros programadores da equipe, já habituados ao formato de alguns programas, consideravam a prática irritante.&nbsp;

Mais uma vez o problema do peopleware, ou seja, tomei uma medida isoladamente, sem considerar eventuais impactos sobre outras pessoas. Se tivesse sabido administrar melhor a equipe, provavelmente teria aumentado a produtividade de todos e não teria causado desconforto a ninguém.

Gerência de Configuração de Software

Tipicamente, é vista como controle de versão de códigos-fonte, porém abarca muitas outras atividades além desta. Podemos citar a avaliação das mudanças propostas e o controle de versão de outros artefatos.

Assim como outras práticas apresentadas anteriormente, a gerência de configuração de software faz com que o esforço de desenvolvimento do software aumente em relação ao caminho feliz (hipótese absolutamente teórica na qual o desenvolvimento ocorre sem qualquer percalço). Qualquer um que já tenha apagado acidentalmente um trecho de código pouco usado ou que promovido alterações desastrosas em um programa sabe como é bom poder recorrer ao controle de versões para identificar o que foi alterado.

Felizmente, atualmente é bastante improvável alguém conduzir um projeto, mesmo de pequeno porte, sem empregar os recursos básicos de alguma ferramenta para controle de versão dos programas-fonte. Talvez porque o custo de adotar ferramentas como SVN, GIT e outras assemelhadas seja muito baixo em relação aos benefícios imediatos.&nbsp;

A adoção de práticas de gerência de configuração mais sofisticadas, todavia, requer amadurecimento. A ausência de benefícios imediatos para os encarregados de executar os procedimentos dificulta a sua implantação.