Na semana passada eu e toda a equipe de desenvolvimento da UFABC fomos ao Rails Summit 2009, maior encontro de Ruby on Rails da América Latina. O evento, promovido pela Locaweb e guiado por Fábio Akita, teve a sua segunda edição realizada nos dias 13 e 14 de outrubro, no Centro de Convenções Anhembi, em São Paulo. Confira qual foi a programação do evento.

Foram várias as palestras e os temas apresentados durante o Rails Summit, desde valores e paradigmas da linguagem e do framework, até detalhes técnicos e novidades sobre o assunto.

A palestra de fechamento do evento foi apresentada por Obie Fernandez, autor do The Rails Way, o guia de referência definitiva para Ruby on Rails, editor da Addison-Wesley Professional Ruby Series e reconhecido membro da comunidade internacional de Ruby. Obie é o CEO/fundador da Hashrocket, consultoria web e desenvolvedora de produtos em Jacksonville Beach, Flórida.

Palestra: “Dominando a Arte de Desenvolvimento de Aplicações”

A palestra teve o objetivo de comparar o desenvolvimento de aplicações com criações artísticas. Obie iniciou descrevendo as maneiras como um indivíduo pode ser considerado especialista em alguma coisa, sugerindo como regra maior a prática: “Practice, practice and practice” (Praticar, praticar e praticar). Apesar do caráter óbvio desta colocação, a idéia parece não ser tão simples. Obie dividiu em 3 níveis o domínio que alguém possui sobre alguma modalidade, seja ela esportiva, artística ou de programação. Não me lembro exatamente como foram as classificações atribuídas por ele, mas era algo assim:

1º nível: O especialista. A pessoa é expert e muitas vezes uma importante referência naquilo que faz.

2º nível: O bom conhecedor. Apesar de não ser a melhor em sua área, a pessoa tem um bom conhecimento. Não passa vergonha.

3º nível: O mediano. Não é leigo, mas pode estar longe de ser o especialista da sua área.

Segundo algumas pesquisas, o tempo médio de prática para que um ser-humano possa se tornar especialista em alguma modalidade em algum momento de sua vida é em torno 10000 (dez mil) horas. Desta maneira, calculando bem por cima, um programador Ruby, por exemplo, com uma jornada diária de 8 horas, levaria cerca de 5 anos para ser especialista na linguagem. Porém, nesta estimativa alguns fatores que não foram levados em consideração podem fazer este tempo se elevar bastante – Apesar da jornada diária de trabalho, qual programador fica, efetivamente, 8 horas por dia apenas codificando ou estudando Ruby? E outro fator, não menos importante: O prazer com que a pessoa exerce determinada atividade – de nada vale 8 horas efetivas diárias se isto for um grande sacrifício. Obie comparou este último fato com o aprendizado de violino – Uma pessoa que desde sua infância pratica e estuda horas e horas por dia o instrumento, mas não tem o mínimo prazer em fazer isto, definitivamente o tempo que ela levará para se tornar uma especialista é extremamente superior (isto se fosse possível).

Entendo que pode paracer uma série de obviedades, e pode até ser, mas foi brilhantemente exposta por Obie Fernandez. Recomendo assistirem ou lerem algum material de sua autoria. Mas as partes mais legais, na minha opinião, foram as menções ao desenvolvimento ágil:

Assim como um artista plástico idealiza uma obra de arte em que o resultado final não é claro em sua mente, não se deve esperar que o desenvolvedor preveja todas as funcionalidades e o formato definitivo do sistema antes mesmo de começar a desenvolver – o pecado capital da maioria das metodologias clássicas de engenharia de software. Da mesma forma,  o artista não pinta um quadro o dividindo em partes isoladas, assim como o desenvolvimento e a programação de um sistema pode fluir muito melhor se não for excessivamente modularizada. Reparem nas diferenças:
Outra prática muito comum utilizada em metodologias de desenvolvimento ágil são os testes automatizados de sistema: TDD (Test Driven Development ou Desenvolvimento Orientado a Testes). Uma feature de um sistema só deve ser codificada caso um teste para esta feature também já tiver sido previamente codificado, garantindo a integridade de todo o sistema, evitando, ou melhor, evidenciando uma porção de erros inimagináveis em futuras modificações sem que eles precisem ser encontrados pelo usuário final (como acontece na maioria das vezes em que um sistema é desenvolvido sem testes automatizados) e principalmente proporcionando uma visão clara e garantida do funcionamento do sistema como um todo, sem ao menos ter realizado nenhum teste real, assim como alguns especialistas da música conseguem imaginar perfeitamente como é a melodia da obra sem a ter ouvido nem uma única vez, apenas pela sua partitura.

A palestra foi ótima!

Aos programadores que não conhecem estes tipos de metodologias (Agile Development, TDD, etc), recomendo fortemente que pesquisem sobre. Ficam aí alguns links:

Test Driven Development
Agile Manifesto
Desenvolvimento ágil de software
Scrum

Web Site oficial de Obie Fernandez: http://obiefernandez.com/

• Previous Entry: A alegoria da caverna
• Next Entry: Psicologia Cognitiva – Memória