Posts Tagged ‘Domain-Driven Design’

Estamos contratando no Yahoo! Brasil

Thursday, November 18th, 2010

Estamos contratando desenvolvedores para o Yahoo! Brasil!

Nosso time é responsável pelo desenvolvimento e manutenção do Yahoo! Meme. Para trabalhar conosco é imprescindível ser faixa preta em Python, PHP ou JavaScript e conhecer pelo menos uma segunda outra dessas três. Mesmo sendo essas as principais linguagens que usamos por aqui, precisamos de desenvolvedores multidisciplinares que saibam usar diferentes tipos de ferramentas – porque nunca sabemos quais produtos virão no futuro e que tipos de vantagens poderemos ter usando ferramentas diferentes.

Tão ou mais importante do que isso é ter ótimos conhecimentos sobre desenvolvimento ágil (especialmente XP), conhecer ferramentas de testes unitários, ser capaz de trabalhar com TDD, entender sobre CI e a sua importância, automatização de rotinas/build/etc., melhores práticas de desenvolvimento de software, Orientação à Objetos, Domain-Driven Design e tudo mais que puder ser relevante para ajudar a construir software confiável e manutenível de forma rápida e com ritmo/qualidade sustentável. Experiência com automatização de testes com Selenium ou Webdriver também é essencial. Como trabalhamos com web, também é necessário ter conhecimento em HTML, CSS e desenvolvimento de aplicações cross-browser.

Como desenvolvemos produtos de escala mundial, é necessário ter experiência com aplicações de alta performance e disponibilidade, identificação e otimização de gargalos de performance, escalabilidade, caching e sharding. É importante também ter bons conhecimentos de pelo menos um tipo de Unix e seus derivados.

Conhecimentos em C, C++, arquitetura de serviços, desenvolvimento de mashups, experiência com uso e desenvolvimento de APIs (REST, YQL, etc.) e experiência em desenvolvimento para iPhone/iPad são bons diferenciais, porém não são requeridos.

Para estas posições é necessário saber inglês bem, o que quer dizer que você deve ser capaz de conversar e ler/escrever em inglês sem problemas (e eventualmente ser entrevistado em inglês caso necessário).

Estamos procurando por pessoas criativas, que gostem de inovação, de pesquisar e identificar novas tendências e de encarar desafios complexos com agilidade e velocidade. Nosso time é pequeno, jovem e nosso ambiente está em constante mudança e evolução. Queremos pessoas irreverentes, que gostem de desafios, com idéias novas e com vontade de criar produtos incríveis!

A empresa oferece contratação apenas por CLT e benefícios como plano de saúde e vale refeição. Estamos localizados na Vila Olímpia em São Paulo. Geralmente contratamos pessoas de outros estados, mas desta vez infelizmente só estamos contratando pessoas de São Paulo/Capital. Update: Voltamos a contratar pessoas pessoas de outros estados e oferecemos auxílio para mudança (passagem, hospedagem, etc.).

Se você se encaixa neste perfil, envie seu curriculo em inglês para mim (gc AT yahoo-inc.com) com uma lista dos últimos 3 livros técnicos que leu. Não esqueça de colocar links para o seu Twitter, LinkedIn, GitHub e o que mais você achar relevante e que pode nos ajudar a te conhecer melhor. :)

Update: mais detalhes sobre a vaga (em inglês) na página de desenvolvedores do Meme.

Como anda o seu inglês?

Tuesday, October 5th, 2010

Há não muito tempo uma pessoa me procurou no IM para conversar sobre sua carreira. Ela me disse que no momento estava fazendo um curso de Java e me perguntou o que exatamente ela precisava para trabalhar numa empresa como o Yahoo!. Conversamos sobre algumas coisas até que perguntei sobre seu inglês. Para minha surpresa, ela disse que o curso de inglês iria ter que esperar um pouco porque naquele momento ela estava priorizando o curso de Java…

Se você está numa situação parecida, faça o seguinte: pare tudo que você está fazendo e vá aprender inglês. Sério, no nosso mercado é muito, mas muito mais importante do que você pode imaginar.

