refactoring – Blog do Camilo

Lançamento livro: TDD na Prática

Olá Pessoal!

É com muita felicidade que venho compartilhar com vocês mais esse “filho”. Eu não sei nem por onde começar de fato. Mas que tal pelo inicio?

Bom, a seguir falo um pouco da história dele (como todo livro meu sempre tem uma história real por trás), porque escrevi, quem pode ler, sorteio etc Vou buscar ser bem breve..

Lets go…

Agradecimentos

Fazer esta parte aqui nunca é fácil, pois são várias pessoas que contribuem para uma obra como esta: amigos, colegas de trabalho, familiares, amigo virtual, etc. E lembrar de cada um não é uma tarefa fácil. Sendo assim, estarei destacando aqueles que vieram em memória no momento que escrevo este trecho. Aqueles que contribuíram e acabei esquecendo, peço que me perdoem.

Primeiro, não poderia esquecer o meu colega de trabalho Gustavo Knuppe. Apesar dele não saber que estava escrevendo este livro, foi responsável por muitas mudanças que fiz na forma de abordar o assunto de TDD, principalmente em um artigo, no qual Knuppe foi o revisor, e nesse processo sugiram várias e boas sugestões no artigo produzido que aproveitei para utilizar neste projeto.

Um amigo que não poderia deixar de fora é o Alberto Leal. Eu diria que meu contato com mundo Agile começou devido a uma apresentação sobre refactoring que o Leal fez em alguns minutos via MSN e depois desse dia fui me envolvendo mais e mais com a técnica e quando conheci TDD e liguei o passado com o presente vi que ter conhecido refactoring com o Alberto fez uma diferença grande. Obrigado meu amigo!

À minha namorada Ellis Ribeiro, que teve a paciência e dedicação em revisar a parte ortográfica e dar sugestões de melhoria na estrutura do livro 🙂

Como tudo começou… (Era uma vez….)

Bem, primeiro nunca imaginei que um dia eu escreveria um livro sobre TDD, independente de que foco este teria. Até porque eu não sabia nada do assunto até inicio de 2010, apenas ouvia. Tinha tentado usar algumas vezes antes e fracassei em todas elas. Nunca entendia de fato como fazer os unit tests, muito menos escreve-los primeiro, mas fiquei com aquilo na cabeça. Todos (Kent Beck, Martin Fowler, Guilherme Silveira, etc) falam e conseguem, daí eu me perguntava: “o que eu estou fazendo de errado? Não vou desistir de entender direito.” Dai passou o tempo, tive que voltar a estudar devido a um projeto que precisei trabalhar em 2010 e tinha que escrever unit tests para as coisas darem certo e então fui estudando, começei a ler e pesquisar com mais detalhe. Lembro que o primeiro post que li sobre o assunto foi do Guilherme Chapiewski. Fui navegando para outros blogs, tentando entender a mecânica e praticar. Comecei a pegar o ritmo, mas confesso que naquele momento não sabia que eu fazia TDD na veia, era complicado, pra mim era código com um framework que eu testava o que escrevi. Mas cada vez que programava gostava do resultado, ficava viciado, daí decidi me aprofundar mais no assunto, e fui buscar referências “for dummy”, tanto em português quanto em inglês. Achei? Não, pois identifiquei os seguintes problemas nas obras publicadas sobre o assunto na época:

1. Era necessário ter uma certa experiência (nem que fosse muuuito básica) com a mecânica de unit test;

2. Os livros eram longos e poucos práticos para iniciantes, com exemplos esquisitos que ao término da leitura sentia falta de algo mais concreto para praticar e dizer: ‘entendi de fato com a mão na massa’. Enfim, faltava uma direção melhor para iniciantes.

