Primeiro dia! – Experiência de como entrar em um grande projeto

Todo mundo já deve ter passado pela experiência de entrar em um projeto em andamento, grande ou pequeno. Em qualquer área é sempre difícil entrar em uma nova equipe, mas para nós desenvolvedores é mais difícil ainda. Motivado por isso, resolvi escrever alguns posts falando sobre a experiência que tive recentemente ao entrar na Thoughtworks.

Entendendo o problema

Por melhor desenvolvedor que você seja, é pouco provável que nos primeiros dias você consiga ser produtivo como os outros membros da equipe. Esta é uma característica bastante singular da nossa profissão, leva certo tempo para que alguém recém-contratado consiga entender o projeto e se tornar produtivo.

Esse é um dos principais motivos pelo qual os profissionais da nossa área são tão valorizados. Quando alguém sai da equipe, por mais que no outro dia a vaga já esteja ocupada, demora muito tempo para que a equipe volte a ser produtiva da mesma forma.

Se a sua equipe não for estúpida for esperta, eles saberão disso também, e buscarão a maneira mais rápida de fazer você de fazer você progredir na sua curva de conhecimento. Eles não vão esperar que você corrija bugs ou fazer melhorias em funcionalidades existentes nos primeiros dias ou semanas. Mas e o que você deve fazer então?

Primeiros passos

O principal objetivo é aprender sobre a base de código, o mais rápido possível. No entanto, é preciso ir com calma. A base de código pode ser grande, pode utilizar muitas ferramentas, pode ter várias linguagens diferentes, pode ser difícil de ler ou tudo isso junto! Então ao invés de sair lendo código de maneira aleatória, o que é bem desmotivante, procure primeiro entender como é a aplicação.

Uma boa ideia é fazer um passeio pela aplicação, acessar as principais funcionalidades como se fosse um cliente. Dessa forma você conseguira fazer ligações mais facilmente sobre as partes do código e o que elas representam na aplicação. Lógico que certas partes do código tem apenas funções arquiteturais e não possuem uma correspondência direta com a aplicação.

Ao abordar o código, procure se concentrar em entender pequenas partes da aplicação. Se a base de código for pequena, você evoluirá rapidamente, no entanto, quando o projeto é grande e/ou bagunçado, essa evolução pode demorar um pouco, mas não se desespere. Procure realizar tarefas que abordem sempre uma mesma área, assim você vai conseguir entregar valor, mesmo que em uma pequena parte.

Outro ponto importante é entender como é o funcionamento organizacional da sua equipe/empresa e como é o fluxo de trabalho. Por exemplo, como as tarefas são escolhidas, testadas, entregues, etc. Dessa forma fica mais fácil entender o impacto das suas ações e como você pode melhorar.

Técnicas úteis

Esse processo de abordar o código pode ser facilitado se a equipe fizer a utilização de algumas técnicas bem conhecidas pelos agilistas. A principal técnica que consegue acelerar esse processo é a Programação em Par. Ter um desenvolvedor experiente do seu lado para guiá-lo pelo código facilita muito, sem contar que a dupla pode realizar tarefas e entregar alguma coisa, o que é bem melhor do que simplesmente ficar lendo código sem fazer nada.

Se a sua equipe realmente segue os princípios ágeis, existe uma boa chance da base de código ter uma boa cobertura de testes. Isso é bom, pois lhe dá certa segurança ao fazer modificações. Enquanto você tenta entender o código, pode ser uma boa procurar por lugares para refatorar, mesmo que seja apenas simplificar um condicional ou extrair um método. Se a base de código estiver bem testada, você consegue fazer isso facilmente.

Outra ideia interessante é reunir a equipe para realizar de pequenas apresentações. Essas apresentações podem ser sobre alguma mudança significativa ocorrida na aplicação, sobre a evolução do projeto, sobre a arquitetura, ou então você mesmo pode fazer uma apresentação sobre o que aprendeu e a parte da aplicação a qual você se dedicou. Também é interessante fazer um modelo da aplicação, não necessariamente um UML formalizado, o importante é entender a aplicação e não apenas documentar o software.

Isso leva a outro ponto importante, o feedback. Em qualquer atividade é interessante saber a opinião de outras pessoas sobre como você está se saindo, e ao entrar em um novo projeto é mais importante ainda saber se os seus esforços estão na direção certa para que você possa se corrigir. Então após uma semana ou um mês, pergunte aos seus colegas de trabalho sobre como você está se saindo. Pode ser as pessoas com as quais você fez par, o gerente do projeto, etc. Não precisa ser apenas sobre as suas habilidades técnicas, também é interessante saber se você é um bom profissional e se encaixa com a proposta da empresa.

Durante as reuniões é bem fácil ficar perdido, pois ocorrerão discussões sobre assuntos que você provavelmente não tem conhecimento e você não vai querer parar a reunião para tirar dúvidas, certo? Uma ideia é realizar pequenos resumos sobre o que foi discutido, tomando notas sobre os assuntos falados. Assim, após a reunião você pode perguntar ao seu par ou outra pessoa sobre o que foi discutido.

O que não fazer

Um grande problema ao entrar em um novo projeto é não conhecer a linguagem utilizada. Se você não entende a linguagem, não consegue ler código, assim não adianta ficar explorando a base de código sozinho. O melhor a fazer é praticar com a nova linguagem, resolver problemas simples e entender a sintaxe. Uma dica é o site http://projecteuler.net/, nele existem vários exemplos de problemas matemáticos que são resolvidos através de computação. Assim, você abordará problemas simples e treinará os princípios básicos da nova linguagem.

Para entender a nova linguagem não perca tempo lendo livros teóricos ou discussões filosóficas sobre os aspectos da linguagem. É necessário ter um conhecimento prático da linguagem, então se preocupe primeiro em conseguir entender a sintaxe e conseguir ler o código. Depois, quando estiver conseguindo parear sem grandes problemas, vá entender mais a fundo os detalhes da nova linguagem. Se você quer aprender Java, por exemplo, é muito melhor começar por uma das apostilas da Caelum do que por um livro estilo Deitel.

Já os frameworks não são tão vitais para o projeto quanto a linguagem, assim não explore todos ao mesmo tempo. À medida que for avançando na base de código e tiver um bom entendimento, busque mais informações sobre como elas se integram com o código e com a aplicação.

Se o projeto for realmente grande, a arquitetura terá uma complexidade extraordinária. Então não tente entender a arquitetura ou as decisões tomadas na história do projeto, apenas compreenda as motivações que levaram as decisões para saber os rumos do projeto e trabalhe nesta direção.

Não deixe que a sua pouca experiência o leve a uma falsa zona de conforto. É muito simples dizer que não sabe e esperar que o seu par resolva o problema. Um bom profissional nunca dá como resposta um “não sei”, a menos que seja seguido diretamente por um “ainda”.

Anúncios

2 comentários sobre “Primeiro dia! – Experiência de como entrar em um grande projeto

  1. Daniel Oliveira

    Excelente texto! Espero por mais post. Parabéns Marcos!

  2. Marcos, parabéns pelo post e valeu a citação da Caelum.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s