Posts Tagged ‘Design Patterns’

Mais 10 livros recomendados para desenvolvedores

Monday, March 3rd, 2014

Lá atrás em 2008 escrevi um post sobre 10 livros recomendados para desenvolvedores. Na época o post foi bastante popular e eu sempre pensei em escrever uma continuação, que acabei nunca fazendo.

Enfim, a hora chegou e aqui vai mais uma lista de outros 10 livros recomendados para desenvolvedores! Mas antes disso, alguns detalhes sobre como cheguei nessa lista:

Por que apenas 10 livros e não 20 ou 30? Não sei dizer – o primeiro post foi assim então vou continuar. :) O bom é que isso me deixa uma quantidade de livros mais do que suficiente para no futuro escrever vários posts!

Por que essa lista tem livros sobre “processos” como Kanban ou Lean? Não era para ser livros para desenvolvedores? Não tenho pretensão de escrever aqui uma lista definitiva e restrita a apenas um tópico, mas sim listar alguns livros que pessoalmente acho importantes para desenvolvedores de software e que me marcaram de alguma forma. Nosso trabalho não é só programar direito mas também saber se organizar (ou organizar um time) para que se entregue mais software, com mais qualidade e em tempo recorde, portanto acho esses tópicos super importantes.

Por que um livro sobre JavaScript e nenhum sobre Ruby, Python, Java ou qualquer outra? Tem alguma preferência de linguagens rolando aí? Não tem preferência não. O “Good Parts” é sensacional porquê me fez entender e respeitar JavaScript de um jeito completamente diferente. Não acredita? Leia o livro então! Acha que é perda de tempo? Eu acho que não, JavaScript hoje em dia é uma das linguagens mais populares e é indispensável conhecê-la bem para fazer desde um simples website como este blog até gigantes como Yahoo e Facebook.

Por que todos os livros são em inglês? 99% de toda a literatura relevante de tecnologia é em inglês e em muitos casos não há tradução disponível, portanto se você ainda não está craque, pule esta lista e vá urgentemente aprender inglês antes de mais nada! De todas as linguagens (de programação ou não) que você pode pensar em aprender, essa é provavelmente a mais importante.

Clean Code: A Handbook of Agile Software Craftsmanship Clean Code: A Handbook of Agile Software Craftsmanship
Robert C. Martin
Test Driven Development: By Example Test Driven Development: By Example
Kent Beck
Growing Object-Oriented Software, Guided by Tests Growing Object-Oriented Software, Guided by Tests
Steve Freeman e Nat Pryce
Code Complete: A Practical Handbook of Software Construction Code Complete: A Practical Handbook of Software Construction
Steve McConnell
Working Effectively with Legacy Code Working Effectively with Legacy Code
Michael Feathers
JavaScript: The Good Parts JavaScript: The Good Parts
Douglas Crockford
Kanban: Successful Evolutionary Change for Your Technology Business Kanban: Successful Evolutionary Change for Your Technology Business
David J. Anderson
Lean Software Development: An Agile Toolkit Lean Software Development: An Agile Toolkit
Mary Poppendieck e Tom Poppendieck
The Lean Startup: How Today The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
Eric Ries
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
Jez Humble e David Farley

Alguns pensamentos sobre “documentação ágil”

Monday, September 20th, 2010

Existe um mito de que não se documenta em projetos que usam metodologias de desenvolvimento ágil. Não é bem assim, aliás, não chega nem perto de ser verdade.

A grande diferença entre projetos “tradicionais” e de desenvolvimento ágil é que os processos tradicionais geralmente são bastante prescritivos e você tem que documentar tudo que estiver definido no processo (que geralmente é muita coisa). Você não pensa no que está fazendo, simplesmente segue o que foi definido e escreve documentos. Em métodos ágeis não há prescrição de documentação (e o manifesto ágil fala também sobre “software funcionando mais do que documentação”), mas isso não significa que você não pode documentar nada. Muita gente confunde isso e diz que nunca se deve documentar em projetos “ágeis”, o que é um grande engano. Em projetos ágeis você pode documentar sem problemas desde que seja necessário de fato. A idéia é que você não deve perder tempo com nada que não seja requerido de verdade para o projeto.

Já participei de projetos onde documentar foi extremamente necessário. Por exemplo, uma vez trabalhei num projeto com vários times onde nem sempre os desenvolvedores estavam no mesmo espaço físico, portanto era preciso documentar alguns pontos chave da arquitetura e ambiente para que todos pudessem trabalhar sem problemas. Também já participei de situações onde meu time desenvolvia componentes que precisavam ser usados por outros times, e esses componentes precisavam estar bem documentados para que os outros times pudessem trabalhar adequadamente. Note que isso é totalmente diferente de documentar o projeto inteiro ou escrever dezenas de casos de uso. Documentamos apenas o que fazia sentido ser documentado.

Enfim, há diversas situações onde você pode precisar documentar por diversos motivos. Para te ajudar a decidir quando documentar e como documentar, veja a seguir alguns princípios do que chamei de “documentação ágil”. Essas são apenas algumas práticas úteis e princípios importantes que observei ao longo do tempo em diversos projetos de que participei. Certamente existe muito mais do que isso, mas vamos lá:

Documentação não substitui comunicação

Em projetos tradicionais, muitos documentos são usados para comunicar idéias entre o Analista e o Programador, com QA e por ai vai. Em desenvolvimento ágil o objetivo da documentação é registrar as informações por outros motivos (como os motivos acima). Se você estiver se comunicando por documentos, você já deixou de ser ágil há muito tempo. Documentação não deve ser usada para substituir a comunicação intensa e constante entre os membros do time.