E foi quando despertou de sair anotando tudo que ia aprendendo, tanto aquilo que deu certo quanto o que deu errado também. Meses depois (no final de 2010), por “ironia” do destino caiu no meu caminho o meu primeiro projeto, o qual usariamos TDD. Mesmo sendo pequeno ajudou muito, digo que foi onde tudo começou de fato, com erros e acertos, mas foi gratificante o resultado. Dai fui para um outro mais arrojado, de 1 ano, e TDD foi a base para podermos entregar o código com qualidade, menos bug, menor custo de manutenção e respeitando os prazos. Tudo isso me fez refletir. Um dia parei e olhei para tras e perguntei: “O que aprendi até hoje? Que tal criar um livro sobre o assunto? Aliás, usar minhas anotações, experiência adquirida, para ajudar quem está querendo entrar nesse mundo?” Observei nos fóruns e comunidades Java que muitos tinham vontade de aprender TDD, outros tinham tentado e fracassado, alguns nem sabiam por onde começar.

Enfim, todos os problemas que passei eram bem recorrente para todo iniciante. E foi aí que nasceu o meu livro “TDD na Prática”. Essa é a história dele.

Quem pode ler?

Essa é uma pergunta muito comum: “será que devo comprar?” Eu digo sempre o seguinte: compre o livro se você:

1. Conhece bem o básico do Java e Orientação a objetos. Olha o que eu estou falando, conhece bem JAVA e não JEE. Iniciantes ainda fazem confusão com as siglas do Java (não deveria, pois a primeira lição é saber as diferenças);

2. Sabe o que é unit tests ou tem ideia de para que serve;

3. Sabe a diferença entre unit test x Junit;

4. Quer de fato aprender TDD e saber que, no inicio, será um caminho duro, sofrido, pois não é só sentar na máquina e sair codificando. É uma forma diferente de pensar, codificar, resolver problemas, que no resultado final isso é transparente para quem olha sua aplicação e diz: “Essa eu digo 100% que foi feito com TDD, mas essa não”. A olho nú não é possível dizer isso.

5. Gosta de desafios e quebrar a cabeça;

Se você se encaixa nos pontos acima, pode adquirir um exemplar, caso contrário, eu diria que não compre :).

Como o livro está estruturado?

Bem, para quem conhece meus livros sabe que sou bem informal na escrita e gosto de dar a sensação ao leitor que estamos mais batendo um papo que lendo um livro em si. Com esse não será diferente, pois é meu jeito natural de escrever. Mas o que eu coloquei no livro?

Bom, quando começei a escrever a primeira pessoa que eu pude me espelhar era eu mesmo, aquele cara que não sabia:

– nada de TDD na prática, só ouvia falar;
– conceitos de Agile, muito abstrato ou quase nenhum;
– tanta sigla, termos TDD, Mocks, Mockito, Junit, refactoring que na prática, juntando tudo no “liquificador”, nunca sabia se o resultado final era de fato o esperado;
– e um cara que não sabia programar usando unit test; Alias, mal entendia uma classe que tinha métodos com as anotações @Test. Me perguntava “pra que realmente isso serve? como pode agregar valor na aplicação?” Só ouvia as pessoas falarem: “É bom”. “Funciona”. “Usa isso que vai ser show”, “Seus problemas acabaram, use unit test”. Mas no fundo não entendia como, e tive que aprender isso sozinho.

Então o livro segue uma ordem que, a depender em que nível você está, pode ir lendo sequencialmente. Eu diria que se é bem iniciante mesmo, vá na ordem sequencial, mas se você já sabe mocks, usar o JUnit, etc, pode pular alguns e ir para o qual lhe interessa de imediato.

Coloquei exercícios para serem feitos com o objetivo de forçar o leitor a exercitar o que aprendeu sobre TDD de formas diferentes. Vamos começando em um nível com a minha ajuda, mas depois deixo você ir sozinho, tomando suas decisões de quais testes escrever. Isso ajuda a ganhar confiança naquilo que está fazendo, o que no inicio com TDD todos se sentem desconfortável, inseguros e se perguntando: “será que estou fazendo a coisa certa? É isso mesmo?”. Enfim, espere exercícios um pouco diferentes do que você está acostumado a fazer no dia-dia. Também compartilho com o leitor como eu faço TDD e a gente vai vendo o que da certo e não da. Em alguns exercícios há respostas, para depois o leitor comparar e ver como resolvi. Não quer dizer que o seu tem que ser igual ao meu, cada um resolve de uma forma. O objetivo é que você tenha feito realizando os testes primeiro. Mas há outros que não temos a resposta. Fiz esses para que você possa olhar para o problema e garantir que atendeu ao requisito, ou seja, resolveu de fato usando TDD sem ter outra solução para preparar. Isso ajuda a ter mais confiança no que você entrega, já que todo “TDDista” sempre vai ouvir a seguinte frase: “Isso não funciona”, “Isso é coisa de nerd”. “Só funciona no mundo do Kent Beck e Martin Fowler”. Mas acostume-se com esses e outros comentários, faz parte do dia a dia, e o melhor de tudo: não se irrite. Há um capítulo que explico o Junit, Mocks, refactoring, falo rapidamente sobre Agile e Scrum.

