Este artigo foi dividido em três partes com muitas verdades inconvenientes sobre código versus produto, “PO imaginário” x “PO real” e documentação versus conhecimento. Veja também a Parte 01 e a Parte 02.

Documentação versus conhecimento

A palavra “documentação” gera arrepios na maioria de desenvolvedores que eu conheço. E não é sem razão.

Documentação virou sinônimo de processo pesado. De páginas e páginas de formulários que devem ser preenchidos e que nada agregam a um projeto. E que geram uma tremenda falsa segurança aos gestores.

Digo falsa segurança porque geralmente a documentação é encarada pelos “não desenvolvedores” como uma espécie de snapshot do cérebro do projeto. Você tira aquele snapshot, aplica-o em outra equipe em outro lugar diferente e ela continua o desenvolvimento onde o mesmo tinha parado, uma espécie de backup do projeto inteiro.

E isso nós sabemos que é uma grande bobagem. É impossível registrar todas as nuances, todos os detalhes de um projeto de desenvolvimento em papel ou em qualquer outra mídia.

Então, documentação é bobagem, certo?

Não, não é bem assim. O problema é o que se convencionou chamar de documentação. Diria mais, o problema é o nome “documentação”.

Documentar com a visão “snapshot” que citei acima seria como tentar registrar uma viagem anotando cada passo, cada parada, cada acontecimento, de forma que se alguém precisasse continuar a viagem do mesmo ponto, essa pessoa não teria problemas.

Um projeto envolve uma miríade tão grande de acontecimentos que, mesmo se fosse possível registrar todos, não seria viável absorver tanta informação.

Porém, seguindo a metáfora da viagem, informações sobre terreno, clima, fauna e flora são sempre úteis. O mapa não é o território, mas ajuda brutalmente a interagir como mesmo.

E é aqui que voltamos para a questão do artigo anterior, onde falei “Superestimamos a tecnologia. Subestimamos a complexidade do negócio”.

O código em si não precisa (ou pelo menos não deveria precisar) ser documentado. Ele deve ser legível, limpo, derivado de um jargão e baseado em um domínio coerente. O código e, por consequência, o software é um reflexo do negócio.

Uma visão/proposta excelente é a feita por Eric Evans com seu D.D.D. (Domain Driven Design). Evans trouxe a importância do domínio para o centro do palco e com ele a questão da linguagem ubíqua.

Dos diversos dialetos que formam uma empresa, seria forjada uma linguagem que atendesse ao domínio como um todo e que dessa maneira atenderia a todos os stakeholders.

Então se o software é o domínio e se o domínio é um reflexo do negócio, é o negócio que precisa ser documentado. Ou melhor, não o negócio, mas o tratado de paz negociado pelo P.O. (o real, não o imaginário, citados na segunda parte do artigo), isto é, aquela visão que atende a todos os interessados.

Com isso em mente, o caminho para um projeto de sucesso não seria a documentação, e sim a criação de diversas visões que representassem não só a realidade atual do negócio como a que se espera alcançar com o término do desenvolvimento e que evoluirá através de suas futuras manutenções.

Mas como representamos esse conhecimento?

Essa é a verdade inconveniente desse post. Não existe um jeito padrão, que funcione bem para todos os casos. Não existe uma solução simples. Cada viagem/expedição é única e tem maiores chances de sucesso quando se possui mais informações sobre a mesma.

Defendo aqui que, da mesma maneira que criamos uma linguagem ubíqua do domínio, alinhando todos os conceitos e jargões que compõem o mesmo, precisamos criar uma linguagem ubíqua do projeto e que será utilizada por ele.

Pessoas são diferentes e se comunicam de maneiras diferentes. Algumas entendem melhor de textos, outras entendem melhor de imagens etc.

Conteúdos são diferentes e são representados de formas diferentes. Alguns devem ser fotografados, outros gravados.

O alinhamento dessas duas variáveis (Pessoas x Conteúdos) irá formar a linguagem ubíqua do projeto. Serão os “mapas” (que prefiro chamar de artefatos de construção de conhecimento) do “território” (que é o domínio). De posse desses “mapas”, as pessoas conseguirão andar com mais tranquilidade no território.

O P.O. é o cartógrafo que constrói os mapas que os desenvolvedores utilizam em suas expedições. E, à medida que o território muda, os mapas são atualizados. Afinal, o software muda porque o negócio muda, ou porque a nossa compreensão dele evolui.

Um projeto de sucesso:

• Partiria de visões fragmentadas do negócio, profundamente influenciadas pela rotina;
• Determinaria a melhor maneira de representar tanto a visão atual como a futura;
• Desenvolveria uma visão unificada do negócio que atendesse a todos os stakeholders;
• Daria origem a um software que atendesse a essa visão unificada;
• E, de posse da visão unificada, seria mais fácil determinar os pontos de alteração do software quando o domínio precisasse ser alterado.

E viajar sem mapas é uma roleta russa. Se chegar ao lugar desejado, você teve sorte.

Conclusão

Um projeto de software deve ter por base o negócio. Somente o conhecimento dele (via seus stakeholders) gera um software que torna o projeto um sucesso. E esse conhecimento (de negócio) deve ser construído (no P.O.) e representado (com uma linguagem ubíqua)

Código bonito é bom, mas não irá nos salvar. Software que atende ao negócio sim.

Espero que tenham gostado e até o próximo!