Desafios do Projeto de Software

Este artigo é baseado em uma parte do quinto capítulo do livro Code Complete, por McConnell, 2ª edição

Esse foi um dos melhores livros que eu li sobre criação de software, cujos princípios não entram em obsolescência com o passar do tempo, ao contrário das implementações das linguagens de programação.

McConnel sabe o valor da metáfora no mundo abstrato da programação de computadores.

Ele inclusive trata disso em seu livro.

Eu também sou um grande adepto da metáfora como ferramenta de comunicação.

Sem metáforas, fica muito difícil discutir arquitetura de software.

Falar sobre milhares de linhas de código para uma equipe com a limitada capacidade de retenção de informação que temos não é prático.

Uma das primeiras metáforas que McConnel propõe é a de comparar a criação de sistemas de informação com a construção de edificações.

É melhor do que a métafora da escrita de documentos, pois leva o ouvinte ou leitor a imaginar (um real) esforço na criação de software.

Construir software não é uma tarefa fácil, pois há muitos desafios que tem de ser superados a cada projeto.

Mais do que otimizar algoritmos, é preciso organizar o software, para mantê-­lo funcionando depois que ele for colocado em produção.

128345994_e037b5a511_z

Segundo McConnel, o problema de software é um problema perverso!

Isso não quer dizer que os problemas que envolvem a construção de software são criados por supervilões.

Isso significa que você precisa resolver o problema uma vez para defini­-lo claramente, depois resolvê­-lo mais uma vez para criar uma solução que funcione.

O que implica dizer que você só irá compreender realmente o negócio que o software implementa depois que implementá-­lo pela primeira vez.

Não que a primeira versão só software seja errada, que não faça o que o cliente pediu.

Ela pode atingir os objetivos mas de uma forma inadequada.

E essa inadequação só será percebida quando uma modificação for solicitada e você perceber que é extremamente difícil modificar seu software.

E essa dificuldade só aumenta a cada novo lançamento.

Por mais planejamento que haja em um projeto de software, ele só controla o atendimento ao requisito e não o código que o implementa.

O código que implementa um requisito pode se dividir em várias funções ou classes, o que não permitirá ter conhecimento completo, com um simples olhar, de como o requisito é implementado em detalhes.

imagem-artigo-flavio-livro

Além disso, ocorrem bugs no software. E eles são corrigidos. E as correções geralmente aumentam a quantidade de código.

Como as correções geralmente são feitas de forma emergencial, elas não são implementadas da melhor forma possível e isso causa degradação do código.

Um código degradado é um código difícil de manter e que contém operações inúteis ou desnecessárias.

Após perceber que o código está degradado, geralmente quando você já não consegue mais entender o que o código faz, é necessário reorganizá-­lo, para torná-­lo compreensível e remover o que não é mais necessário.

E eventualmente corrigir um bug que paradoxalmente foi introduzido pela correção de outro bug.

Por isso o processo de software é um processo desordenado (mesmo que conduza a um resultado ordenado).

Você comete vários erros até distinguir a diferença entre uma solução boa e outra ruim.

Isso é natural quando precisamos entregar uma funcionalidade no prazo ou corrigir um bug de um dia para outro.

Você naturalmente age nessas condições como alguém que tem de fugir de alienígenas zumbis e precisa ligar o motor do primeiro carro que encontrar.

Você nem procura a chave, já faz uma ligação direta, porque sua vida depende disso.

Mesmo quando criamos software com tempo para planejamento, podemos não compreender realmente o contexto dos problemas a serem resolvidos, pois nossa visão é limitada.

E isso não é nenhum sintoma de burrice, é tão somente uma consequência da falta de experiência.

A compreensão de um problema às vezes exige a experiência de ter resolvido outro.

Isso é algo natural na ciência. A compreensão do átomo, por exemplo, foi sendo ampliada conforme os instrumentos de observação foram aperfeiçoados e os pesquisadores tinham conhecimento anterior para estender.

A solução de um problema em software só irá se revelar ruim se você tiver implementado essa solução.

Não é possível corrigir ou aperfeiçoar o que não existe.

Ao resolver o problema pela primeira vez, você não o compreende direito. Mas após estudar sua solução em funcionamento, o problema fica mais claro, e você percebe o que pode ser melhorado.

Ou seja, não espere que qualquer implementação em software seja definitiva, por mais planejamento que você faça. Ela sempre poderá e precisará ser aperfeiçoada.

Se os programadores de sua equipe não puderem assimilar isso, então Ultron terá razão ao dizer para eles: “Vocês querem salvar o mundo, mas não querem que ele mude”.

A mudança é a única certeza constante.

flisboa

Flávio Gomes da Silva Lisboa
No Code Squad, ministra os seguintes treinamentos: http://code-squad.com/perfil/flaviogomeslisboa#cursos-ministrados

Flávio é Bacharel em Ciência da Computação com pós-graduação em Aplicações Corporativas usando Orientação a Objetos e Tecnologia Java pela Universidade Tecnológica Federal do Paraná. Programador formado pelo Centro Estadual de Educação Tecnológica Paula Souza, já atuou em empresas privadas de TI e foi funcionário de carreira do Banco do Brasil, onde chegou a analista na diretoria internacional.

É funcionário do Serviço Federal de Processamento de Dados (Serpro), onde já trabalhou na Superintendência de Soluções de Desenvolvimento e na Coordenação Estratégica de Tecnologia. Atualmente é chefe do setor de adequação da solução e mobilidade do projeto Expresso 3 na Coordenação Estratégica de Ações Governamentais.

Foi membro do time oficial de tradução do Zend Framework e é autor dos livros: Zend Framework Desenvolvendo em PHP 5 Orientado a Objetos com MVC, Zend Framework Componentes Poderosos para PHP (2ª ed.) e Criando Aplicações PHP com Zend e Dojo (2ª ed.). É associado da ABRAPHP, Zend PHP Certified Engineer, Zend Framework Certified Engineer, Zend Framework 2 Certified Architectcontribuidor oficial do projeto Tine 2.0, suíte livre de comunicação em PHP.

 

 

Twitter

1 Comment

  1. Daniel Albino

    27/05/2015 at 12:33

    Sensacional, Flávio!
    O texto fez com que eu me sentisse um programador menos ruim. ;-)

Leave a Reply to Daniel Albino Cancel reply

Your email address will not be published.

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2017 Bussola Code Squad

Theme by Anders NorenUp ↑