Em primeiro lugar, alguns dos melhores livros existentes só estão disponíveis em inglês. Poucos títulos são traduzidos e quando são levam alguns meses (ou anos) para tal, isso sem contar que as traduções muitas vezes são ruins. Por exemplo, o Domain-Driven Design do Eric Evans levou aproximadamente 5 anos para ser traduzido, o Patterns of Enterprise Application Architecture do Martin Fowler levou 4 anos, e por aí vai. Hoje em dia o tempo é menor que isso, mas mesmo assim é muito tempo. Ou seja, você não só vai ficar alguns meses (ou anos) para trás como também corre o risco de não ter acesso a uma boa parte do conteúdo mais relevante disponível.

Em segundo lugar, os grandes players de TI publicam seus blogs em inglês – assim como vários dos desenvolvedores mais influentes no mercado. De forma alguma estou desmerecendo os blogs em português (como esse aqui), mas grandes nomes como Robert Martin, Alistair Cockburn, Kent Beck – e mais algumas dezenas que eu poderia citar – escrevem em inglês. Isso sem contar as dúzias de blogs como o TechCrunch, Mashable, High Scalability ou até mesmo o xkcd. Se você não entende inglês você não poderá aproveitar todo esse conteúdo.

Em terceiro lugar, a maioria dos projetos Open Source relevantes são em inglês. Por exemplo, você está acompanhando o desenvolvimento do Node.js? Você já estudou Clojure? E o Rails 3? Linux? Python? Projetos da Apache Foundation? Se você já brincou com alguma dessas coisas (ou todas) certamente foi porque você sabe inglês. E você pode não somente usar essas coisas para desenvolver como também estudar os códigos para entender como funcionam ou contribuir com os projetos. Enfim, um mundo gigantesco de oportunidades.

Eu poderia dar mais um monte de motivos – como dizer que a maioria dos lugares mais relevantes que todo mundo gostaria de trabalhar vão exigir que você saiba inglês – mas acho que só isso já é mais do que suficiente. Inglês é uma das coisas mais essenciais para profissionais de desenvolvimento de software e você não pode ignorar isso. Corra atrás e aprenda inglês “pra ontem”, essa é sua prioridade número um!

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.

Yahoo! procura Ninjas

Thursday, January 14th, 2010

Estamos procurando Desenvolvedores e Scrum Masters Ninjas para integrarem nossa equipe no Yahoo!

Nosso time é o que chamamos de “Innovation Cell”, que é algo como uma incubadora de projetos, responsável por pesquisar e criar novos produtos. Atualmente nosso carro-chefe é o Yahoo! Meme, que foi inteiramente desenvolvido no Brasil no último ano e já está em vários outros países como Indonésia, Filipinas, México, Argentina e Taiwan.

Desenvolvedor Ninja

Os Desenvolvedores Ninja serão responsáveis pelo desenvolvimento e manutenção de aplicações web, em especial o Yahoo! Meme e outros aplicativos de integração com redes sociais. É imprescindível ser faixa preta em Python, PHP ou JavaScript e conhecer bem pelo menos uma segunda outra dessas três. Mesmo sendo essas as principais linguagens que usamos por aqui, precisamos de desenvolvedores multidisciplinares que saibam usar diferentes tipos de ferramentas – porque nunca sabemos quais produtos virão no futuro e que tipos de vantagens poderemos ter usando ferramentas diferentes.

Tão ou mais importante do que isso é ter ótimos conhecimentos sobre desenvolvimento ágil e ser capaz de trabalhar com TDD, entender sobre CI e a sua importância, automatização de rotinas/build/etc., melhores práticas de desenvolvimento de software, Orientação à Objetos, Domain-Driven Design e tudo mais que puder ser relevante para ajudar a construir software confiável e manutenível de forma rápida e com ritmo/qualidade sustentável. Experiência com automatização de testes com Selenium ou Webdriver também é essencial.

Como desenvolvemos produtos de escala mundial, é necessário ter experiência com aplicações de alta performance e disponibilidade, identificação e otimização de gargalos de performance, escalabilidade, caching e sharding. É importante também ter bons conhecimentos de pelo menos um tipo de Unix e seus derivados.

