Coisas de engenheiro

Quem me conhece já deve ter me visto reclamando do quanto eu achei a cadeira de Engenharia de Software um lixo durante a faculdade. Eram infinitos diagramas e documentos que não pareciam levar a lugar algum e nem ajudar qualquer desenvolvedor a pensar no problema de escrever um software. A cadeira foi basicamente o semestre inteiro conhecendo diagramas (que também tivemos de efetivamente usar -- apesar de não nos ajudarem no fim das contas a realmente desenvolver o programa) e, só no fim, aprender um pouquinho sobre o que realmente me interessava: métodos ágeis (que foram apresentados na correria porque, pelo que lembro, a gente tava atrasado na matéria).

Em oposição a essa cadeira, eu lembro que eu tinha gostado até que bastante de ter aprendido, primeiramente em Lógica e depois novamente em Semântica Formal, a provar a corretude de um programa com base no seu código. É claro que as provas só seriam "possíveis" para programas relativamente curtos, e isso significaria que eu teria de sempre ou criar abstrações fortes o suficiente e simples o suficiente para provar que funcionavam ou então simplificar o meu programa. Além disso, questões como paralelismo e orientação a objetos tornavam a coisa bem mais complicada =/ (e estavam "fora do escopo" da disciplina xP)

Ainda por mais um terceiro lado, eu lembro de ter aprendido muito (MUITO) lendo boa parte de um livro do Bertrand Meyer (Object-Oriented Software Construction, 2ª Ed., 1997) ao longo da disciplina de Técnicas de Construção de Programas. Eu tinha aprendido que esse cara "disregarded" a maior parte das frescuras de UML que a gente tinha aprendido em Engenharia de Sofware, porque simplesmente elas não eram formais o suficiente e não ajudavam com problemas que ele apontava ao longo do livro.

Enfim... o que eu quero dizer através desses primeiros parágrafos é que, ao longo da minha graduação, eu construí um "desprezo" bem grande por "coisas de engenheiro" (i.e., diagramas, tabelinhas, check-lists, ... [eles usam a palavra "ferramenta" e têm um tom todo formal pra se referir a essas coisas]). Meu grande argumento sempre foi que, por englobar sempre um bom tanto de subjetividade, elas nunca garantem 100% de eficácia. Além disso, elas apresentavam um ar de formalismo que não condiz com o nível de subjetividade que eles internalizam. Um grande exemplo, pra mim, é a formalidade com que em geral a engenheirada trata o formato de cada um dos tipos de caixinhas possíveis em um fluxograma [sério que o "if" precisa ser tratado por um losango? Por que não um hexágono? Ou uma bolinha? Ou por que não tratar tudo como bolinha? u.u]. A mesma formalidade eu via na UML u.u

Cada vez mais, por outro lado, eu tenho percebido que, sim, essas coisinhas realmente funcionam. Não por causa do formato, pelas bolinhas, pelos diagramas, mas porque elas ajudam a se estruturar o pensamento e se pôr no papel de forma um pouco mais bem estabelecida cada uma das coisas que se pretende fazer. Por exemplo, é muito mais fácil enxergar o passo-a-passo de um processo através de um fluxograma; dado o fluxograma, é muito mais fácil indicar em que pontos o processo pode ou não apresentar falhas (e que falhas são essas); dadas essas falhas, é muito mais fácil escolher que falhas tratar através do diagrama de Pareto [que, aliás, foi um treco que me fizeram descobrir que eu achei bastante legal e útil]; é muito mais fácil encontrar os motivos das falhas através dos 5 porquês; e finalmente é muito mais fácil definir um plano de ação através do 5W2H.

Me sinto, assim, desconstruindo um preconceito =) Agora só falta eu desconstruir o que tenho com psicologia, que, da mesma forma, nunca me mostrou funcionar u.u (eu sempre desacredito dessas "coisas de psicóloga" v_V)

Era isso...

R$