quinta-feira, 24 de março de 2011

É melhor ter um mapa


Conhecimento tácito é tudo aquilo que está na cabeça das pessoas mas não está escrito em lugar algum, ou que é difícil de colocar em palavras. É como receita pra fazer arroz, não tem nenhuma que explica tudo que você precisa saber. Se você tentar seguir, ele sai todo empapado.

Isso é uma das grandes pragas de qualquer projeto de software. Pense bem: toda empresa tem alguém que, se for embora hoje, deixa pra trás um punhado de coisas que ninguém mais sabe. Daí pra descobrir tudo é uma eternidade e muita dor de cabeça. Faça o seguinte exercício mental. Seu projeto está aí, seguindo em frente tranquilamente. Imagine que você quebrou as mãos e alguém entrou agora em seu projeto para te substituir. O que essa pessoa vai ler? Por onde vai começar? Quanto tempo ela vai levar para saber tudo que você sabe sobre o seu projeto?

A solução, é claro, é documentação. Nunca trabalhei em um projeto que eu considerasse bem documentado. Talvez em uma empresa que siga processos rígidos, com certificação CMMI ou equivalentes, a coisa seja diferente, mas nunca trabalhei em uma empresa assim. Se tem uma coisa que nunca é suficiente, é documentação.

Meu amigo Ademir gosta de dizer que não confia em documentação, só em código. Eu discordo. Aprender lendo código é difícil, cansativo e doloroso. É preciso algo que te mostre uma visão do todo, que explique como as várias partes se compõe. Entrar em um projeto novo é explorar um território desconhecido. Para não se perder tempo demais vagando sem rumo, é preciso um mapa.

A desconfiança do Ademir não é sem fundamento. Em última instância, a verdade está no código. É muito fácil deixar documentos ficarem desatualizados em relação ao código. Como dizem os exploradores, se o mapa e o terreno forem diferentes, acredite no terreno. O código é o terreno. Mesmo assim, mesmo sendo meio errado e impreciso, é melhor ter um mapa.

A maioria das pessoas não gosta de escrever documentação porque é difícil. Muitas das coisas que sabemos são difíceis de explicar de forma clara, difíceis de colocar em palavras, mas é preciso tentar. Não basta escrever código claro e bem escrito. Todo mundo precisa de um mapa.

4 comentários:

  1. Por isso que ferramentas que geram documentação a partir do código são legais: te lembram de atualizar a documentação quando você atualiza o código.

    ResponderExcluir
  2. Gostei. Documentar não é tão difícil assim. Documentação bem feita é como teste bem feito: acontece antes do código.

    Documentação bem feita diz claramente onde se quer chegar, a analogia com um mapa é ótima. Ela diz por onde você escolheu ir e quais decisões tomou. Quando é bem feita, também diz a razão por que se toma um caminho e não outro.

    Eu diria que documentação de sistema é mais parecida com uma carta marítima: com o tempo, os ventos e as correntes mudam, e o melhor caminho pode ser outro. Sem saber as forças que motivaram uma decisão de design, leva muito, muito tempo pra ter certeza de o código já não reflete os objetivos.

    ResponderExcluir
  3. Olá Torsten e demais colegas... Conversando com o Ademir, ele me apontou seu blog e achei muito legal seu post... Na verdade sou suspeito para "achar legal" o tema, pois minha linha de pesquisa no PPGCC da UFU (http://www.facom.ufu.br/posgrad ) é exatamente sobre este problema... O interessante é que concordo com ambas as visões: o código é a única fonte confiável (pelo menos para a maior parte dos sistemas), mas ninguém merece ficar depurando um sistema linha a linha para compreendê-lo. Além do mais, documentar software é caro, chato e vão ter dúvidas se sua documentação está consistente/adequada/etc.

    Mas então, qual a saída? Minha resposta tentativa é o uso de técnicas de Engenharia Reversa (ER) no código-fonte para obtenção da informação relevante para a tarefa de compreensão/manutenção do software. Não estou falando daquelas ferramentas que desenham diagramas de classes e sequência a partir do código inteiro. Não me interessaria ver um diagrama com 2000 classes no caso por exemplo do ArgoUML... seria preferível ver a árvore de pacotes, classes no IDE.

    Para quem tiver mais interesse, publicamos agora em 2011, 2 artigos com algumas soluções nesta área:
    1) CSMR http://www.se.uni-oldenburg.de/csmr2011/program.maintrack.runtimevolution.html#drivperfcha
    Neste artigo mostramos como foi possivel em 1 dia de trabalho inserir um novo diagrama (objetos) no ArgoUML com +130KLOC, inserindo cerca de 600 linhas, inserindo, reutilizando e alterando várias classes. A Luciana (aluna) de mestrado que conduziu a implementação não conhecia o Argo previamente... Apesar de não termos medido, eu não esperaria usando depuração fazer esta tarefa em menos de 1 semana, na melhor das hipóteses, porque até entender onde estão os pontos relevantes e como eles funcionam demoraria muito tempo.

    2) CIBSE http://cibse.inf.puc-rio.br/files/CIbSE_WER2011_Program.pdf
    Neste artigo, mostramos como é possível recuperar abstrações de alto nível a partir de rastros de execução... estas abstrações seriam como diagramas de sequência "arquiteturais"

    É claro que ainda temos falsos positivos e falsos negativos nestes tipos de abordagem, mas além de estarem diminuíndo com os novos trabalhos, os verdadeiros positivos tem se mostrado bastante úteis. Outra dificuldade é lidar na compreensão de algoritmos muito complicados... Daí é outro desafio... :)

    Os artigos acima ainda não estão disponíveis na web... quem tiver interesse mando por email (Marcelo Maia - UFU)... Desculpe a propaganda ;)

    ResponderExcluir
  4. Oi Marcelo,
    Legal sua linha de pesquisa, tem tudo a ver com o problema que eu coloquei no post.
    Aliás, vou estar na UFU dia 17/05 pra dar uma palestra, vamos ver se a gente se encontra pra almoçar.
    Um abraço,
    Torsten

    ResponderExcluir