Onde adquirir um exemplar?

Acredito que, dentro de uma semana no máximo, o livro estará disponível nas melhores livrarias, como: Saraiva, Cultura, Fnac, etc. E nas lojas virtuais: livrosdeprogramacao.com, submarino.com.br, americanas.com.br etc.

No site da editora você pode comprar: www.lcm.com.br.

Formato do livro:

O livro será disponibilizado no formato impresso (R$ 36,80) e e-book(R$ 27,80). A versão ebook só será vendida pelo site da editora.

SlideShare

Disponibilizei no slideshare alguns capítulos do livro.

Sorteio

Você tem até 02/12/2012 para realizar o seu cadastro. No dia 03/12/2012 divulgarei o resultado.

Regras:

– Não é permitido realizar 2 cadastros. E-mails duplicados e a pessoa não estará mais participando do sorteio. Então façam apenas 1 cadastro por e-mail. Lembrando que deve ser um e-mail válido, pois o contato para confirmação dos dados será feito pelo e-mail cadastrado, e o ganhador tem até 48hrs para responder, a partir da data de recebimento. Caso contrário, um novo sorteio será feito;
– O livro será enviado para o endereço informado no cadastro. Então coloque o endereço completo + ponto de referência.

Atualização:

O ganhador poderá escolher se deseja a versão impressa ou e-book.

Resultado

O ganhador foi: Rafael Oliveira

note: Um e-mail foi enviado para o ganhador o mesmo tem até 48hrs para confirmar o recebimento e dados de entrega. Caso não seja respondido em 48hrs a partir da data de envio, um novo sorteio será realizado.

Bom, vou ficando por aqui.

Demorou, mas chegou. 🙂

See ya!!

Pré-Lançamento: Livro TDD na Prática

Olá pessoal,

É com muita felicidade que escrevo este post. Realmente só quem é “pai” sabe o que eu estou sentido. Como vocês já podem imaginar está vindo ai mais um filho para se juntar aos seus irmãos “Guia do exame SCJP” e “Guia Prático JEE”. É ele o “TDD na Prática”. O livro está previsto para ser publicado até o final de junho/2012. Ainda não recebi a versão final do livro, mas assim que receber estarei disponibilizando alguns capítulos. A seguir faço uma pequena apresentação sobre o meu filhão.

lets go…

Sumario Tdd na Prática

Sobre o livro

O livro vem com um objetivo simples: “Descomplicar o que parece ser complicado”, em outras palavras O objetivo é ensinar como praticar TDD usando a linguagem de programação Java. Para muitos iniciantes em TDD, no primeiro momento parece que estamos fazendo tudo errado e que escrever os testes antes do código funcional não é nada legal. E que para superar os primeiros obstáculos, só o conhecimento técnico não é suficiente. Quando comecei com TDD passei por vários obstáculos e um deles foi encontrar livros práticos, ou seja, aqueles que eu pudesse colocar a mão na massa de verdade, ter problemas para resolver usando a técnica, etc. Os disponíveis eram bastante teórico, deixando a parte prática sobre minha responsabilidade que, como iniciante, era difícil saber por onde começar. Esses livros foram importantes para entendimento e formação da minha base teórica sobre o assunto, mas eu percebi que uma coisa era eu ter lido e outra era praticar e me ver com o Eclipse aberto e sem saber o que fazer de verdade, ou pior, me perguntar: ‘como resolver um problema usando TDD e não cair na tentação de escrever os testes por último?’. Quem não tem cão caça com gato. Tive que criar meu próprio caminho prático, onde comecei a desenvolver novas aplicações usando a técnica (venci pela persistência), em seguida surgiu a oportunidade de ir para um projeto novo na empresa que trabalhava e lá tive o espaço para desenvolver usando TDD por quase 2 anos, e nesse meio surgiu a ideia desse livro: “por que não criar um livro prático sobre TDD com base na minha experiência?”. E foi assim que comecei a escrever o livro no final de 2010, tendo como referência o Kent Beck.

