12 de abr de 2014

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$

2 comentários:

  1. Haha, entendo bem esse preconceito. Acho que ele é causado por um “mismatch” entre como o negócio é apresentado, o que a pessoa espera dele, e o que ele realmente faz.

    Também não sou muito fã de engenharia de software e, embora não esteja no momento me sentindo desconstruindo um preconceito, admito que alguns diagramas, em algumas situações podem ser bem úteis para “pensar direito” e comunicar as ideias a outras pessoas.

    Meu exemplo preferido de diagrama “inútil” era o diagrama de casos de uso:

    Reclamação 1: “Eu não preciso de um curso superior para aprender a fazer bonequinhos e bolinhas com texto dentro. Eu poderia reinventar esse diagrama sozinho na primeira série!”

    Reclamação 2: “Dá pra fazer a mesma coisa e muito mais rápido com listas em texto puro, atores e suas tarefas.”

    Mas a ideia abstrata do diagrama, isto é; mostrar que existem vários tipos de usuários, e várias tarefas que cada um pode fazer; é útil para documentação e comunicação com os outros envolvidos no projeto. Se for explicado que a parte útil da coisa não é o formato de losango do if ou a oval do caso de uso, mas sim a visão que eles apresentam do projeto, aí sim fica mais fácil gostar do negócio.

    Aliás, losango é um formato horrível pra escrever dentro, sempre falta espaço. :-)

    ResponderExcluir
    Respostas
    1. HUEHAUEHA... é é... justamente. Agora, que eu to "aberto" ao uso dessas coisas e, sem influência externa (que me diga que "o formato tem que ser um losango ou então tá errado", por exemplo), usando-as, eu to aceitando mais o seu uso.

      [desculpa a demora pra responder: eu tenho respondido só nos fins de semana, e o feriadão da semana passado não contou como "fim de semana" direito pra mim -- minha próxima postagem vai provavelmente falar sobre isso]

      Excluir