O Programador Pragmático – Capítulo 2 – segunda parte

By Gabriel Rubens

E aí vai a segunda parte do segundo capítulo do livro que deve estar na cabeceira de qualquer programador: O Programador Pragmático.

Mais uma vez, esse resumo é uma anotação pessoal, e se é pessoal é influenciada por minhas experiências (meio obvio), então compre o livro que vale cada centavo investido.

Projéteis Luminosos

Essa parte do livro é simplesmente fantástica (eu já escrevi essa palavra várias vezes =P), mais uma vez começa com uma analogia que sobre os modos com que podemos dar um tiro no escuro, em resumo são:

Podemos calcular onde está o alvo, temperatura, umidade, fazer diversos cálculos, etc… E se o ambiente não mudar, o alvo não se mover, a temperatura estiver constante e assim por diante o tiro tem uma chance de chegar perto (hmmm, isso me lembra uma tal de “cascata”, ou um tal de RUP que é iterativo e incremental, mas que o levantamento tem que ser feito todo de uma vez “cascata com outro nome?!?!”, “argh!!”).

O segunda alternativa é a utilização de projéteis luminosos que são carregados junto com as balas comuns, só que estes deixam um rastro quando queimam, assim podemos ver se estão acertando o alvo, caso a responta seja positiva, as balas comuns também estão.

Acho que com essa analogia não precisa mais de comentários, só ler um pouquinho sobre Agile, entregas frequentes, ciclos pequenos e etc…

E já que estamos dando um tiro no escuro quando estamos construindo algo que outra pessoa pediu, nós podemos fazer do modo que manda o figurino: Levantar tudo que o sistema pode ter, escrever tudo em todos os diagramas que a UML tem, fazer contratos em que qualquer mudança que o usuário venha a pensar seja muito cara e burocrática. E não podemos esquecer da clausula que diga que se ele não gostar a culpa é dele, já que o documentação estava lá e ele assinou!

Ou podemos optar pro projéteis luminosos, a escolha de um Programador Pragmático, com pequenas partes feitas, testadas, integradas e apresentadas para o usuário e caso ele queira alterar já estamos preparados para isso.

A utilização de projéteis luminosos não garante que você irá acetar o alvo, mas garante que você terá o feedback rápido, e assim saberá se está perto ou não do alvo.

Utilizando Protótipos

Outra abordagem para verificação e validações é o esboço em protótipos, os protótipos podem ser feitos por ferramentas específicas ou um quadro branco (eu já utilizei HTML), os protótipos tem a função diferente dos projeteis luminosos, pois provavelmente será descartado. A grande vantagem da utilização de protótipos é que eles são mais baratos que a implementação final do sistema, assim ele permite um entendimento comum antes que as coisas sejam feitas.

Nem sempre os protótipos são das GUI, eles também podem referencias esboços da arquitetura em post-it. O livro apresenta algumas coisas que podem ser prototificadas:

Arquitetura

Nova funcionalidade em um sistema existente

Estrutura ou conteúdo de dados externo

Projeto de interface de usuário

Etc…

Outro ponto que deve ser lembrado é que os protótipos não são precisos, são apenas esboços e sendo assim não deve ser despendido muito tempo na sua construção.

O livro também deixa a dica de que quando optarmos em fazer as presentações por protótipos devemos deixar bem claro que ele não será reaproveitado. Do mesmo modo que um protótipo de um avião que é construído para testar a sua aerodinâmica não é utilizado em um voo.

Linguagens de Domínio

Após os protótipos o livro fala sobre Linguagens de Domínio, sobre como a linguagem de programação influencia no modo de solucionar o problema, e logo após os autores dizem que devemos aproximar a linguagem do domínio com a solução que será implementada na linguagem de programação.

A tema central dessa parte é que devemos programar o mais próximo possível da domínio do problema. Entre as diversas vantagens que há em utilizar esse estilo na programação podemos dizer da facilidade em manter a diálogo com quem conhece o domínio e quem está desenvolvendo o sistema.

E nessa parte eu fiquei devendo os exercícios já que não sei expressões regulares (vai pra lista de estudo).

Estimativas

Na parte de estimativa ele ensina a pensar da seguinte maneira: Primeiro entender bem o problema, depois disso é hora de construir um modelo mental do sistema que foi pedido. Depois de construir todo o modelo mental é hora de dividi-lo em componentes e pensar em quanto tempo esses componentes serão construídos. Outra dica é consultar um pessoa que já tenha feito algo semelhante ao que você está se propondo a solucionar, não que isso lhe de o tempo exato, mas desse modo você terá uma base dos problemas que podem surgir.

Outra coisa importante é sempre verificar o tempo que realmente foi gasto com o que foi previsto, essa é uma forma de acompanhar as suas habilidades e estivar.

Mais um dica: COMPRE O LIVRO!!

Gabriel Rubens

Postagens Relacionadas:

• O Programador Pragmático – Capítulo 2 – primeira parte
• O Programador Pragmático – Capítulo 1
• O Programador Pragmático – parte 8
• O Programador Pragmático – parte 6
• O Programador Pragmático – parte 7
• O Programador Pragmático – Resenha do prefácio
• Livro SCJP (guia de bolso)