Tecnologia de Internet (Locaweb)

O 3o. dia da RailsConf (2o. dia de palestras) foi um dia muito agitado. Tivemos palestras de grandes nomes do desenvolvimento de software, como Neal Ford e Robert Martin.

A palestra do Neal Ford e seu colega, Paul Gross, foi muito interessante. É impressionante ver como eles conseguiram administrar bem o (curto) tempo que tiveram e passar a mensagem de forma eficiente. Em um evento como esses uma boa parte dos palestrantes acaba perdendo um pouco do foco e tenta passar mais informação do que o que cabe na agenda.

Eles falaram de um grande projeto realizado pela consultoria em que trabalham, ThoughtWorks, e sobre as coisas que aprenderam com ele.

Aqui vão alguns conselhos:

• Lute para manter sua suíte de testes rápida.
• Invente coisas novas sempre que precisar.
• Escreva testes inteligentes (eles quiseram dizer que o teste tem que ter um propósito maior do que simplesmente adicionar cobertura ao código).
• Escale sua infra-estrutura de desenvolvimento da mesma forma com que você escala a sua infra-estrutura de produção.
• Evite fazer design adiantado. Faça apenas do que precisa ser implementado no momento.
• Adicione complexidade gradualmente.
• Não use banco de dados como fila de mensagens (principalmente porque isso pode deixar o DBA muito bravo).
• Defina bem quais são as regras e os limites do seu projeto, por exemplo, em que situações será permitido utilizar mocks e stubs para realizar testes.
• Divirtam-se

Para manter a velocidade dos testes funcionais eles utilizaram e recomendam o DeepTest. Para os testes de aceitação em grande escala, utilizaram o Selenium Grid.

Além das recomendações, a dupla também compartilhou as suas impressões com relação ao trabalho em equipe e sobre tecnologia. Sobre trabalhar em equipe:

• Software tem mais a ver com comunicação do que com tecnologia.
• Ter a equipe trabalhando junto, no mesmo local, é muito bom.
• Programação pareada é excelente.

Neal Ford disparou uma piadinha dizendo que “programação pareada dissemina conhecimento mais rápido do que a gripe suína” (a palestra foi bastante descontraída).

Além disso, com relação a lidar com tecnologia:

• Escalar é difícil, não importa qual tecnologia se esteja utilizando.
• Rails pode escalar! (isso não é mais novidade para a comunidade, mas é importante reforçar)
• Atualizar o sistema é difícil. Para eles, isso significou arcar com o custo de 6 semanas de um desenvolvedor para migrar do Rails 1.2.3 para o 2.2.

A palestra teve muito mais conselhos e exemplos, alguns usando a analogia do jogo de “papel, pedra e tesoura”. Os slides estão disponíveis aqui para quem quiser conferir.

Acabamos de ter uma excelente palestra do guru Robert Martin, o Tio Bob. É impressionante ver a sua desenvoltura e capacidade de comunicação. Até agora esse foi o ponto alto da RailsConf’09.

Em resumo, a mensagem que ele passou foi:

• Nada deixa o código mais flexível do que escrever testes. Um código com uma boa suíte de testes ganha flexibilidade em ordens de magnitude. Se você tem uma arquitetura horrível mas uma boa suíte de testes, seu código é ainda assim mais flexível do que um que possua uma excelente arquitetura e nenhum teste.
• A presença de testes eliminam o medo de mexer no código.
• Nenhum código pode ser considerado limpo, código sempre é limpável. E isso se atinge com testes.

Ao argumentar sobre a necessidade de se escrever testes de software, em especial utilizando TDD, ele disse:

Escrever testes antes de escrever código é como lavar as mãos antes de fazer uma cirurgia. Se o seu médico não lavasse as mãos, você acharia isso profissional da parte dele?

Nesse momento, a platéia ficou em silêncio e as pessoas começaram a olhar umas para as outras.

Profissão: desenvolvedor

Com muita desenvoltura,  Bob Martin argumentou que programadores não tinham disciplina antigamente. Foram as práticas de testes, XP, programação pareada, integração contínua, entre outras, que fizeram com que tivéssemos disciplina. Antes disso, os programadores não eram profissionais. E ponto final.

