Documentação não é digitação, e sim análise do problema

“Nada é tão fácil ou tão difícil quanto parece.”

 

Ultimamente venho me deparando com um problema muito grande no desenvolvimento de software e que afligem muitos dos desenvolvedores de sistemas. É a de fazer a documentação do sistema. Na verdade fazer a documentação não é o real problema, mas sim a forma como ela é feita e como ela está inserida no processo de desenvolvimento de software. Não vou entrar no grande pensamento filosófico de que a documentação é necessária ou se é perda de tempo ou que devemos fazer uma gama de diagramas ou apenas rascunhos no quadro branco. Aqui estou partindo da premissa de que a documentação tem uma importância de grande relevância para todo o processo de desenvolvimento de software.

Muitos desenvolvedores, gerentes e até mesmo clientes não dão a devida importância à documentação de um sistema e seu impacto dentro do processo de desenvolvimento de software. A maioria sempre acha que a documentação está em segundo plano, que quando o cronograma aperta podemos simplesmente pegá-la e jogá-la “fora” naquele momento até a entrega do sistema e depois voltarmos para trás e fazer toda a documentação como se estivéssemos apenas transpassando o sistema (código-fonte) para o Word, gráficos, matrizes, diagramas e etc.

E é aí que está o vilão da história. A maioria dos desenvolvedores, gerentes e clientes vêem a documentação como o grande empecilho na construção dos sistemas e por simplesmente acharem que ela é pura digitação ou como muitos chamam, “Desenhosinho”, ignoram que ela é o resultado fiel da análise do domínio do problema do sistema e que nela fica registrado a solução encontrada que satisfaz os requisitos necessários para o entendimento do negócio do cliente e a construção do sistema. Em muitos projetos já vi as maiores atrocidades feitas nos sistemas por simplesmente não fazerem a documentação da forma correta, ou seja, fazer a análise do problema e chegar a uma solução coesa que atenda o cliente de forma eficaz. Já me deparei com casos em que um plano de teste não é criado ou caso seja, não contempla todos os cenários de testes impactando dessa forma os testes de QA e de integração do processo de negócio que o sistema deve abranger. Simplesmente todo o processo de desenvolvimento de software é ignorado, pois a maioria dos desenvolvedores, gerentes e clientes não entendem ou não querem entender que cada documentação tem pré-requisitos que são as documentações criadas nas fases anteriores do desenvolvimento.

Como por exemplo, não podemos ter um plano de teste sem ter os casos de uso com as regras de negócio, assim como não podemos ter os casos de uso sem fazer uma análise do levantamento de requisitos e ter o mapeamento do domínio do problema. Isso sem mencionar nas demais documentações que também tem seus pré-requisitos. O que me preocupa muito é que muitos desenvolvedores se preocupam somente com o código, querendo simplesmente sair codificando que nem loucos. Se pelo menos durante a codificação fosse feita a análise do problema de forma clara e coesa, o sistema em termos de código, componentização, integração e arquitetura em geral seria bem feito, mas não é o que acontece. O que acontece é que caem no código sem se preocupar com esses detalhes e transformam o sistema em uma “colcha de retalhos” com muitas redundâncias e sem usar nenhum padrão de software, tornando assim a manutenção e a evolução do sistema muito difícil, pois além de não existir a análise do problema, não existe a documentação mínima necessária para entender o que o sistema faz e porque certas decisões na codificação foram adotadas.

Enquanto vivermos em um mundo onde os desenvolvedores de software acham que são excelentes programadores e não excelentes analistas de sistemas ou de negócio, estaremos fadados a reviver sempre os mesmos problemas no desenvolvimento de software.

Agilidade no Desenvolvimento de Software: Processo com Filosofia

Já faz um bom tempo que venho estudando sobre processos de desenvolvimento de software e suas conseqüências nos projetos e nas empresas sejam elas para o bem ou para o mal. E já faz um bom tempo que venho estudando o desenvolvimento de software ágil. Mas nessa minha vida corriqueira de desenvolvedor de software sempre vi e vejo as pessoas dizerem e bater o martelo que se não usarmos um processo de desenvolvimento ágil (XP / SCRUM / FDD e outras letras do alfabeto) estaremos fadados a ficar mergulhados em um processo burocrático e sem a menor flexibilidade durante o desenvolvimento do software.