Conhecimentos de OpenSocial, desenvolvimento de mashups, arquitetura de serviços e experiência com uso e desenvolvimento de APIs (REST, YQL, etc.) são diferenciais.

Scrum Master Ninja

O Scrum Master Ninja deverá ajudar o time de desenvolvimento a produzir no máximo da sua capacidade. Sua missão será organizar e facilitar os Sprint Plannings e Reviews, bem como Retrospectivas e o que mais for necessário para suportar os times de desenvolvimento e produto. Ele deverá identificar e remover impedimentos, ajudar o time a manter o foco mas dando todo o espaço e autonomia que ele precisa para se auto-organizar e gerenciar. É necessário já ter tido alguma experiência anterior relevante nesta posição.

Como o Yahoo! é uma empresa que em sua maioria ainda trabalha com métodos tradicionais de desenvolvimento, esta pessoa também será responsável por fazer com que o time esteja dentro das normas da empresa, gerando relatórios para as células de gerenciamento de projetos e fazendo algum trabalho burocrático de registro e comunicação de métricas.

Queremos um Scrum Master influente, que seja capaz de entender questões técnicas mesmo que em alto nível, que seja apaixonado por procurar maneiras de melhorar o processo de desenvolvimento, construtivo na hora de resolver problemas e solucionar conflitos e com muita vontade de descobrir novas maneiras de trabalhar com métodos ágeis. O Yahoo! é uma empresa que ainda está engatinhando em métodos ágeis e por isso precisamos de alguém com muita disposição e vontade de mudar a empresa!

Por último, experiência com XP, Lean Software Development, Kanban e diversos métodos ágeis são diferenciais.

Continuando…

Para ambas as posições é necessário inglês avançado, o que quer dizer que você deve ser capaz de conversar e ler/escrever em inglês sem problemas (e eventualmente ser entrevistado em inglês caso necessário).

Estamos procurando por pessoas criativas, que gostem de inovação, de pesquisar e identificar novas tendências e de encarar desafios complexos com agilidade e velocidade. Nosso time é pequeno, jovem e nosso ambiente está em constante mudança e evolução. Queremos pessoas irreverentes, que gostem de desafios, com idéias novas e com vontade de criar produtos incríveis!

A empresa oferece contratação apenas por CLT e benefícios como plano de saúde e ticket refeição. Estamos localizados na Vila Olímpia em São Paulo. Vamos dar preferência para pessoas de São Paulo mas também vamos olhar com carinho currículos de pessoas de fora e daremos auxílio para mudança caso necessário.

Se você se encaixa em algum destes perfis, mande seu curriculo em inglês para mim (gc AT yahoo-inc.com) com uma lista dos últimos 3 livros técnicos que leu. Não esqueça de colocar links para o seu Twitter, LinkedIn, GitHub e o que mais você achar relevante e que pode nos ajudar a te conhecer melhor. :)

Síndrome de DAO

Saturday, January 17th, 2009

O assunto Repository X DAO já está bem batido, eu sei, mas é impressionante como isso confunde muita gente até hoje… Muitas pessoas já postaram sobre isso mas eu quero dar meus dois centavos.

Com a popularização do Domain-Driven Design ví muita gente simplesmente renomeando seus XptoDAO para XptoRepository achando que assim estariam aplicando DDD porque “chamar um objeto de Repository é mais semântico que DAO”. Esses dias no Twitter ví uma mensagem assim: “Repositório ou DAO ? Eu gosto do nome repositório porque me parece ser uma abstração mais adequada”. Vamos lá, não se trata somente de nomes diferentes para a mesma coisa.

O padrão DAO têm o objetivo de criar uma abstração da infra-estrutura de armazenamento de dados para a aplicação. Uma camada de persistência é útil porque dá a funcionalidade de armazenamento/persistência de dados sem revelar detalhes específicos da infra-estrutura por trás disso. O armazenamento pode ser feito num banco de dados, em vários bancos de dados, em um webservice, em um arquivo texto, tanto faz, mas do ponto de vista da camada de negócios que obtém esses dados, por exemplo, ela está lidando apenas com busca, alteração e gravação de objetos em algum lugar que nem importa.