O que você vai encontrar no livro:

Desenvolver aplicações Java usando a técnica de TDD;
Exercícios Práticos;
O uso de objetos mocks com Mockito;
Praticar algumas técnicas de Refactoring ;
Entender os valores do mundo Agile;
Por que TDD?
Junit;

E como sempre, dei preferência em usar uma linguagem informal e fazendo o uso bastante da primeira pessoa. O motivo é que durante seus estudos quero que tenha a sensação de estar batendo um papo comigo ao invés de estar lendo algo mais formal.

Meu desafio

Quando eu decidi escrever esse projeto foi porque me sentir desafiado (assim como os outros já publicados). É isso mesmo. Ao olhar o que tinha em mãos (anotações) mais a experiência e sofrimento com o “mundo TDD” e decepções que passei eu disse: “preciso escrever um livro sobre o assunto”. Daí reparei que escrever um livro com um assunto abstrato não seria uma tarefa fácil, uma vez que TDD, refactoring são técnicas que não se aplicam somente à linguagem Java. E daí eu comecei a entender melhor o livro do Kent Beck (TDD by example) e Martin Fowler (o de Refactoring) o quanto eles são “chatos” e sem sabor para quem é bem iniciante. E eu disse: “preciso fazer algo que empolgue o iniciante, ou seja, algo com sabor, mas que eu não venha perder o eixo principal da técnica”. E daí passei dias pensando, escrevendo, apagando, anotando, dormindo sem respostas e fui vendo como vencer esse desafio de ensinar TDD sem ferir os conceitos da técnica. Isso era o que me tirava o sossego todos os dias e não sei se consegui atingir. Acredito que sim, mas só terei a certeza quando você me escrever dizendo o que achou J. (aguardem até o lançamento…)

Quem pode ler?

O publico alvo são estudantes da tecnologia Java que querem aprender usar TDD desde o principio e tem simpatia com o mundo Agile.Se você ainda está dando os primeiros passos com Java e gosta de ser desafiado, este livro é para você. Indiretamente o livro acaba revisando alguns conceitos básicos do Java nada fora do normal, porém agora o desafio é você fazer as coisas mais simples escrevendo seu teste primeiro. Como eu já passei por isso, sei o quanto difícil é escrever os testes primeiro antes do código funcional e quando eu falo mais simples, não necessariamente é mais fácil. Se você está bem no inicio do Java, ainda dando “Hello World”, eu diria que o livro não vai ajudar muito nos seus estudos com Java, talvez atrapalhe. A minha sugestão é: aprenda primeiro os fundamentos da linguagem e Orientação à Objetos e depois retorne à todo vapor para ler o livro. Enquanto isso coloque na prateleira e não compre o exemplar.

Pensei em escrever este livro quando, ao iniciar meus estudos com Java, não encontrei um material do qual pudesse desde “pequeno” ir sendo educado com boas práticas, e fui aprendendo no dia-dia, além dos sofrimentos que tive até adquirir uma nova cultura. Se você é aquele iniciante que está a fim de colocar em prática toda essência do Java e ao mesmo tempo ir entendendo o que só ouve falar de TDD, Refactoring, JUnit, este livro é para você.

Eu particularmente diria que este é um tipo de livro que gostaria de ler depois de ter lido Head First Java da Kathy Sierra.

Agradecimentos

Fazer essa parte aqui nunca é fácil, pois são várias pessoas que contribuem para uma obra como essa: amigos, colegas de trabalho, familiares, “amigo virtual” etc. E lembrar todos não é uma tarefa fácil. Sendo assim, estarei destacando aqueles que vieram em memória no momento que escrevo este trecho. Aqueles que contribuíram e acabei esquecendo, peço que perdoem.

