No último artigo discutimos basicamente sobre a "mania" que temos de sair escrevendo código, partindo diretamente da inspiração. Ok, eu concordo que há um pouco de arte em programar, talvez até por isso temos a expressão "o estado da arte em desenvolvimento", mas na minha opinião a nossa parcela de inspiração não é maior que a de Da Vinci: 10% de inspiração e 90% de transpiração.

O planejamento é uma das etapas mais importantes do processo de transpiração nodesenvolvimento de software. E mesmo na visão micro, ou seja, quando se trata da unidade básica que é um programa, é necessário planejamento. Com o tempo fomos condicionados a pensar grande, sempre em projetos, em grandes sistemas, em arquitetura de um sistema N camadas. Mas o que estamos discutindo aqui é a unidade básica de um sistema. Sim, o programa de 50 linhas também precisa de um planejamento.

Para fazer um bom planejamento é preciso prática e perseverança. Isto pode não ser fácil ou tão divertido quanto programar, mas é extremamente necessário para o sucesso do programa.

Lembro–me de um curso de PSP (Personal Software Process) que fiz no CITS alguns anos atrás. O PSP é uma metodologia de desenvolvimento de software desenvolvida pelo mesmo instituto que criou o CMM, a Carnegie Mellon University.

Os exercícios se baseavam em escrever programas que implementavam algumasfórmulas matemáticas. Antes de iniciar a codificação do exercício era necessário fazer um plano de desenvolvimento, estimando o número de linhas de código, o tempo necessário, o número de erros previstos, escrever um pequeno algoritmo para detalhar a lógica e outros dados acerca do programa.

A grande sacada era que o programa deveria ser escrito do início ao fim sem compilar nenhuma vez. Naquela época eu era um recém formado e acreditava que este processo estava totalmente errado e seria ineficiente.

Na minha concepção seria muito mais fácil fazer algumas linhas de código e compilar, fazer mais algumas linhas e compilar e assim por diante até chegar ao final do programa com alguns poucos erros. Mais uma vez eu estava errado.

Quando se programa linha a linha e compila, estamos mudando o nosso foco de desenvolvimento de uma implementação matemática para uma luta com o compilador, como discutimos no artigo anterior (veja ao lado). Quando comecei a fazer a codificação do programa do início ao fim, eu parei de brigar com o compilador e centralizei meus esforços na lógica para resolver os problemas. Nos primeiros exercícios, gastei muito mais tempo e linhas de código que eu havia previsto. No décimo eu já estava bem mais apurado e errando bem menos a previsão, gastava mais tempo planejando e menos tempo codificando.

O resultado final era que eu desenvolvia mais rápido por ter que corrigir menos erros. Demorava um pouco mais até termos um programa funcionando, mas em compensação o tempo de testes e correção era bem menor.

Esta é uma boa prática a ser desenvolvida nas empresas e universidades – incentivar o programador a fazer planejamento do código, mesmo que o programa faça apenas um parser de XML ou apenas abra um arquivo em Java. Se você começar a utilizar está prática de planejamento garanto que verá resultados em menos tempo que imagina. Não é necessário usar UML ou uma notação específica; faça desenhos, escreva num rascunho a lógica de negócio, faça você mesmo as anotações que você entenda e seja prático e útil.

É preciso também alertar aos clientes, que apesar do prazo ser importante, é crucial ter um sistema bem escrito e que funcione. Não é preciso ter em sua equipe desenvolvedores com mestrado ou doutorado, os recém formados são ótimos para assimilar novos conceitos e com um pouco de treinamento já estarão aptos a escrever códigos mais limpos e mais funcionais.

Vale a pena lembrar de uma das máximas da Engenharia de Software: Quantomais tarde encontrar um bug num sistema mais caro é para corrigi–lo.

Existem hoje diversas metodologias de desenvolvimento de software e qualquer uma delas é melhor que a metodologia NRNC (na raça e na coragem). Isto é, abrir uma página em branco e começar a batucar no teclado escrevendo o código.

Pablo Picasso foi um dos maiores artistas de todos os tempos e tem uma das obras mais vastas do mundo, incluindo pintura, desenho, poemas e cerâmica. Ele chegava a pintar mais de um quadro por dia e viveu até os 92 anos. O que tem a ver Picasso com programação?

Picasso planejava um quadro durante meses antes de colocar na tela. Com sua técnica ele podia terminar um quadro em apenas um dia, mas o tempo de concepção do quadro, o planejamento, poderia durar muito mais tempo, às vezes meses na escolha das cores.

Há outra semelhança entre Pablo Picasso e área a de computação: Talvez por causa de um impulso em criar novos quadros a partir de novas idéias, Picasso é criticado por não finalizar suas obras. Ele produziu muito, mas apenas alguns de seus quadros realmente foram concluídos; na área de computação existem diversos projetos assim. Com certeza esta é uma semelhança que nós não gostaríamos de ter. [web insider]

Respostas

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

+

  1. Wallace Souza

    Outra excelente abordagem!!
    parabéns!!
    sobre o artigo,costumo comentar com amigos meus que, desenvolvedores psicografam códigos ou esquecem o design de seus módulos pq seus códigos não incluem vida de outras pessoas,imagine se aquele código que vc poderia ter feito refactor mas não fez por ventura foi responsável por um acidente aéreo??
    Não importa o quão simples seja sua solução em software,mal planejado ou mal desenhado,só implicará na qualidade de seu serviço,o que não lhe impedirá em um serviço maior,repetir os mesmo erros.
    Analogia as grandes navegações
    Planejar/design é importante,viver nem tanto…