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.