Atualizando o conhecimento

Olá amigo,

lendo seu texto, logo me veio a dúvida: Como você pode desenvolver sem saber UML? Qual a linguagem de comunicação sua com um analista?

Eu acho que você deveria começar por um livro de certificação SCJA. Eu tenho um que comprei no amazon, porém ele está disponível apenas em inglês. É um ótimo livro, aborda algumas coisas superficialmente, mas o que você vai ter que aprender é o que está sendo introduzido no livro, não resumidamente, mas com um apronfudamento.

Depois você pode pegar livros específicos de cada tópico e ir aprofundando os conhecimentos.

Abraços

dohko:

Olá amigo,

lendo seu texto, logo me veio a dúvida: Como você pode desenvolver sem saber UML? Qual a linguagem de comunicação sua com um analista?

Eu acho que você deveria começar por um livro de certificação SCJA. Eu tenho um que comprei no amazon, porém ele está disponível apenas em inglês. É um ótimo livro, aborda algumas coisas superficialmente, mas o que você vai ter que aprender é o que está sendo introduzido no livro, não resumidamente, mas com um apronfudamento.

Depois você pode pegar livros específicos de cada tópico e ir aprofundando os conhecimentos.

Abraços

Então cara, nesse tempo de desenvolvimento que eu tive eu ainda não tive que me comunicar com os analistas, meus gerentes/chefes/lideres faziam isso…infelizmente nunca especifiquei nada, nem tive contato com a UML no dia-a-dia.
Na verdade eu até sei um pouco do que aprendi na faculdade, mas se for pra fazer alguma coisa na prática mesmo eu não vou saber me virar…

Gabriel,

UML é legal pra se comunicar. Acredito que você pode começar lendo o UML Distilled do Martin Fowler porque é um livro que te ensina UML de uma maneira bem legal. Como eu disso no começo, é boa pra se comunicar. Dessa forma, não pense que UML é documentação.

Eu acredito que a lista que o shoes fez é muito boa. Acho que, como você não conhece DP, você deve comprar os dois livros que falam de Design Patterns (ou só o segundo, do Gamma et. al - esse é bom você comprar porque uma vez ou outra você vai recorrer a ele quando surgir alguma dúvida - isto é, mesmo você conhecendo os patterns, você “voltimeia” recorre ao livro). Se você não faz testes unitários e não programa em Java, comece usando xUnit e comprando um livro de testes (não somente de testes unitários, mas também de TDD (Test Driven Development) - são coisas diferentes). Depois disso, seria legal ler o PEAA (aquele que tem nome grande, o Patterns of Enterprise Application Architecture, do Fowler) e o Domain Driven Design, do Eric Evans (eu nunca li, mas muita gente diz que é bom).

Como você pode ver, são todos livros retirados do post dele. Eu meio que arrumei uma ordem pra você ler (que é como eu faria).

Acredito que depois dessa leituras, você se sentirá muito mais seguro pra desenvolver software. Eu ainda não trabalho (último ano da faculdade), mas conheço UML e já li os de Design Patterns e o de Refatoração (não quero dizer que você está atrasado, nem nada). Posso dizer que depois que li o de Refatoração (não totalmente) e me senti 10x mais seguro ao desenvolver alguma coisa (principalmente fazendo testes unitários).

Boa leitura e qualquer dúvida, posta aí!

Abraço.

Andre Brito:

Gabriel,

UML é legal pra se comunicar. Acredito que você pode começar lendo o UML Distilled do Martin Fowler porque é um livro que te ensina UML de uma maneira bem legal. Como eu disso no começo, é boa pra se comunicar. Dessa forma, não pense que UML é documentação.

Eu acredito que a lista que o shoes fez é muito boa. Acho que, como você não conhece DP, você deve comprar os dois livros que falam de Design Patterns (ou só o segundo, do Gamma et. al - esse é bom você comprar porque uma vez ou outra você vai recorrer a ele quando surgir alguma dúvida - isto é, mesmo você conhecendo os patterns, você “voltimeia” recorre ao livro). Se você não faz testes unitários e não programa em Java, comece usando xUnit e comprando um livro de testes (não somente de testes unitários, mas também de TDD (Test Driven Development) - são coisas diferentes). Depois disso, seria legal ler o PEAA (aquele que tem nome grande, o Patterns of Enterprise Application Architecture, do Fowler) e o Domain Driven Design, do Eric Evans (eu nunca li, mas muita gente diz que é bom).

Como você pode ver, são todos livros retirados do post dele. Eu meio que arrumei uma ordem pra você ler (que é como eu faria).

