Archive for the ‘Boas Práticas’ tag
Boas práticas: cuidado com elas
Ter em mãos um conjunto pré-definido de boas práticas a serem consideradas no início de um novo projeto pode ser muito positivo.
No entanto, algo muito negativo pode decorrer do reconhecimento de boas práticas:
A falácia de interpretá-las como verdade absoluta, um modelo rígido a ser seguido.
A verdade é que não existe resposta fácil na disciplina de engenharia de software.
Boas práticas são importantes sim, porém estas devem ser consideradas e contestadas conforme as características do contexto existente.
Segundo Taiichi Ohno, autor do sistema de produção da Toyota, se você enxergar um modelo como solução para todos os problemas, então a motivação pela busca por melhoria contínua deixará de existir.
Além disso, antes de enxergar uma determinada prática como algo importante para o alcance dos objetivos de seu projeto, saiba exatamente o que esperar do emprego desta prática, e qual o custo-benefício envolvido.
E para concluir, vale lembrar também do primeiro item do manifesto ágil:
Indivíduos e interações são mais importantes que processos e ferramentas.
(Inglês) The best code ever
Este texto está disponível apenas em Inglês.
(Inglês) Explicit intent
Este texto está disponível apenas em Inglês.
ORM – Você ainda não usa?
No mercado de .Net software ainda é comum encontrarmos sistemas corporativos que não optaram em sua concepção pela adoção de um framework ORM.
Felizmente aquilo que traz bons resultados cedo ou tarde tende a entrar em tendência.
É o que aos poucos vem acontecendo dentro deste cenário.
ORM é uma técnica de mapeamento entre dados relacionais de um banco de dados e objetos de software existentes em uma aplicação escrita em uma linguagem orientada a objetos.
Existem diversos frameworks que viabilizam a utilização desta técnica.
Dentro da plataforma .net, cito NHibernate, Linq To Entities e SubSonic, como bons exemplos.
Projetos de sistemas corporativos comumente compartilham de características que fazem do uso deste tipo de solução uma boa escolha. (Quando foi a última vez que você escreveu um software que não possuia o requisito de persistir dados em um banco relacional?)
O que pretendo aqui é listar alguns dos resultados alcançados com a correta implementação de uma solução ORM neste tipo de projeto:
-
Maior foco na agregação de valor ao negócio do cliente.
Maiores esforços serão direcionados à soluções que atendam as reais necessidades do cliente, em contrapartida a esforços voltados ao desenvolvimento de código extenso e repetitivo, propenso a erro e de nenhum valor de negócio.
-
Sintonia com os trabalhos de arquitetura e testes.
A utilização de um framework ORM facilitará a definição de uma arquitetura de software flexível e extensível.
A abstração e transparência da persistência de dados também se alinhará perfeitamente com a definição de estratégias de cobertura de testes para a base de código. -
Redução considerável da quantidade de código a ser escrito e posteriormente mantido.
Este é o aspecto mais interessante do ponto de vista comercial.
Significa entregas mais rápidas, redução de custos e ganho de agilidade.
Aumento de competitividade.
Concluindo, quando falamos em mapeamento objeto-relacional, não estamos falando apenas de uma solução técnica comprovadamente eficaz.
Estamos falando também de uma solução que traz competitividade ao fornecedor e aumento da qualidade do produto entregue ao cliente.
Note que a aplicação deste tipo de solução não é recomendada para todo e qualquer tipo de cenário.
No entanto, grande parte deles costuma se mostrar completamente compatível.
Controller, mas nem tanto
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.