Já o padrão Repository tem o objetivo de dar apoio ao domain model fornecendo persistência. Ao contrário do DAO, que é um objeto de infra-estrutura da aplicação e faz parte da camada de persistência, o Repository faz parte do domain model que é parte da camada de negócios.

Domain models (modelos de domínio) fazem sentido quando a aplicação tem regras de negócio muito complexas. Isolar as regras de negócio em um domain model torna mais fácil o trabalho de focar e lidar com essas regras complexas. Porém, para que um software possa funcionar fortemente baseado em domain model (que é a proposta de Domain-Driven Design) é necessário dentre outras coisas que haja algum componente que faça parte desse modelo e permita que se faça persistência de dados – e daí veio o Repository.

No ano passado conversei bastante com o pai do DDD – Eric Evans – sobre isso e para ele o problema é que as pessoas confundem esses dois conceitos porque realmente são bem parecidos. Na maioria dos casos você irá precisar dos dois, porque o domain model fará buscas por objetos em um Repository que por sua vez delegará para o DAO, que é quem entende como é a infra-estrutura de armazenamento de dados. Para ele também não importa se o Repositório é uma classe ou uma interface, o que importa é que os objetos do domain model deverão dempre lidar com busca e persistência de objetos usando a interface do Repository, que tem o compromisso de ser mais semântica do que a do DAO.

[FEJ 2008] Falando sobre o Falando em Java

Monday, May 19th, 2008

O Falando em Java foi excelente! Além das palestras terem sido muito boas, foi uma excelente oportunidade para encontrar e conversar com um monte de gente legal. Pena ter sido um dia só e não ter conseguido falar direito com todo mundo, mas mesmo assim foi ótimo.

Três destaques para o evento:

1) O Sérgio Lopes correu um grande risco de se dar mal, mas no final acabou fazendo uma apresentação muito bem humorada sobre Domain-Driven Design que deu certo e todo mundo gostou! De uma forma muito descontraída ele conseguiu passar a mensagem, pena que a apresentação ficou um pouco grande para o tempo que ele tinha… Mesmo assim valeu.

2) Na parte da tarde, o Fabio Kung deu um show sobre JRuby on Rails! Ele mandou muito bem e eu aprendi um bocado de coisas novas – foi uma das palestras mais legais que eu assistí nos últimos tempos.

3) E o último destaque mas nem por isso menos importante foi o bolo do café da tarde que estava sensacional! Nossa, eu devo ter comido uns vinte pedaços (estragando qualquer estimativa que a Caelum tenha feito de bolo/pessoa).

Brincadeiras à parte, o evento foi um sucesso total. Parabéns mais uma vez para o Paulo Silveira, Guilherme Silveira e toda a galera da Caelum, que conseguiram reunir 300 pessoas legais em pleno domingo para fazer um evento excelente!

Falando em Java 2008, aí vou eu!

Monday, May 12th, 2008

Falando em Java 2008Na próxima semana estarei em São Paulo para o Falando em Java 2008, um ótimo evento realizado anualmente pelos amigos da Caelum, a melhor empresa de treinamentos em desenvolvimento de software do Brasil na atualidade.

Esse ano haverá a ilustre presença do Emmanuel Bernard (um dos líderes do projeto Hibernate na JBoss) que fará duas apresentações, uma sobre JPA 2.0 e outra sobre Hibernate Search. Por uma grande ironia do destino, a palestra de Hibernate Search foi uma das que eu não consegui assistir na JBoss World 2008 e agora vou ter minha segunda chance! Além disso esse ano não se falará só em Java mas também em arquitetura de software, Domain-Driven Design, JRuby on Rails, Scrum e AJAX.

Nos vemos por lá! :)

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 :)

[JBoss World 2008] O Hibernate Validator me incomoda…

Thursday, February 14th, 2008

JBoss World 2008 - BOFAcabei de participar de um BOF com Emmanuel Bernard, Gavin King, Pete Muir, Max Andersen e mais uma dezena de pessoas.

O assunto era desenvolvimento de aplicações usando Hibernate, Seam e outras coisas mais da Red Hat. Dentre as várias coisas que foram discutidas, falamos sobre o Hibernate Validator.