Acredito que depois dessa leituras, você se sentirá muito mais seguro pra desenvolver software. Eu ainda não trabalho (último ano da faculdade), mas conheço UML e já li os de Design Patterns e o de Refatoração (não quero dizer que você está atrasado, nem nada). Posso dizer que depois que li o de Refatoração (não totalmente) e me senti 10x mais seguro ao desenvolver alguma coisa (principalmente fazendo testes unitários).

Boa leitura e qualquer dúvida, posta aí!

Abraço.

Quanto a Design Patterns, leia primeiro o Head First Design Patterns. O livro “Design Patterns: Elements of Reusable Object-Oriented Software” é um clássico, mas muito maçante.

Já comprei o PoEAA mas ainda não tive tempo de ler.

Portugues

andrepestana:

Andre Brito:

Gabriel,

UML é legal pra se comunicar. Acredito que você pode começar lendo o UML Distilled do Martin Fowler porque é um livro que te ensina UML de uma maneira bem legal. Como eu disso no começo, é boa pra se comunicar. Dessa forma, não pense que UML é documentação.

Eu acredito que a lista que o shoes fez é muito boa. Acho que, como você não conhece DP, você deve comprar os dois livros que falam de Design Patterns (ou só o segundo, do Gamma et. al - esse é bom você comprar porque uma vez ou outra você vai recorrer a ele quando surgir alguma dúvida - isto é, mesmo você conhecendo os patterns, você “voltimeia” recorre ao livro). Se você não faz testes unitários e não programa em Java, comece usando xUnit e comprando um livro de testes (não somente de testes unitários, mas também de TDD (Test Driven Development) - são coisas diferentes). Depois disso, seria legal ler o PEAA (aquele que tem nome grande, o Patterns of Enterprise Application Architecture, do Fowler) e o Domain Driven Design, do Eric Evans (eu nunca li, mas muita gente diz que é bom).

Como você pode ver, são todos livros retirados do post dele. Eu meio que arrumei uma ordem pra você ler (que é como eu faria).

Acredito que depois dessa leituras, você se sentirá muito mais seguro pra desenvolver software. Eu ainda não trabalho (último ano da faculdade), mas conheço UML e já li os de Design Patterns e o de Refatoração (não quero dizer que você está atrasado, nem nada). Posso dizer que depois que li o de Refatoração (não totalmente) e me senti 10x mais seguro ao desenvolver alguma coisa (principalmente fazendo testes unitários).

Boa leitura e qualquer dúvida, posta aí!

Abraço.

Quanto a Design Patterns, leia primeiro o Head First Design Patterns. O livro “Design Patterns: Elements of Reusable Object-Oriented Software” é um clássico, mas muito maçante.

Já comprei o PoEAA mas ainda não tive tempo de ler.

É verdade. Acho que o do Gamma et. al. serve mais como um livro de consulta do que como um textbook como os da série Head First.

Abraço.

GoF é de consulta mesmo, ainda assim ele é bem pesado. O que gosto mesmo é a introdução do livro, antes do catálogo, é a melhor leitura de teoria de orientação a objeto que conheço.

PoEAA é bem mais leve e mais aplicável, se você conhece arquiteturas corporativas, vai entendê-lo bem, no estilo “ah, já fiz isto!”.

Refatoração do Fowler é ótimo, nem parece que também é um livro-catálogo, gostei muito também.

Utilizando UML e Padrões, do Craig Larman - Ainda estou lendo. Apesar do nome, é um ótimo livro de análise orientada a objetos. Também recomendo. Talvez quem nem gosta de ouvir falar de Unified Process vá chiar

---

Domain Driven Design do Eric Evans é outro que estou seco atrás pra ler. Vou ter que pedir na Amazon mesmo e ler em inglês.

Tenho que lembrar de ficar menos na web e mais nesses livros.

dohko:

Como você pode desenvolver sem saber UML? Qual a linguagem de comunicação sua com um analista?

Hmmm, com um pouquinho só de criatividade dá pra se expressar muito melhor com analistas sem se limitar pelas regras da UML.

Um livro bom pra ajudar nisso é o Back of the Napkin (tem uma palestra do autor aqui também)

s4nchez:

dohko:

Como você pode desenvolver sem saber UML? Qual a linguagem de comunicação sua com um analista?

Hmmm, com um pouquinho só de criatividade dá pra se expressar muito melhor com analistas sem se limitar pelas regras da UML.

Um livro bom pra ajudar nisso é o Back of the Napkin (tem uma palestra do autor aqui também)

Cara, que legal essa palestra. Eu recomendo.

Eu costumo ir até a mesa deles, puxo uma cadeira, sento e começo a conversar. Funciona muito bem.

E pra quem acha que estou sendo sarcástico, pior foi um me falar que, em quase 10 anos que está na área, fui um dos primeiros a fazer isso, discutir e reanalisar o projeto.

É mole?