Aos poucos no meu dia a dia sinto que preciso de mais conhecimento em metodologia/arquitetura de software.
Hoje eu tenho algum conhecimento em UML, Design pattern (li o livro do GoF e do J2EE Pattern), um pouco de XP e muito pouco sobre TDD (embora eu tento utilizar JUnit o máximo possivel).
Gostaria de me aprofundar em certos assuntos, tais como XP, Scrum, TDD, DDD e outras coisas a mais que vocês acham necessário para ser um bom arquiteto.
Por isso, venho aqui pedir a ajuda do pessoal experiente no assunto, para indicar os livros de leitura obrigatória.
Recomendo MUITO o livro do Evans. É um livro clássico que todos devem ler. É preciso atenção porque apesar de bem escrito, alguns trechos dele são complexos para quem nunca passou pelo tipo de problema que ele descreve.
Patterns of Enterprise Application Architecture by Martin Fowler
O livro é dividido em duas partes. A primeira mostra uma visão macro da arquitetura de software. A segunda são os patterns citados no livro explicados individualmente.
Tem algumas coisas antigas sim porém muitas atuais. Ajuda bastante também como refêrencia, inclusive durate a leitura do DDD.
[quote=alex.lopes]
Gostaria de me aprofundar em certos assuntos, tais como XP, Scrum, TDD, DDD e outras coisas a mais que vocês acham necessário para ser um bom arquiteto.[/quote]
Alex, todo mundo hoje em dia quer ser arquiteto quando na verdade deveriam estar focados em ser bons profissionais do desenvolvimento de software em geral.
Escreví o artigo “O Papel do Arquiteto” na MJ chamando alguns caras de fora exatamente para dizer que:
Arquitetos têm que ter experiência vasta (desenvolver vários sistemas diferentes)
Arquitetos têm que ter experiência longa (como disse no artigo, bons arquitetos que conheço tem mais de 10 anos de experiência)
Arquitetos têm que ter características interpessoais como liderança, solução de conflitos, pragmatismo, comunicação.
Os livros vão te ajudar, mas experiência é mandatório para ser um bom arquiteto. Pra falar a verdade, Arquiteto é só um papel. As vezes tive que desempenhá-lo sozinho (como faço agora), mas prefiro uma equipe que possui o papel de arquiteto “compartilhado” entre todos.
[quote=rodrigoy]
Alex, todo mundo hoje em dia quer ser arquiteto quando na verdade deveriam estar focados em ser bons profissionais do desenvolvimento de software em geral.[/quote]Assino em baixo.
[quote=rodrigoy]1. Arquitetos têm que ter experiência vasta (desenvolver vários sistemas diferentes)
2. Arquitetos têm que ter experiência longa (como disse no artigo, bons arquitetos que conheço tem mais de 10 anos de experiência)
3. Arquitetos têm que ter características interpessoais como liderança, solução de conflitos, pragmatismo, comunicação.[/quote]IMO, muito bem resumido.
Concordo contigo Rodrigo
Um bom arquiteto não vai surgir apenas depois de ler uma série de livros, mas certamente a leitura irá ajudar a ganhar conhecimento.
O que eu busco com esse tópico é realmente saber quais os livros que podem me ajudar a obter conhecimento sobre os assuntos acima, não que eu vá virar um Master Arquiteto, mas que irá me ajudar a conhecer conceitos que hoje são obscuros para mim. E tenho certeza que conhecendo esses conceitos, meu lado “desenvolvedor” também irá evoluir.
Se alguém tiver alguma sugestão sobre livros com os assuntos de Scrum, TDD, Patterns e cia, e queria compartilhar com o pessoal, sinta-se à vontade em postar aqui.
Muito bem observado. Pensando nos arquitetos que só arquiteteiam sem se envolver com código, me lembrei dos ivory-tower architects do livro Release It! do Michael Nygard que por coincidência recebi ontem. Segundo ele, bons arquitetos são os pragmáticos que vestem também a camisa dos desenvolvedores. Estou gostando muito do livro.
[quote=alex.lopes]Concordo contigo Rodrigo
Um bom arquiteto não vai surgir apenas depois de ler uma série de livros, mas certamente a leitura irá ajudar a ganhar conhecimento…
[/quote]
Sobre Scrum, os livros do Ken Schwaber são bons (indico o Agile Software Development with Scrum). Agora, esses livros são mais fáceis de entender depois que você já viu centenas de projetos falharem miseravelmente nas mãos de gestores covardes e burros.
Sobre TDD, é difícil explicar, o pessoal fala bem do livro do Vinicius Teles, mas particularmente eu não lí… Leia Kent Beck. Mas TDD só se aprende fazendo, experimentando e perguntando. Acho que TDD dá pra aprender lendo artigos na Internet e praticando.
Patterns recomendo Eric Evans, Martin Fowler, GOF, Jimmi Nilsson. Até o Head First Design Patterns é bom, apesar dos exemplos toscos…
[quote=rodrigoy][quote=alex.lopes]Concordo contigo Rodrigo
Um bom arquiteto não vai surgir apenas depois de ler uma série de livros, mas certamente a leitura irá ajudar a ganhar conhecimento…
[/quote]
Sobre Scrum, os livros do Ken Schwaber são bons (indico o Agile Software Development with Scrum). Agora, esses livros são mais fáceis de entender depois que você já viu centenas de projetos falharem miseravelmente nas mãos de gestores covardes e burros.
Sobre TDD, é difícil explicar, o pessoal fala bem do livro do Vinicius Teles, mas particularmente eu não lí… Leia Kent Beck. Mas TDD só se aprende fazendo, experimentando e perguntando. Acho que TDD dá pra aprender lendo artigos na Internet e praticando.
Patterns recomendo Eric Evans, Martin Fowler, GOF, Jimmi Nilsson. Até o Head First Design Patterns é bom, apesar dos exemplos toscos…
[/quote]
E desse, o que acha:
Título: Refatoração - Aperfeiçoando o Projeto de Código Existente
Autor: Fowler, Martin
Editora: Bookman
Me encontro na mesma situação. Só que com apenas 2 livros pela metade. O Padrões de Projeto em Java e o de XP, do Beck. Vou acabar esse do Beck e manterei o de padrões na geladeira para começar o Projetos de Software, do Braude.
Nunca pensei que fosse tão difícil programar direito. Ou como diz o Fowler: “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
Uma simples questão de qual a metodologia melhor para atuar com servlets já me deixa confuso.
Mas acho que seja uma fase passageira. Lembro de quando comecei a aprender Java. Tinha a sensação de que não estava aprendendo nada. Hoje eu acho que eu estava certo.