Planejamento!
10/08/2001 0:00Por:
Picasso diria ao desenvolvedor que mesmo um simples programa de 50 linhas precisa de planejamento.
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]