Ao final da palestra, um dos participantes questionou se não estava acontecendo uma onda de “super-profissionalismo”, causada pela euforia que as pessoas têm demonstrado por todas as práticas mencionadas. Após divagar por um momento, o carismático Tio Bob reafirmou sua posição:

Deixe-me pensar… temos como ser profissionais demais? Não! Ser profissional é ter honra, é ter disciplina e acima de tudo, não ter medo de seguir a disciplina.

Se você, por causa de um prazo apertado ou por pressão, abandona sua disciplina, então você deixou de ser profissional. Você fez isso porque sentiu medo e isso também não é profissional. Profissionais não devem sentir medo e sim tratar esse tipo de situação com calma.

E então a analogia com a medicina veio à tona novamente:

Se um médico abandonasse sua disciplina por causa de pressão ou prazo, o que ele faria? Operaria o seu paciente sem ter o menor cuidado?

A propósito, o tema da palestra era “O que acabou com o SmallTalk poderia acabar com o Ruby também“. Entre outras coisas, o que Bob Martin apontou como motivos para o fim do SmallTalk foram: a arrogância da comunidade de desenvolvedores e o fato de terem ignorado as necessidades empresariais.

A platéia aplaudiu Bob Martin de pé e no final tivemos uma pequena interação com ele exclusiva que está disponível no AkitaOnRails.

Os organizadores da conferência disponibilizaram a gravação da palestra no blip.tv. Assistam!

Qualquer um que se entitule um profissional em desenvolvimento de software utiliza algum repositório de versionamento de código. É inevitável, mesmo quando se trabalha sozinho, para não se sentir inseguro sem um repositório onde seu trabalho é gerenciado.

Existem dezenas de produtos que fazem esse trabalho, incluindo o antigo CVS, seu sucessor Subversion (SVN), Rational ClearCase, Microsoft Visual Source Safe e outros. Esses sistemas tem uma coisa em comum: sua natureza centralizada. Existe um servidor, vários desenvolvedores necessariamente sincronizados com esse servidor, alguns com permissão apenas de leitura e um controle rígido no fluxo de código. 

Trocar um pelo outro não é uma mudança tão grande assim no fluxo de trabalho em geral. Esse tipo de sistema possui um grande calcanhar de aquiles: sua natureza centralizada. O servidor central é o mestre do seu código. Os desenvolvedores tem apenas as últimas versões atualizadas do código em sua máquina e nenhuma memória do histórico completo do projeto.

Perca o servidor e você perde todo seu histórico. Pior: você só consegue trabalhar se estiver online, se estiver offline se tornará muito improdutivo pela impossibilidade de realizar um ‘commit’ ao servidor. Pior ainda: se mudar de idéia no meio do desenvolvimento é um jogo de tudo ou nada: ou você retorna ao último commit (commit = escrita no repositório) que baixou do servidor ou manualmente reedita seus arquivos até o meio do caminho onde queria. Pior do pior ainda: comece a usar branches (galhos de desenvolvimento paralelo no mesmo código) no seu servidor e terá uma dor de cabeça sem tamanho para conseguir mesclar mudanças com seu tronco principal de desenvolvimento. Por isso mesmo pouca gente usa branches em sistemas centralizados e os que usam dependem de pessoas especializadas em cuidar dos problemas que ele apresenta.

Isso inibe completamente o trabalho de um programador. Um bom programador precisa testar, precisa experimentar, precisa fazer provas de conceito. Assim como qualquer bom artista, ele precisa ser capaz de rabiscar suas idéias, e até mesmo mudar de idéia no meio do caminho sem problemas. Com sistemas centralizados e restritivos você é praticamente obrigado a uma cultura de acertar da primeira vez, porque erros custam caro. E em consequência, o programador experimenta cada vez menos, tornando-se menos e menos produtivo e desmotivado. É quando programar se torna ‘apenas mais um emprego’ e não é mais divertido como antes, sem repositório algum.

Existe solução aos sistemas centralizados de versionamento de código? Com certeza sim. Continue lendo este artigo.

(mais…)