QCon – Responsive Design
A apresentação de Kent Beck sobre Responsive Design começou com 10 minutos de atraso porque as pessoas não paravam de chegar para vê-lo falar. Havia pessoas em pé no fundo e nos cantos da sala e sentadas no chão do corredor.
Logo no início deixou claro que a apresentação tratava do entendimento que ele têm sobre seu próprio processo de design. A idéia por trás de tudo é garantir um fluxo constante de implementação de funcionalidades, ou seja, adicionar uma funcionalidade após a outra sempre no mesmo ritmo. Para isso ser possível deve-se investir constantemente no design, de outra forma o que pode acontece é haver a necessidade de se parar de tempos em tempos para “ajeitar” o design para que ele possa suportar as próximas funcionalidades.
Depois disso, deu uma definição muito precisa para design: design são elementos relacionados beneficamente. Olhando por esse ponto de vista, design é livre de escala e não há diferença entre arquitetura e design, o que convencionou-se chamar de arquitetura é apenas design em um nível mais alto.
A partir daí falou sobre as coisas que compõem seu processo de design: valores, padrões, princípios, estratégias e refactoring, comentando mais sobre os três últimos.
Com relação a princípios, Kent Beck diferenciou os princípios universais dos específicos. Os primeiros são aqueles que se aplicam a qualquer software, como o DRY (”don’t repeat yourself”), por exemplo, enquanto os outros fazem parte da especificação de um software em particular (como “o sistema nunca deve deixar de escrever uma informação no banco de dados, mesmo em caso de falha”).
A parte mais tangível da apresentação foram as quatro estatégias para se evoluir o design:
- Leap: Sequência de pequenos passos na direção desejada. É importante que sejam pequenos para garantir que caso o código quebre no meio do caminho seja possível se voltar atrás. O tamanho dos passos depende de vários fatores – ferramentas, risco, experiência do programador, etc.
- Parallel: Manter dois designs diferentes que realizam a mesma coisa durante um certo período de tempo. Depois que o segundo design está estabelecido, pode-se começar a mover os clientes do design anterior para o novo.
- Stepping Stone: Quando o passo a ser dado para entender o problema é muito grande, adiciona-se uma etapa intermediária que ajude a chegar mais perto do destino final. Frameworks e APIs são exemplos dessa categoria. A diferença fundamental entre Leap e Stepping Stone é que o primeiro é o objetivo final, enquanto o segundo é o meio para se chegar ao objetivo.
- Simplification: Inserir ou retirar restrições no design para torná-lo mais fácil de ser trabalhado.
Por último falou sobre refactoring e de como vê o conceito ligeiramente diferente da forma como Martin Fowler o apresentou. Para ele todo refactoring é bi-direcional: se é possível criar um método novo a partir de um código existente, deve ser possível também subtituir as chamadas a um método pela sua implementação, por exemplo. Também comentou que achava que refactorings deveriam ser cidadãos de primeira classe nas linguagens, e não apenas modificações em arquivos texto, podendo inclusive ser incluídos com o código no controle de versão.
Para finalizar a apresentação Kent Beck reforçou que o princípio básico por trás disso tudo é garantir um fluxo constante de implementação de funcionalidades.
22 de novembro de 2008 às 3:30
Muito bom resumo! Parabéns pela objetividade e clareza
22 de novembro de 2008 às 10:45
Resumo Legal. É muito bom poder saber um pouco sobre que aconteceu no evento já que infelizmente desta vez, não deu para estar aí…
Abraço