Não poderia esquecer o meu colega de trabalho Gustavo Knuppe, apesar dele não saber que estava escrevendo este livro, foi responsável em muitas mudanças que fiz na forma de abordar o assunto de TDD.Principalmente em um artigo sobre TDD, o qual Knuppe foi o revisor, e nesse processo, sugiram várias e boas sugestões no artigo produzido e aproveitei para utilizar neste projeto. Um amigo que não poderia deixar de fora é o Alberto Leal. Eu diria que meu contato com mundo Agile começou devido a uma apresentação sobre refactoring que o Leal fez em alguns minutos via MSN e depois desse dia fui me envolvendo mais e mais com a técnica e quando conheci TDD e liguei o passado com o presente vi que ter conhecido refactoring com o Alberto fez uma diferença e grande. Obrigado meu amigo!

Outra pessoa é meu amigo Edson Gonçalves, sempre digo que se me tornei um escritor é porque fui “batizado” por esse grande escritor e amigo, o qual já temos um laço de amizade verdadeira por mais de quatro anos. Dedicar este livro para um grande amigo como você é o mínimo que posso fazer. Nos momentos mais difíceis você sempre estava ali comigo me dando força. Abraços e tudo de bom para você meu grande amigo.

Formatos

Será vendido no formato impresso e e-book.

Enfim, pessoal essa foi a pequena apresentação do meu próximo livro. Espero que vocês gostem e curtam. Quem quiser divulgar nas comunidades eu não me importo 🙂

Abraços, qualquer dúvida só mandar.

See ya!!!

TDD:Minha primeira Experiência TDD

olá Pessoal,

No post de hoje é compartilhar com vocês minha primeira experiência com TDD de forma mais corporativa onde tinha que entregar algo de fato(e sair dos tests made in house).Para quem acompanha o blog, meu twitter sabe que venho estudando e se envolvendo cada dia com o mundo Agile. Como toda primeira experiência nunca sabemos como será o resultado,uma vez que não nada de background para aquele contexto. Talvez podemos falhar ou ter um sucesso do tipo “aceito”. E para sabermos disso precisamos apenas de coragem(não esqueça dessa palavra quando tiver trabalhando com TDD) e deixar o medo de errar de lado. Foi assim, que começei meus “baby-steps” com TDD. O que aprendi de cara foi: “uma coisa é usar TDD em seus projetos pessoais at home, e outro quando vamos para complexidade que temos no mundo de um negócio real, são experiências muito distante, porém se não tivesse feito aquela experiência caseira, o impacto seria maior”.

Vamos ver o que rolou…

lets go…

Cenário

Surgiu uma nova feature no projeto e teremos que implementar, e daí cai isso na minha mesa(sempre acontece isso no desenvolvimento de software certo?). O escopo, design, desenvolvimento etc. Tudo isso é responsabilidade do engenheiro/desenvolvedor/analista/arquitetos etc encontrar uma solução para a tal feature. Alguem precisa dela done no prazo X , dentro dos criterios de aceitação YXZ.

Minha Experiência

Normalmente um produto tem muitas features, no inicio gera uma pergunta: “Por onde começar?” “qual a melhor feature implementar por agora?” Selecionei a mais simples. Antes eu poderia ir logo na mais que aparentava difícil, mas com TDD eu precisava fazer de forma mais simples possível, desde que saisse do vermelho para verde. Daí começei a criar os units tests para uma determinada classe, pensando nos problemas, principalmente aqueles esperados, as exceções que deveriam acontecer quando o contexto fosse ZX. E foi assim que começei, da maneira mais simples e “boba”, a medida que ia adicionando novas features e o código mudando, os tests mais simples failure e isso era bom, porque sabia que uma nova feature que foi implementada, fez meu código quebrar e eu fiquei sabendo disso o quanto antes e agora devo fixar para poder ir adiante. Então esses feedbacks rapidos foram cruciais, pois não esperei até o deploy acontecer e o pessoal de QA abrir um bug 🙂

Para saber o que precisava ser feito, fiz um BillBoard, com as tasks(to-do), o que está sendo feito(in progress), e o que foi feito – Done (faltou uma coluna com blocker). Assim podemos manter o foco e saber de fato do que estamos fazendo e ajuda até dar um bom status nas scrums com o team.

