Marcos Sousa’s Blog

Nos últimos três meses tive a oportunidade de ler dois ótimos livros relacionados a desenvolvimento ágil. Com abordagem envolvente ambos os livros conseguiram manter minha concentração nas madrugas mesmo após dias estressantes no trabalho. Acredito após a leitura dos dois livros acabei aperfeiçoando minhas técnicas de desenvolvimento, tanto a nível de design de solftware quanto minha postura diante processos.

O livro Agile Software Development, Principles, Patterns, and Practices escrito pelo Robert Martin aborda alguns conceitos de XP e foca bastante em mostrar as vantagens de usar abordagens TDD com intuito de criar códigos mais legíveis e reutilizáveis. Particularmente, o primeiro estudo de caso foi o melhor, mostra detalhadamente passos de refatoração como nomes de métodos mais claros, extrair classes, métodos. Martin introduz cinco princípios:

• SRP – Single Responsabity Principle
• OCP – Open Closed Principle
• LSP – Liskov Substitution Principle
• DIP – Dependence Inversion Principle
• ISP – Interface Segregation Principle

Se você deseja escrever códigos melhores, recomendo ler estes cinco princípios. Além destes cinco princípios, o livro aborda diversos patterns conhecidos da literatura, mas em uma abordagem diferente. E sempre com um estudo de caso para aplicar os patterns abordados. Muito bem estruturado.

Esta semana finalizei a leitura do livro Agile Software Development with Scrum. Quando eu comprei este livro, pensei que ele abordava os conceitos do Scrum. Por outro lado há dicas de algumas atitudes a serem tomadas Daily Meetings, Sprint Plannings que evitam situações que conduzem ao fracasso do projeto.

Do início ao fim do livro há relatos de estudos de casos de sucesso mostrando como o Scrum mudou o rumo de diversos projetos. Este livro ajudou a consolidar minha opinião de que para implantar o Scrum ou qualquer outro método ágil em um projeto é preciso de uma disciplina forte. São muitos mitos a serem quebrados, e dependendo da organização e da maturidade do time é uma tarefa um pouco complicada.

Exemplo: não é fácil reunir-se diariamente no mesmo horário e durante 15 minutos exatos. E por ser uma situação que evidencia para todo o time a produtividade do desenvolvedor, alguns profissionais começam a criar resistência (através de atrasos as reuniões) tornando-se um grande risco durante os primeiros projetos.

É como Ken Schwaber diz em em seu último parágrafo, em outras palavras: “Scrum não é para todos apenas para pessoas dispostas a matar ‘leões’ diariamente”.

Como a vida não pára, agora vou quero aprofundar um pouco mais os meus conhecimentos em Ruby principalmente em Rails. Além de artigos, o user guide, estou começando a ler o livro do Rodrigo Urubatan, e pelas primeiras páginas que já li, o livro parece ser bem legal, assim que finalizar a leitura deixo aqui meus 5 centavos.

Observando o comportamento em vários projetos, pude perceber que grande parte das pessoas não dão muito valor aos testes, e quando valorizam atribui a responsabilidade de testar a outras pessoas. As coisas ainda ficam piores quando chega a pequenas empresas. Pergunte ao dono da padaria que você toma café todos os dias, se eles testaram alguma funcionalidade do software que eles tem antes de colocar em produção? Se a versão tiver algum problema e corromper os dados, a culpa sem sombra de dúvidas será do time de desenvolvimento.

O problema começa no modo como as pessoas projetam o software, dentro de um processo Waterfall, onde cliente não é parte do processo. Neste contexto, o cliente diz o que deseja e depois de 9 meses ele tem um resultado: um software produzido nas “coxas”.

Mesmo em projetos onde existem práticas de testes, muitos deles ainda são ineficientes. O usuário apenas valida as “telinhas” do sistema, e muito pouco em termos funcionalidades. Infelizmente, poucos destes usuários testam o comportamento de entradas de dados inválidos, por exemplo, um campo de CPF aceitar “-1″ como valor, ou um espaço em branco ser um conteúdo válido para um campo obrigatório. Como resultado, o sistema chega a produção, dados inconsistentes são inseridos e a culpa é do desenvolvedor.

Testes unitários é algo que muitos desenvolvedores ainda acham inútil, quando fala em integração contínua, aí acham exagero. Quer um exemplo, pergunte à um programador PHP se ele faz teste unitários. “Faço apenas sites, não sistemas, não preciso disso”, nem fazem idéia de que existe o PHPUnit para este propósito. Mesmo dentro de um obsoleto modelo cascata, cheio de casos de usos, porque não criar testes unitários pelo menos para validar os fluxos principais e alternativos? Pelo menos o fundamental pode ser controlado por um sistema de integração contínua.

Meu objetivo não é falar que práticas, como TDD, são perfeitas. O que eu quero chamar a atenção é importância que o teste tem dentro de um processo de desenvolvimento de software. Aparentemente, gastar algum tempo a mais fazendo testes, pode ser mais eficaz do que ter que corrigir uma falha que foi para produção por pura falta de atenção. Testar não é fácil e rápido, porém corrigir bugs pode ser mais demorado ainda.