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.”