Bem, em minha opinião eu discordo totalmente desse pensamento, pois como já me expressei antes, processos são feito de pessoas, boas práticas e ferramentas. Não adianta tentarmos inserir uma metodologia ágil em um ambiente despreparado que não irá rolar e as pessoas ficarão discutindo a validade de ser ou não ser ágil. Isso significa que podemos utilizar qualquer processo de desenvolvimento de software iterativo e incremental com aquelas letrinhas do alfabeto que também poderemos ser ágeis.

Hoje eu vejo que as pessoas confundem muito processo de desenvolvimento de software com agilidade no desenvolvimento de software. Quando eu li o Manifesto Ágil e o livro de Kent Beck (Programação Extrema Explicada), logo percebi que o que estava sendo inserido no desenvolvimento de software era uma nova visão de construir software, uma nova abordagem com novas práticas, ou seja, uma filosofia de vida e não um processo em si. Como exemplo, temos o próprio XP que prega várias dessas filosofias (valores): Comunicação, Coragem, Feedback, Respeito, Simplicidade e até várias práticas como: programação em par, desenvolvimento dirigido a testes, integração contínua, o usuário indicar a prioridade dos requisitos, documentação somente se necessário e quando necessário e etc.

Em qualquer processo de desenvolvimento de software iterativo e incremental existente hoje é possível trabalharmos com esses mesmos valores e todas as boas práticas para desenvolvermos software. Lembre-se sempre de que processo é feito de pessoas e para termos agilidade no nosso dia a dia precisamos de que as pessoas envolvidas nos projetos se conscientizem desta nova maneira de construir software, desta nova filosofia.

“Kaplaa!”

Design By Contract! Afinal de contas isso ajuda?

“A confiança entre as pessoas é como um fio de cabelo ao encontro de uma navalha.”

Não é de hoje que vejo muitos desenvolvedores de software discutirem sobre Design By Contract (DBC) e se realmente é necessário sua utilização. Até mesmo entre meus estimados amigos de profissão quando temos nossas conversas filosóficas regadas de muito chopp e salgadinhos em algum bar perto do trabalho, vem à tona esse tema bastante popular ou impopular dependendo da perspectiva do observador. Já ouvi muitas pessoas dizerem que utilizar DBC é pura perda de tempo, pois não ajuda em nada e apenas atrapalha o desenvolvimento do software delegando atribuições a outras pessoas onde a própria pessoa que criou um método poderia estar fazendo. Outros dizem que não gostam de seguir os conceitos do DBC porque não confiam no outro desenvolvedor (tornando a frase inicial uma verdade) e que ele provavelmente fará besteira, ou seja, não validará a pré-condição e o sistema de alguma forma poderá ficar inconsistente.

Mas com todo esse blá blá blá, afinal de contas DBC ajuda ou não? Para responder essa questão é necessário que voltemos aos princípios/conceitos da orientação a objetos que prega que um objeto/método deve ser altamente coeso, com baixíssimo acoplamento para com isso promover um altíssimo reuso. Bem, sabemos que para atingirmos um alto grau de coesão precisamos que o objeto/método faça exatamente aquilo que ele foi criado para fazer e nada mais e para atingirmos um baixo grau de acoplamento devemos dividir as responsabilidades de determinadas tarefas entre os objetos/métodos (Padrão GRASP).