Documentação não pode ser perecível

Documentação tem que ser leve e não pode ser perecível, ela deve ser durável. Se você documenta algo que precisa ser modificado todo dia, existem grandes chances de você esquecer de atualizar a documentação e ela passa a ficar desatualizada. É melhor não ter documentação do que ter documentação errada. Além disso, se você precisa mudar a documentação toda hora significa que você está se aprofundando demais nos detalhes, e então a documentação vai “quebrar” a cada linha de código que você escrever. Quando estiver documentando, pergunte-se: “daqui a algum tempo essa documentação ainda será válida?”. Faça documentação durável. Não entre num nível de detalhe que te faça mudar a documentação o tempo todo (a não ser que você realmente precise disso – e mesmo assim pense se não dá pra fazer de outro jeito, por exemplo, automaticamente).

Documente o necessário, e não mais do que isso

Assim como você deve implementar apenas o necessário para entregar uma funcionalidade e não mais do que isso, você deve documentar apenas o que for necessário e nada mais do que isso. Não perca tempo escrevendo documentação que nunca será usada por ninguém. Se ninguém precisa usar a documentação, então ninguém deve documentar. Documento tem que ter um motivo, documentar sem uma necessidade real não faz sentido

Documentar tem que ser fácil

Documentar tem que ser rápido, não pode dar trabalho. Use ferramentas como wikis, geradores de documentação (como o Sphinx) e por aí vai. Se for fácil documentar, as chances de você fazê-lo serão maiores. No caso de não usar wiki (ou alguma coisa online/web), use ferramentas para publicar a documentação automaticamente. Se a documentação for fácil de ser acessada (e tiver busca) ela fica mais útil. Além disso, prefira usar uma tecnologia fácil e conhecida para que todos os membros do time possam documentar. Por exemplo, se você escolher usar LaTeX, você está reduzindo as chances de designers documentarem, pessoas de negócio e outros membros não-programadores de um time.

Documentação faz parte do “Definition of Done”

Se o seu projeto precisa de documentação por qualquer motivo, a documentação deve fazer parte da “Definition of Done”. É melhor documentar no momento que as histórias estao sendo desenvolvidas – quando o conhecimento está fresco na cabeça – do que acumular um monte de débito e ter que pagar de uma vez só – quando você vai precisar conferir um monte de coisas que já estão prontas para documentar com precisão, o que vai te dar mais trabalho e consumir mais tempo.

Documentação no código pode ser um “code smell”

“Code smell” é um sintoma no seu código que pode indicar um problema maior. Muitas vezes códigos precisam ser documentados porque eles são desnecessariamente complexos. Sempre que possível prefira refatorar o código para ele ficar mais fácil de entender ao invés de escrever comentários (até porque muitas vezes o código muda e o comentário fica lá desatualizado, e isso acaba mais atrapalhando do que ajudando). Tenha uma boa suite de testes (uma suite bem escrita e organizada é uma especificação executável), use Domain-Driven Design para expressar melhor o domínio do software, metáforas, tenha um design simples, use design patterns, enfim, é melhor fazer com que o software seja mais bem escrito e não mais bem documentado.

10 livros recomendados para desenvolvedores

Thursday, March 27th, 2008

No início do ano escreví um post sobre a importância de nós, desenvolvedores de software, lermos livros, que rendeu boas discussões. Depois disso recebí algumas mensagens perguntando quais são os livros que considero mais importantes para um desenvolvedor.

Bom, essa pergunta é complicada de responder. Primeiro porque eu ainda não lí todos os livros que deveria, e segundo porque cada pessoa tem seu gosto particular por tecnologias, processos, frutas e etc.

Então, resolví criar a lista dos 10 livros que eu particularmente mais gosto e que recomendo fortemente para qualquer desenvolvedor. Estes livros são alguns dos que mais me influenciaram a melhorar minha forma de trabalhar e programar. Além disso, coloquei link para os sites, blogs ou páginas de informações dos autores, caso alguém ainda não tenha:

Agile Software Development, Principles, Patterns, and Practices Agile Software Development, Principles, Patterns, and Practices
Robert C. Martin
Agile Software Development with SCRUM Agile Software Development with SCRUM
Ken Schwaber e Mike Beedle
Design Patterns: Elements of Reusable Object-Oriented Software Design Patterns: Elements of Reusable Object-Oriented Software
Erich Gamma, Richard Helm, Ralph Johnson e John M. Vlissides
Domain-Driven Design: Tackling Complexity in the Heart of Software Domain-Driven Design: Tackling Complexity in the Heart of Software
Eric Evans
Extreme Programming Explained: Embrace Change (2nd Edition) Extreme Programming Explained: Embrace Change (2nd Edition)
Kent Beck e Cynthia Andres
Introduction to Algorithms Introduction to Algorithms
Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest e Clifford Stein
The Mythical Man-Month: Essays on Software Engineering The Mythical Man-Month: Essays on Software Engineering
Frederick P. Brooks
Patterns of Enterprise Application Architecture Patterns of Enterprise Application Architecture
Martin Fowler
Peopleware: Productive Projects and Teams Peopleware: Productive Projects and Teams
Tom DeMarco e Timothy Lister
The Pragmatic Programmer: From Journeyman to Master The Pragmatic Programmer: From Journeyman to Master
Andrew Hunt e David Thomas

Infelizmente todos os livros são em inglês e nem sei se existe tradução. Se você não souber inglês, matricule-se urgentemente em algum curso porque saber inglês nesta área é muito importante!

Convido vocês a também fazerem suas listas e compatilharem seus livros preferidos :)