O resultado

Resultado veio além do esperado, no inicio gastei bastante tempo com o units tests e seguindo os conceitos da metodologia, porém ganhei mais velocidade lá na frente e principalmente na semana final, pois tinhamos code clear(TDD ajudou identificar onde deveria refatorar), units tests fazendo boa cobertura e testes rápidos.

A moral da história que ganhei 2 dias free, pois conseguir entregar antes do deadline, com um bom tempo sobrando para fazer qualquer coisa, e o melhor de tudo a segurança que os criterios de aceitação daquela feature estava sendo alcançada com o menor esforço possível(não foi necessário dar aquelas esticadas de 2-3 hrs após o expediente). Então feature accepted, good cobertura de code e code clear. Tudo provocado por algo chamado TDD. Observem que nada disso foi planejado, era apenas entregar a feature, mas por consequência do destino, TDD trouxe vários outros beneficios de forma indireta ao desenvolvimento.

TDD não é a solução para todos os problemas que temos no desenvolvimento de software, não passa de uma metodologia que depende como está sendo aplicada ao projeto, e o mais importante pessoas etc. Se as pessoas envolvidas não estão nem ai, e não acreditam já entramos perdendo no jogo.

Eu faço uma associação bem abstrata para quem não entende TDD com aquelas metodologias que aprendemos na faculdade de como fazer o seu TCC, sabemos que só a metodologia não vai fazer o seu TCC, você vai precisar entender do assunto que deseja escrever, e começar a usar a metodologia para ti guiar como terminar aquilo da melhor forma possível e saber quando acabou ou quanto falta para acabar. E o melhor se vai dar tempo de entregar dentro do prazo (basta olhar o seu burn down chart do TCC rs).

Um livro que eu deveria ter lido, antes de ir para minha primeira experiência profissional com TDD era o do Kent Beck, mas não tive tempo, pois foi um challenge que surgiu em questão de poucos dias e daí tive que usar os materiais que já tinha em mãos e li bastante artigos, post da galera mais expert: Guilherme Silveira, Philip Calçado, Rodrigo Yoshima, Guilherme Chapiewski há alguns post e palestras legais no InfoQ. E o que não deu pra ver ler, teve que ser visto na pratica com erros e acertos.

Vou ficando por aqui, e espero que tenham gostado do post, não deixe de compartilhar como foi sua primeira experiência com TDD, ficaria feliz em ler outros cases. O objetivo do post, é mostrar para aqueles que estão na dúvida do uso de TDD, para saber de fato se funciona, tem que colocar mão na massa, o máximo que você vai descobrir no final é que TDD não atendeu aquele contexto que você tentou validar.

Abracos, see ya!!

Como ser um Programador Senior Java

Olá Pessoal,

Ano passado eu falei como ser um programador júnior & pleno. Discutimos qual o perfil técnico que no minimo o programador deve “ter” e o que esperado por algumas companhias. Claro que nenhuma informação contida no post era algo cientificamente comprovado(nesse também não). Apenas um achismo do autor tendo como base a experiência, analise do mercado, bate papo com alguem do RH e um pouco de achismo. Hoje vou falar sobre ser Pleno.

O que é ser um programador pleno?
Como se tornar um?
O que preciso saber tecnicamente para ter um perfil de Programador Java Pleno?

Lets go…

Outros posts:

Antes de começar, quero dizer que um profissional de IT não vive apenas dos conhecimentos técnicos nos dias de hoje. Há outras qualidades que são avaliadas e tem o mesmo peso ou até mais que o número de frameworks, certificações e tempo de experiência. Um exemplo que posso citar é trabalho em equipe, relacionamento, comunicação, equilíbrio etc. Do que adianta ser “bom” tecnicamente, mas você não sabe se comunicar bem, não tem proatividade, se acha o dono do mundo e não consegue de forma nenhuma trabalhar em equipe?!! Você pode ter a experiência que for em uma determinada tecnologia, mas os pontos que acabei de citar, eles são classificatório/eliminatório em um processo seletivo. O que um dia as empresas já fizeram “vista grossa” e queria apenas aquele “cara de informática” para “mexer com o computador”. Esse perfil não existe mais nas melhores empresas para se trabalhar.