Além dos conceitos expostos acima, temos o princípio da Não-Redundância que prega que não deve existir repetição no tratamento de determinada situação, ou seja, em um método existente ou a condição dos parâmetros e do estado (atributos) do objeto está expressa em pré-condição ou deve ser tratada pelo próprio método, mas nunca em ambas. Infelizmente eu já me deparei com códigos exatamente assim, cuja equipe de desenvolvimento não utilizava DBC. Um método criado por um desenvolvedor criticava todos os parâmetros de entrada com as possíveis situações que não poderiam acontecer para o método funcionar e os métodos que chamavam esse método e que foram criados por outros desenvolvedores também faziam a crítica para não passar valores inválidos para os parâmetros. Dessa forma existiam os seguintes problemas: códigos redundantes, perda de tempo dos desenvolvedores por codificarem algo que já existia, os métodos deixaram de ser coesos, pois faziam coisas que não deveriam, o grau de acoplamento era maior do que deveria e o reuso desses métodos ficou prejudicado.

Muitos desenvolvedores ao se depararem com essa situação dão a desculpa de que o problema é resolvido com um refactory do código, mas a verdade é que desenvolvimento baseado em refactory pressupõe que o refactory exista devido as iterações e dos incrementos que foi exigido durante o processo de desenvolvimento (desenvolvimento iterativo e incremental) e não do refactory existir por causa de código que não segue as boas práticas do desenvolvimento.

Com os princípios/conceitos e problemas expostos acima, posso responder a pergunta e dizer que de fato DBC ajuda e muito. Humm ok, mas no que ajuda? Bem vamos lá de novo. Utilizando a pré-condição determinamos de quem é a responsabilidade de efetuar a crítica tanto dos parâmetros quanto do estado dos objetos antes da execução do método. Com isso temos como ganho métodos mais coesos, menos acoplados e com um alto grau de reuso e sem redundância de código. Utilizando a pós-condição damos a garantia para o método cliente de que todo o processamento será realizado sem problemas e o resultado será o mesmo que o esperado (firmado no contrato do DBC). E estabelecer esses contratos é de grande importância quando estamos lidando com o mundo corporativo, principalmente em projetos com arquitetura orientada a serviços (SOA) onde não existe mais aquela visão de aplicação monolítica e sim de serviços dos mais variados níveis trabalhando em conjunto para executarem um processo de negócio (Leia aqui sobre SOA). Esses serviços devem ser muito coesos, sem acoplamento entre eles e com o máximo de reuso dentro do negócio do cliente e DBC ajudará em muito nessa tarefa.

Outra ajuda muito importante que o DBC nos dá é sobre manter a invariante da classe que é outro conceito de orientação a objeto. A invariante é a verdade absoluta e imutável de uma classe durante toda sua existência e como exemplo podemos utilizar o objeto Quadrado. Sabemos que um quadrado é feito de quatro lados de tamanhos iguais e isso é imutável, ou seja, essa é sua invariante. Então podemos utilizar a pré-condição para que não seja passado nenhum valor que torne a invariante falsa e utilizar a pós-condição para garantir que a invariante permaneça verdadeira após a execução do método.

Porém, muitos já me perguntaram como é possível controlar se a pré-condição está realmente sendo validada, se todos os desenvolvedores de uma equipe estão fazendo as críticas necessárias? Para essa questão devemos utilizar de TDD (Test-Driven Development) exaustivamente, pois se uma pré-condição/pós-condição/invariante está sendo quebrada é porque o código contém erros e com o TDD será possível descobrir e consertar esses erros. Note que a validação do uso de DBC com TDD tem grandes chances de sucesso em um cenário (que chamo de DBC Inside Project) onde os desenvolvedores são da mesma equipe. Existe outro cenário (que chamo de DBC Outside Project) onde é muito complicado ter DBC no seu máximo uso, que é quando existe equipes diferentes de consultorias diferentes para projetos corporativos que se comunicam.

Muitos defendem a idéia de que é quase impossível colocar pré-condição e esperar que ela seja validada por quem deveria. De que nesse caso seria melhor criticarmos dentro do próprio método para não deixarmos o sistema/serviço ou até mesmo uma base de dados inconsistente. Esse é um cenário que ainda não tenho resposta, apenas digo que o bom senso é sempre bem vindo, ou seja, utilizar DBC sempre que possível porque com certeza ajuda e muito.

“Jolan True.”

Processo Unificado vs Ágil: Ser ou não ser, eis a questão!!