O Hibernate Validator me incomoda, e é um pouco complicado de explicar o motivo, mas eu vou tentar. Na verdade não é o Validator em sí, mas as suas annotations. Vejamos um exemplo de código traduzido da página Validator. A sintaxe é muito simples e mesmo que você não saiba exatamente como funciona provavelmente conseguirá entender:

public class Endereco {
 
    @NotNull private String rua;
    private String cep;
    private String estado;
 
    @Length(max = 20)
    @NotNull
    private String pais;
 
    @Range(min = -2, max = 50, message = "Andar invalido")
    public int andar;
 
        ...
}

Na minha concepção, quando usamos o Hibernate Validator dessa forma, passamos a ter regras de negócio/validação do objeto fora do seu controle, e essas regras não estão fortemente encapsuladas. A verificação de que um endereço deve ter no máximo 20 caracteres, por exemplo, deveria estar encapsulada dentro de um método que cria/atualiza o endereço, e não numa annotation.

Existe uma discussão muito grande sobre isso. De um lado, os “puristas” acreditam que colocar annotations num objeto de domínio significa acoplar esses objetos à infraestrutura e implementações específicas. Do outro lado, os “práticos” acham que isso não tem o menor problema, que na prática o efeito colateral disso é nulo.

Eu sinceramente fico meio dividido. O que eu sei é que isso de alguma forma me incomoda. Estou acostumado a pensar de um modo “Domain-Driven Design”, e para mim o mais natural e certo seria que essa regra estivesse dentro de algum método.

Se você pensar que sua aplicação pode usar todas essas coisas juntas com esses quilos de annotations (Seam, Hibernate, Validator, Guice, etc, etc), no final você vai ter objetos de domínio altamente acoplados à toda a infraestrutura da aplicação. Pior ainda quando essas annotations tem regras de negócio. Os objetos vão acabar se tornando meros “fantoches” controlados por annotations… Isso definitivamente não parece ser bom.

Você tem que ler os livros!

Tuesday, January 22nd, 2008

Nos últimos meses já ouví algumas pessoas dizerem que não têm costume de ler livros, ou questionarem a necessidade de lê-los, já que há uma abundância de fontes de leitura por aí na Internet.

Hoje em dia realmente temos milhares de formas de nos informarmos. Me lembro de ter lido em algum lugar que a Internet possui mais de 250 milhões de sites. Se somarmos isso tudo, realmente tem muita informação. Justamente por isso, faz parte da minha rotina diária dar uma navegada no Google Reader, onde tenho cadastrados os feeds de mais de 300 sites e blogs de diversos assuntos que acho interessantes. Essa é basicamente a minha principal fonte de informação diária e é a melhor maneira de me manter atualizado com tantas novidades surgindo por aí todo dia.

Porém, em alguns casos, para aprender e entender certos assuntos, você precisa ler os livros. Não tem jeito! Por exemplo, como é que um desenvolvedor de software pode dizer que entende Domain-Driven Design sem ter lido o livro do Eric Evans ou pelo menos o DDD Quickly? Ou então dizer que sabe sobre metodologias ágeis sem ter lido pelo menos um livro do Ken Schwaber, Kent Beck ou Uncle Bob? Como é que alguém pode se dizer Arquiteto de Software Sênior++ Certified ™ sem ter visto o Patterns of Enterprise Application Architecture e o GoF? Eu respondo: não tem como. Simplesmente não tem jeito, você precisa ler os livros.

Hoje mesmo o Patrick Kua, que trabalha na ThoughtWorks, escreveu um post sobre os livros que ele considera essenciais para saber sobre metodologias ágeis. Ele acredita que você precisa ler 11 livros, O.N.Z.E. livros, para entender sobre o assunto, e ainda completa: “Of course, simply reading the books won’t mean that you’re an expert [...] though it’ll definitely help in providing context, advice or skills that you need to practice.”. Ou seja, mesmo lendo todos esses livros, ainda há muita coisa para aprender… E estamos falando sobre um assunto apenas.

Assim como os blogs e os sites, os livros são uma fonte de informação importantíssima e necessária. Se você quer trabalhar com tecnologia e desenvolvimento de software não tem jeito: tem que ler e ler muito!