Mas, a pergunta de muitos: “Camilo, o que eu preciso aprender, para se tornar um programador sênior, quantos frameworks, quanto tempo isso leva? Etc”.

Primeiro: Não existe o tempo definido e sim sua experiência adquirida nos projetos que tem participado e tecnologias que tem usado, não existe receita dizendo que somente se vc usou tecnologia X por Y tempo que vc pode se tornar um programador sênior. A sua capacidade de resolver problemas usando a tecnologia correta, atendendo os requisitos do cliente e não perdendo o foco do negócio vai contribuindo para sua formação. Então tire isso da mente que você vai se tornar sênior somente daqui à 5-10 anos. por alguem ti falou Não está escrito em lugar nenhum isso, porém a média geral que bem comum de ver no mercado, é que boa parte dos seniors não tem menos de 5 anos de experiência, mas por que isso? Bem, lembre-se que vc passa um bom tempo como júnior, depois vai para pleno e cai em sênior Mas, tb não há nada que diga que vc tem que seguir essa ordem. Já tive colegas que entrou como júnior e ficou por 1 ano e depois já caiu para sênior, isso vai do skill técnico do profissional + projeto + habilidades não técnicas que citei no inicio do post.

Agora outro ponto importante, é o projeto que você está participando ele é um fator bem decisivo e que acelera o processo, se tem um projeto bem ativo, dinâmico, que esteja aberto ao uso de novas tecnologias isso vai contribuir diretamente para sua formação e não tem salário que pague por isso.

Vejamos a parte técnica de aprendizado que se espera de um sênior Java:

Parece que isso nem deveria aparecer aqui, mas é bom repetir. Experiência em Java, O.O, Design Patterns são fundamentais para um bom sênior Java;
Ter o conteúdo da SCJA, SCJP, SCWCD, SCDJWS de forma suave na mente e na prática. Não estou dizendo que deve ser certificado, mas dominar todo aquele conteúdo como tomar café-da-manhã todos os dias;
Dominar XML de forma fluente.
Ser capaz de eliminar POGs e bugs de um sistema em questão de segundos ou de minutos, sem cometer erros. Essa habilidade é importante lembre-se tempo é $$.
Ser capaz de otimizar código de tal forma que o entendimento seja como somar 2 +2. Quer uma prova disso: Veja o livro refactoring de Martin Fowler o cara refatora de uma forma que tem que ser elogiada. Então usar de forma bem XP, Refactoring etc. Não pode ser uma novidade para um sênior
Conseguir transformar qualquer tipo de requisito mal-definido e contraditório em algo funcional, eficiente, sem bugs e nada de gambiarras;
Tratar SQL, JDBC, Java, JSP, HTML, Servlet, JavaScript, Reflection, Annotations, XML, EJB, SOA, Threads e concorrência como coisas tao trivialmente simples como respirar. Tendo total, completo e absoluto domínio sobre isso
Dominar os frameworks mais usados mercado, exemplo no momento que escrevo o posts: Struts 2, Spring, JSF, Hibernate etc. De 10 vagas para Java 10 pedem pelo menos conhecimento em 1 desses frameworks. Seja para júnior,pleno ou sênior
E por ultimo não parar de estudar, continuar de olho no mercado devorando novas tendências.
Preciso dizer que é bom saber inglês? E de preferência dominar o idioma de verdade e nao somente o “inglês técnico”.

Bem pessoal, vou ficando por aqui e espero que tenham gostado, o objetivo maior aqui é mostrar e ajudar aqueles que estão perdido “o que estudar Java?! ”, acredito com os pontos citados dar para ter um ideia e traçar o mapeamento o que estudar. Claro que as informações aqui não passa apenas da minha opinião, e não acordei hoje e resolvi escrever sobre o assunto e pronto. Pesquisei, conversei com colegas mais experientes, aproveitei profissionais de alto de nível em seleção de profissionais IT, para sugar um pouco as necessidades deles etc. E isso já vem sendo feito a um certo tempo. Não deixem de suas opiniões.

Abraços, see you next post.

Follow me: http://twitter.com/camilolope