Dev Chronicles #1

January 9, 2011 at 6:56 am 1 comment

A crônica a seguir é uma ficção proveniente da minha imaginação fértil, mas sua moral é baseada em fatos verdadeiros =)

Hope you enjoy it =)

“Aquele 17 de janeiro mudou minha vida para sempre. Tinha acabado de sair da faculdade; estava livre, cheio de conhecimento e dono da verdade. Havia estagiado por 10 meses em uma pquena empresa onde em pouco tempo me tornei o ‘core’ do grupo por conseguir desenvolver minhas aplicações muito, muito rápido.

Eis que então estava eu a caminho de desafios maiores, empresas maiores e clientes maiores. Mandei currículo para algumas dezenas de empresas em São Paulo e minha agenda estava lotada de entrevistas e testes de seleção. E por falar em testes, todos eram relativamente fáceis; conseguia codar e acabar tudo muito rápido. Parecia que eu me estabeleceria em um bom emprego logo.

Entretanto, naquele 17 de janeiro eu tinha uma dinâmica marcada em uma recém inaugurada empresa na zona Sul da capital paulista. A primeira etapa consistia em uma prova contendo algumas tarefas simples. O responsável anunciou: “Vocês têm 1h para codar uma aplicação simulando uma rede social. Gostaria que na página apareçam nome, apelido, local de trabalho, relacionamento, interesses, visão política, opção sexual e uma lista de amigos, etc. Codem na linguagem que acharem melhor. Usem o que quiserem”

“Fácil”, pensei, e saí codando como habitual. Em 45 minutos, tudo rodava no meu Tomcat perfeitamente. “Essa foi moleza… To Dentro”. E eu queria estar, porque o salário era bom.

E foi então que descobri que não era fácil.

Assim que entreguei, fu encaminhado a um pequeno grupo de desenvolvedores. Sentamos em uma mesa, e eles então começaram a avaliar o pequeno sistema que eu havia desenvolvido.

“Muito bem, você começou mal com alguns NullPointerException, hem, amigo?” Assustei: “Como?” indaguei à equipe.

“Sua alicação quebra tão fácil que parece  taça de cristal na mão de criança…”

Aqueles caras nã podiam estar falando sério. Mas sim, estavam. Do jeito que eu havia codado as coisas, se o sujeito logado rejeitasse um amigo e depois tentasse adiciona-lo, minha aplicação quebrava. Se mudasse o status de relacionamento, minha aplicação quebrava. Havia um bug com o apelido; se o apelido fosse alterado os amigos que clicassem sobre o perfil tomariam um NPE. E por aí vai uma cascata de erros.

Ainda indignado, disse: “Ok, admito que há muitos erros, mas tive pouco tempo”. Foi então que obtive uma resposta sensata e que me fez refletir sobre cada linha de código que eu havia escritona vida: “Não pagamos pra você desenvolver qualquer coisa. Mesmo que você não tivesse terminado toda a proposta, não faria mal se o qe você tivesse feito não quebrasse assim facilmente. Em uma equipe, cada um desenvolve um pedaço do software. Se todos os pedaços são firmes, o software será firme como um todo. Não adianta produzir rápido se você produz de qualquer jeito. Pense em um engenheiro civil que constrói um prédio. Não adianta nada ele construir tudo em 2 meses sendo que no momento em que pisarem na construção ela ruirá. Software, meu amigo, é a mesma coisa. Software é a empreitada do seu cliente. No caso, dos nossos clientes. Não queremos que prédios desabem. Não queremos que código quebre do jeito que o seu quebrou. Não importa muito se tivermos um desenvolvedor um pouco mais lento que faça as coisas com QUALIDADE. Com o tempo esse dev adquire experiência e vai codar com fluência. Ele não vai codar de qualquer jeito. Demos um limite para testar o bom senso dos candidatos, claro. Sinto muito, você está fora.”

E foi então que o que se quebrou foi minha build. Naquela hora descobri que eu não sabia… absolutamente nada sobre desenvolvimnento de software. Todas aquelas coisas de waterfall e afins que vi na faculdade estavam… legadas.

Sou muito grato àquela pequena empresa. Graças a eles hoje sei o que é TDD, o que é BDD e acima de tudo aprendi a dar valor às metodologias ágeis. Antes eu achava que agile era coisa de programador que não sabia codar e queria ficar enrolando a história. Antes eu achava que TDD era coisa de desenvolvedor que não confiava no próprio código e precisava ver uma barrinha verde pra ter certeza que meia dúzia de linhas de código fariam o que ele esperava que de fato fizesse. Antes eu achava que pair progamming era um despedício de funcionários, e que Kanban era coisa de maníacos por post-its que não sabiam escrever código. Refatoração era apenas renomear uma ou outra variável que estava com um nome muito esquisito.

E hoje vi o quanto eu estava errado. Estou aqui com um quadro branco na minha frente com vários cartõezinhos pregados. Passei o dia todo pareando com um ex-colega de faculdade e rodamos cerca de 355 testes na nossa nova app; todos com barrinha verde e código devidamente refatorado. Já até colcoamos todas as alterações de hoje em produção. E pode acreditar, nunca gostei tando de codar e nunca confiei tanto no meu código quanto confio hoje. E tudo graças àquele 17 de janeiro onde definitivamente abandnei os horses*”

Nota – * Menção ao XGH – extreme Go Horse – Metodologia de desenvolvimento de software.

Entry filed under: Uncategorized. Tags: .

Ambiente de desenvolvimento Seam 3 – Vem com tudo! =)

1 Comment Add your own

  • 1. Adriano Santos  |  January 9, 2011 at 6:00 pm

    Agora ferrou, alem de programadora e ficcionista.Ae nao da pra competir ne……rsr…
    Parabens pelo post !

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


Calendar

January 2011
M T W T F S S
« Dec   Feb »
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Most Recent Posts


%d bloggers like this: