1up4Developers

Pretendo neste post falar um pouco da minha evolução na programação e como Ruby e Rails agregaram mais conhecimento e me tornaram um melhor desenvolvedor.

A gente se forma na faculdade e de repente estamos trabalhando como programador em alguma empresa de software. A primeira coisa que você vai concluir é que nada a maioria das coisas que foram ensinadas na faculdade não se aplicam na vida real. Triste realidade…

Mas como um bom programador (que você é) logo começará a se questionar e se interessar por novos assuntos, aprender novos conceitos e técnicas de programação, pois você não se sentirá confortável fazendo as mesmas tarefas repetitivas ou que não sejam otimizadas.

Orientação a objetos

Nada de cachorrinhos ou pessoas com ações como andar, comer, etc. No mundo real, seus problemas são faturas, notas fiscais, relatórios, importadores de arquivos, planilhas… e por aí vai. Seu primeiro desafio será de entender a orientação a objetos de verdade. Mas não se preocupe se isto demorar um pouco pois logo a “lâmpada” acenderá e tudo ficará claro como o dia.

Linguagem e frameworks

Agora você consegue modelar os objetos da sua aplicação mas se depara com assuntos técnicos que podem ser solucionados prontamente utilizando-se frameworks e alguns recursos avançados da linguagem em questão. Logo você estará visitando os sites da documentação do Struts, do Hibernate, do Ant… e descobrirá que o nome Apache, além de tribo indígena, é muito mais do que um servidor Web. Após muitas provas de conceito e algumas noites sem dormir, você será um programador muito produtivo e confiante.

Análise e documentação

Parabéns! Aqui você já pode ser considerado um desenvolvedor. Logo seu destaque na equipe será recompensado com mais trabalho de corno desafiador. Nesta fase sua empresa se parece com uma padaria: “Me vê meio quilo do relatório X”, “Faz dois webservices pra viagem!”, “Aí, saindo uma fornada de casos de uso…”, etc. Logo alguém tem a brilhante idéia de “documentar” tudo desde uma simples alteração no CSS do sistema até complexos e numerosos diagramas e notações daquele novo sistema para integração. No começo a novidade até parece ser uma boa idéia, mas logo você vai descobrir que o que realmente importa é ouvir os problemas dos clientes.

Testes

Se você não teve a sorte de ser orientado desde o começo da sua carreira sobre desenvolvimento guiado por testes, você aprende a importância de testes da melhor maneira possível: tomando na cabeça! Os problemas começam a ficar mais claros. Você fica mais focado na tarefa que está desempenhando e felizmente também cresce profissionalmente com este aprendizado. Você se pergunta como conseguia desenvolver sem testes e por que a linguagem que você utiliza não tem um suporte mais “nativo” a testes.

Metodologia

No decorrer da sua experiência você tentará desempenhar suas atividades de várias maneiras. Quando você faz de tudo um pouco acha que o melhor seria fazer apenas uma tarefa específica mas depois descobre que estava enganado. Neste ponto você provavelmente já experimentou pelo menos duas metodologias de desenvolvimento e saberá identificar as vantagens e desvantagens em cada uma.

Agilidade

Felizmente sua experiência o guia para um caminho mais ágil. Após aprender e aplicar os mandamentos do manifesto ágil e aprimorar seus conceitos e habilidades técnicas, desenvolver aplicações torna-se uma tarefa “natural” que você desempenha com fluência independente da linguagem ou tecnologia utilizada. Suas maiores conquistas se resumem em conseguir contornar um problema tecnológico ou limitação da linguagem, negociar o escopo do projeto com o cliente, implementar a maior cobertura de testes possíveis, automatizar processos durante o desenvolvimento, etc.

Neste ponto você começa a se questionar: o que devo fazer agora para evoluir profissionalmente?

Ruby!

Eis que você conhece Ruby e Rails. A linguagem parece estranha a primeira vista mas após algum tempo dedicado e muito estudo você descobre que é uma ferramenta muito poderosa e produtiva, onde você pode “fluir” com seu desenvolvimento. Você pensa no que quer fazer e faz! Escreve sua “feature”, implementa e roda! Simples e divertido!

Ruby e Rails vieram suprir uma necessidade e/ou carência dos desenvolvedores por simplicidade. Até seu surgimento, desenvolver aplicações nas linguagens populares do mercado era uma tarefa complicada e trabalhosa. Ruby é uma linguagem poderosa. Rails é simples e muito produtivo. Combinação perfeita!

O que você tá esperando? Comece agora mesmo a estudar Ruby e Rails e seja feliz!

UPDATE: para não causar confusão, alterei o título. Lembre-se: Ruby é linguagem e Rails é framework!

Desenvolvedores em geral sabem como é chato quando uma tela que fez ou alterou dá erro durante uma homologação ou até produção. No caso de um sistema Web, a raiva aumenta ainda mais se a causa for incompatibilidade de navegadores.

Antes de começar a apresentar o “the best of my rotina”, é bom deixar bem claro o meu cenário:

• Trabalho sozinho no projeto, sou humano e faço pair programming com a cpu, que eu tenho certeza que é pogger!
• O meu cliente, o que requisita correções e/ou novas funcionalidades, é um cliente interno e eu tenho acesso direto a ele.
• O sistema não tem testes unitários, testes de integração e etc.
• Muito código foi copiado, não somente na camada de negócio, mas também nas views. As páginas por aqui, também são conhecidas como business-view.
• Tem mais complicações, mais acho que já tem o suficiente para entenderem o meu cenário.

O que já fizemos para começar a arrumar a casa:

• Implantamos um bug tracker, conhecido como Redmine. Sabe aquele velho problema de planilha pra lá e pra cá e ninguém nunca sabia quem, e o que estava fazendo? Pois bem, este problema está quase resolvido aqui (quase porque ainda tem projeto faltando para migrar).
• Implantamos um servidor de integração continua, com o Hudson. Apesar de eu não ter testes, havia um sério problema aqui para implantar novas versões em homologação e produção, e agora com o Hudson centralizando o build, ele mesmo já disponibiliza o war.
• Por sinal, montar e começar a usar o war foi outro trampo também.

Sabendo que o meu contexto é diferente do seu, sinta-se livre para adaptar qualquer coisa. Tentei deixar as dicas o mais genérico possível.

1. Trabalhe com tarefas Curtas

Tarefas curtas são muito mais fáceis para desenvolver, testar e se livrar! Por exemplo, se tem que desenvolver aquele formulário com vinte telas, não tenha dúvida, quebre isto em pequenas funcionalidades. Para identificar as partes “quebráveis”, leve em conta o que a torna funcional, ainda no exemplo anterior, se das vinte telas, você fizer a primeira e a última são suficientes para um cadastro básico, está ai a sua primeira tarefa. Muitas pessoas não dão importância para isso, mas saber “extrair” as tarefas certas de um novo desenvolvimento ou manutenção, traz um leque de vantagens:

• Testar uma funcionalidade curta é muito mais rápido e fácil do que testar uma gigantesca;
• Fica mais dificil perder o foco.
• Os prazos ficam mais “coerentes”.
• Você pode retirar ou incluir novas funcionalidades, a “negociação” com o cliente fica mais simples.

2. Monte e use um roteiro de teste

Pra quem usa TDD, este passo pode pular. Pra quem trabalha com legados e ainda não tem testes (meu caso), eu costumo fazer um roteiro de testes antes de implementar a funcionalidade curta. Este roteiro costuma ser enxuto e abrangente, isto permite que eu descanse meu cerebro enquanto testo, pois com ele, acaba se tornando um processo mecânico. Vou colocar um exemplo recente de roteiro que usei:

Teste de Primeiro Acesso

• Limpar a base, apagar os registros da tabela xpto e suas dependências.
• Limpar os cookies.
• Acessar o index.jsp da Aplicação (esta página simula um login via cookie).
• A tela inicial só permite cadastrar os dados do perfil, os links “xxx” e “zzz” não ficam disponíveis.
• Após o Teste de Restrições ao Editar o Perfil, verificar que os links “xxx” e “zzz” estão disponíveis.
• Clicar em salvar novamente para verificar se o problema de “unique id” não ocorre.

Estes roteiros se tornaram um costume, eu perco pouquissimo tempo pra fazer e apesar de parecer besta, ele me ajuda muito na hora de executar um teste de sanidade por exemplo. O ideal seria transformar este roteiro num teste unitário ou até mesmo num script via Selenium, mas devido a estrutura (ou a falta dela?!) eu ainda não consegui esta automação tão sonhada.
Apesar deste roteiro ser descartável e somente para ajudá-lo, uma idéia legal que venho fazendo é colocá-lo como comentário caso use um bug tracker.

3. Teste seu sistema num ambiente isolado

Estes últimos dois anos tenho usado linux no desktop para desenvolvimento. Infelizmente, todos nós sabemos que todo sistema web tem que ser testado nos IE*s e cia. É claro que durante o inicio do desenvolvimento, uso meu firefox local mesmo, mas assim que termino a funcionalidade, uso uma máquina virtual para averiguar a compatibilidade com os navegadores mais utilizados.
Usando o Virtual Box e Multiple IEs mais o opcional roteiro de testes, consigo validar o sistema numa boa gama de navegadores. Para usar o Multiple IEs não tem segredo, é só atualizar para o IE7 e depois rodar o executável do mesmo.

4. Automatize o que for possível

Já ocorreu de você precisar preencher n campos, navegar em n telas e descobrir que você errou o nome de uma variável javascript e ter que fazer tudo de novo? Pois bem, comigo já aconteceu muito, e uma das soluções que venho usando é o Selenium Ide. Com o plugin do firefox, eu gravo scripts temporários (durante o desenvolvimento da tarefa) que preenche os n campos e navegam nas n telas, assim pelo menos este tempo de navegação eu só perco uma vez.

Finalizando …

Todas estas “técnicas” nada mais são do que uma retrospectiva minha, de uma tentativa (frustada por sinal) de Scrum Solo. Aqui estou colocando o que vem dando resultado, e se você achou besteira ou legal, gostaria muito do seu comentário. Sabe aquela frase da maça e conhecimento, então, minha única expectativa com este post é esta: Novas Idéias!

Valeu e feliz ano novo a todos!

Desenvolver software é uma atividade muito gratificante pois sempre podemos (ou deveríamos) exercitar nossa criatividade para solucionar os problemas dos clientes. Isto, apesar de divertido pode ser perigoso e/ou catastrófico se estivermos com o foco errado. Num ambiente cascateiro, onde cada envolvido está comprometido apenas com o processo e não se preocupa verdadeiramente com os problemas dos clientes, não é difícil que isto ocorra. Quase sempre o foco acaba sendo direcionado para a solução ao invés do problema.

Mas qual a diferença entre foco no problema ou solução? Vamos a um exemplo:

Quando a Nasa enviou os primeiros astronautas ao espaço, descobriu que as canetas não funcionavam com gravidade zero. Para resolver esse problema, os engenheiros contrataram uma empresa especializada para projetar a caneta espacial.
Dez anos e US$ 12 milhões depois, estava pronta a caneta que podia ser usada no espaço, em qualquer posição. Nem a temperatura poderia atrapalhar: a supercaneta funcionava bem fizesse frio ou calor.
Os russos, que tiveram o mesmo problema, optaram por uma solução mais simples: passaram a usar um lápis.

A história acima é bem famosa e mesmo sendo falsa, demonstra muito bem o que acontece quando o problema não está em foco. Neste caso, o problema é a impossibilidade de escrever em gravidade zero. Uma das soluções seria uma caneta que escreva nessas condições. Veja que aqui a solução já está em foco. Outra solução para o problema seria utilizar algo que escrevesse em gravidade zero: um pedaço de carvão ou um giz já serviriam. Assim, o problema seria resolvido.

Outro exemplo de falta de foco no problema é esta história da fábrica de pasta de dente, onde ocasionalmente algumas caixas da pasta de dente eram entregues vazias. Para eliminar este problema, a empresa gastou investiu milhões para garantir que durante a fabricação, nenhuma caixa ficasse sem o tubo de pasta de dente dentro. Mas o problema foi realmente resolvido depois que um operário deixou um ventilador soprando as caixas vazias para fora da esteira de produção. Simples não?

Na área de desenvolvimento de software não é tão raro acontecer algo parecido, onde o foco está inteiramente na solução. Sabe aquele sistema meio capenga, que funciona e dá dinheiro para empresa mas não é “web 2.0″ nem utiliza conceitos de “SOA”? De repente a diretoria decide que este sistema deve ser “migrado” para uma tecnologia da moda mais atual, que o permita “evoluir” mais facilmente.

Para atender esta necessidade, normalmente uma equipe nova é contratada, toneladas de documentos e diagramas são produzidos até que os programadores comecem a codificar. A esta altura, o prazo já está apertado e os “stakeholders” ainda não viram os resultados. Depois de muito tempo e dinheiro desperdiçados, um sistema feito às pressas, bonitinho mas meia-boca, é entregue com os mesmos defeitos do anterior. E o problema não foi resolvido…

Desenvolver software deve ser um investimento lucrativo, proporcionando algum ganho às partes envolvidas. Quando uma necessidade surgir, o primeiro passo é identificar o problema para então encontrar a melhor solução, ou seja, foco no problema. Neste exemplo da “migração”, o problema é que a manutenção do software atual é muito cara, porém “migrar” o sistema inteiro não vai resolver o problema, no máximo criará um novo.

Mas de quem é a culpa quando o foco está na solução? Eu respondo: a cascata! Apesar das metodologias ágeis estarem em alta e aos poucos serem adotadas pelas empresas, a maldição do waterfall ainda é está entre nós. Clientes continuam com a mania de pedir tudo no início do projeto. Ao exporem seus problemas, já estão pensando na solução. Fazem questão de engordar o escopo com coisas das quais não têm certeza da utilidade, mas querem que estejam lá pois podem precisar um dia. Os desenvolvedores também não estão isentos dessa culpa. Um legítimo analista cascateiro não se envolve com os problemas do cliente, apenas ouvem suas solicitações e transformam em casos de uso ou diagramas. É aí que uma simples necessidade se transforma numa bola de neve e a lenda da caneta da Nasa se repete…

Um verdadeiro desenvolvedor ágil deve se comprometer com o cliente, ouvir, entender e se envolver com suas necessidades para então sugerir uma solução simples, focada e que resolva o problema. Esta interação é muito importante e deve ser constante, pois o cliente passa a identificar o que realmente ele precisa, ou seja, o qual seu problema! Assim, começa a se concentrar em funcionalidades que realmente serão úteis e agregarão valor ao software e, consequentemente, ao negócio. Feedback é muito importante. O pessoal do Google sabe muito bem disso…