Rafael Noronha

A chegada do Asp Net Mvc trouxe à comunidade .Net este novo paradigma, uma arquitetura de camada de apresentação capaz de trazer ao seu lado ótimos ganhos, como já descrito por mim neste post.

Muitos desenvolvedores da plataforma ainda não conheciam o padrão MVC, e é natural que os conceitos sejam assimilados gradativamente.

Uma boa prática que eu recomendarei até o dia em que não mais enxergá-la sendo violada, é a correta utilização de Controllers.

É uma pena… o nome não ajuda. Você pensa:

Controller, ah, legal, é aqui que a mágica acontece.

Por favor, pense outra vez.

Controller, mas nem tanto.

O papel do Controller é orquestrar a sua aplicação.
Sendo menos poético: direcionar o fluxo das requisições.

Cabe ao Controller conhecer:

• O que está sendo solicitado
• Quem precisa ser comunicado
• Que resposta devolver ao solicitante

Isto significa que não cabe ao Controller processar a resposta da requisição, o que cabe a ele é passar para frente.

Pense no serviço de Correios.
Você não ficaria feliz se o próprio carteiro abrisse a sua correspondência.

O mesmo acontece com um Controller que ao invés de passar para frente tenta resolver tudo sozinho.
Ele estaria cuidando de uma responsabilidade alheia.

Lembre-se, mantenha os seus Controllers nos eixos.
De brinde você estará aplicando um pouco de SOLID e zelando pela testabilidade do seu sistema, o que é algo muito bom.

O que Scrum sugere para testes de software?

Não foi a primeira e nem será a última vez que vi pessoas perguntarem o que Scrum recomenda para determinada atividade de engenharia de Software.
Scrum não sugere nada, ponto.

Scrum é falho

Não, isto não faz de Scrum um processo falho.

Scrum não se propõe a resolver problemas de engenharia de software.
Scrum não te dirá como construir software seguindo as melhores técnicas de desenvolvimento.

E não há problema algum com isso.

Os benefícios que Scrum se propõe a oferecer são organizacionais, e não técnicos.
São estes benefícios que devemos buscar com Scrum.

Descentralização de tomada de decisão, auto-gerência, aumento de comunicação, transparência e comprometimento, entre outros.

Mas Então(…)

Não é porque Scrum não recomenda nenhuma prática de engenharia que devemos abrir mão delas.
Scrum não é uma receita de bolo para se entregar um projeto de software.

Uma metodologia que determina práticas de engenharia combina muito bem com Scrum: Extreme Programming, sendo isto reconhecido formalmente:

Scrum is a framework. XP engineering practices can be used within a Scrum Sprint to improve quality and productivity.

Ken Schwaber

Portanto, lembre-se que assim como um carro não foi feito para voar, Scrum não foi feito para resolver problemas de engenharia de software.
(Ainda que as práticas de Scrum ajudem a CONDUZIR a resolução de problemas técnicos).

Isoladamente, nenhuma prática será suficiente para te guiar ao sucesso.

Me desculpe, vou me fazer repetir:
Scrum não é uma receita de bolo para se entregar um projeto de software.

Ingressei no mercado de software durante o ano de 2008, e desde então tenho atuado como desenvolvedor .Net.
A experiência adquirida em meu último empregador foi fantástica, e só tenho a agradecer ao pessoal pela ótima oportunidade que me foi proporcionada.

Estarei torcendo para que o produto que ajudei a construir se torne um grande sucesso.
Deixei meus colegas recentemente, visando buscar experiências em diferentes cenários.

Um de meus próximos objetivos passa a ser ingressar em uma equipe que adote práticas ágeis de desenvolvimento, atuando como desenvolvedor .Net pleno.
Também estou disposto a ajudar na adoção de práticas ágeis, caso ingresse em um cenário onde os processos estejam em amadurecimento.

Sou entusiasta de metodologias ágeis, mas ainda não tive a oportunidade de colocar algumas das idéias em prática.

Procuro um ambiente desafiante e inovador, onde meu talento possa contribuir com um trabalho em equipe.
Se você atua neste tipo de ambiente, e sua equipe se fortaleceria com a chegada de um desenvolvedor interessado não apenas em tecnologia,  mas processos, arquitetura, testes e qualidade de software, talvez você queira entrar em contato comigo.

Você pode fazer isto por aqui ou enviando um email diretamente para rafa AT rafanoronha DOT net.

Este texto está disponível apenas em Inglês.

Aí está uma valiosa referência para desenvolvedores de software interessados em Domain-Specific Languages.

Oren Eini, aka Ayende Rahien, autor do livro, é uma das maiores autoridades no assunto.

No livro são abordados diversos tipos de técnicas que se aplicam não apenas à construção de uma DSL, mas também a grande parte das situações que serão enfrentadas no decorrer do ciclo de vida da linguagem construída.

O foco está na construção de DSL’s internas.
Ayende utiliza-se da plataforma .NET e da linguagem de programação Boo, justificando a adoção desta.
Isto não significa que profissionais que atuem com outras plataformas não possam tirar proveito do livro, dada a riqueza do conteúdo.

Além do enfoque prático na construção de DSL’s, a leitura me transpareceu os benefícios de se implementar este tipo de ferramenta em aplicações corporativas, e ainda os cenários apropriados para sua utilização.

Também foi possível aprender um pouco sobre o funcionamento de compiladores e entrar em contato com uma nova linguagem de pogramação, Boo, que possui características bastante interessantes.