Quem não conhece a famosa frase Ser ou não ser, eis a questão (no original, To be or not to be, that’s the question) que vem da peça A tragédia de Hamlet, príncipe da Dinamarca, de William Shakespeare? Incrível como até nos dias de hoje muitas vezes somos assombrados por essa dúvida cruel, principalmente nós meros mortais da área de desenvolvimento de software.

Em conversas de bares regados a chopp e salgadinhos com meus estimados amigos de trabalho e até mesmo lendo seus blogues (Gustavo Serafim, Marcelo da Costa Araújo, Philip Calçado, GUJ) sobre metodologia, processo unificado, processo ágil, RUP, XP, Scrum e as várias outras combinações do alfabeto, percebi que em muitas vezes ficamos apertando a mesma tecla e nunca saímos do lugar. Sempre vejo grandes batalhas serem travadas para chegar à conclusão de qual metodologia/processo é a melhor. Uns dizem que ser ágil é que trará os melhores resultados para os projetos, de forma que para essas pessoas devemos jogar fora toda papelada e se ligar no que realmente traz agilidade que é codificar/testar/refatorar. Já outros defendem que um processo onde não exista documentação apropriada, não se pode ter um maior controle sobre o andamento do projeto e seus inevitáveis desvios de prazo e orçamento, seja quando a equipe é grande ou ela está particionada em diversos lugares ou o projeto envolve diversas tecnologias e blá, blá, blá.

Vejo nos blogues e em muitos lugares grandes entusiastas para não dizer “religiosos” que crêem veementemente que o processo utilizado por eles é melhor do que aquele que eles não usam e que uma determinada metodologia é melhor do que a outra e blá, blá, blá. Mas nunca vejo demonstrarem a verdadeira preocupação que devemos ter ao lidar com metodologia/processo de desenvolvimento de software que é o pilar Pessoas/Boas Práticas/Ferramentas, ou seja, ao invés de ficarmos dizendo que uma é melhor que a outra, devemos nos atentar que sem pessoas treinadas para conhecer, praticar e respirar o processo, sem pessoas que utilizam de boas práticas de desenvolvimento de software e sem uma equipe com ferramentas disponíveis que apóie o processo, não adiantará de nada e continuaremos a bater cabeça contra a parede em cada projeto. E com isso todos nós nos veremos fazendo a mesma pergunta de sempre: Processo Unificado ou Processo Ágil, RUP ou XP, fazer análise ou não, modelar ou não, ser ou não ser. Essa com certeza é a grande questão dos dias de hoje para nós desenvolvedores de software.

Pilar do Desenvolvimento de Software

No nosso dia-a-dia podemos usar Use Case ou User Stories, ferramentas para UML ou rascunho no quadro, reuniões longas e chatas ou uma breve reunião diária (Standup Meeting), DDD, TDD, MDA, diagrama disso, diagrama daquilo, SOA, SCA, RUP, XP, AUP, EUP, Scrum e todas as várias outras combinações do alfabeto, que se não existir as premissas do pilar que mencionei, se as pessoas não aderirem às boas práticas de um processo de desenvolvimento, pode juntar tudo isso e jogar na lata de lixo. Eu sou uma pessoa que nos últimos anos vem tentando entender esse dilema que passamos e cheguei à conclusão que o melhor dos mundos não está em seguir somente um processo unificado ou somente um processo ágil, até mesmo porque podemos ser ágil sem usar XP ou Scrum e usando um RUP. Podemos tanto usar um RUP e customizá-lo para a necessidade de um projeto, podemos usar um XP/Scrum dependendo da situação, como também podemos usar um pouco de cada, utilizando as partes onde cada um é mais forte em determinadas situações. No final das contas o mais importante são as pessoas dentro do processo e as práticas utilizadas para chegar ao objetivo que é o software funcionando e o cliente feliz da vida.

Mas enquanto não aprendermos a usar o que realmente é necessário descartando o que não é essencial e abrir a mente para entendermos que cada situação requer estratégias diferentes e até processos diferentes, sempre estaremos nos perguntando: Ser ou não ser, eis a questão!

“Vida Longa e próspera.”