6 maneiras de fazer a mesma coisa, o que é considerado boas práticas?

As vezes tem tantas maneiras diferentes de fazer o mesmo código que nós ficamos na dúvida quanto a qual maneira usar. O que seria considerado "boa prática" pela comunidade e o que sua equipe entenderia melhor. Suponhamos que você esteja trabalhando dentro de um método de um Domain Service chamado UmDomainServiceChique(objetoDoDominio) que será chamado por uma API. Você tem uma regra de negócio chique para ser verificada que por enquanto chamarei de VerificaMinhaRegraChiqueComplexa(). Você chama UmDomainServiceChique(objetoDoDominio) e caso VerificaMinhaRegraChiqueComplexa() retorne true você vai querer que UmDomainServiceChique faça o que tem que fazer e a api retornar Ok 200, caso contrário você quer que a API responda um erro qualquer, tipo BadRequest, e retornar uma mensagem dizendo que VerificaMinhaRegraChiqueComplexa deu ruim. Eu vejo 6 maneiras de fazer isso, gostaria de saber a opinião de outrs devs sobre qual seria a maneira menos gambiarr

O glorioso retorno do bom senso

Bom, desde minha volda das férias esse é o meu primeiro post técnico, ou quase.

Bom senso está relacionado à razoabilidade. E vale para tudo, de saúde à tecnologia.

Ando vendo por aí muitas pessoas preocupadas demais com o monte de buzzwords do mercado, são as metodologias e certificações de qualidade (ITIL, PMBOK, RUP, Open UP, XP, Scrum, laranja, abacaxi, batatinha) outras relacionadas a linguagens de programação (Java, Python, C#, Ruby) e cada linguagem de programação se desdobrando em infinitos frameworks para os mais diversos assuntos (Hibernate, Fluent, Linq, velocity, rails, django, makumba, spring).

Para complicar há ainda diversos sistemas operacionais, de windows a bada. E por falar em bada, diversos tipos de mobile (android, symbian, windows 7, bada, iOS, McDonalds, China in Box ).

E as ferramentas para documentação de código ou criação de diagramas? ArgoUML, Poseidon, Model Maker...

Nós, que lidamos com tecnologia, somos curiosos por natureza. Mas a curiosidade pode ser uma faca de dois gumes. Ela pode te levar a destruir sua produtividade.

Você que aprender todas as linguagens, metodologias e frameworks? Quer pelo menos conhecer?

Chamemos essa sopa de letrinhas de siglas e neologismos que nascem aos montes todo dia simplesmente de buzz-tools. Algumas realidades  sobre eles que podem ser dolorosas:

1) Você não vai ficar rico se souber todas as buzz-tools.
2) Você não vai ganhar mais dinheiro que seu colega por sua buzz-tool ser melhor ou mais nova.
3) Aprender todas as buzz-tools é como aprender todas as linguagens naturais. Não importa se você tenha pós doutorado na área de Ciência da computação ou áreas correlatas, a verdade é que nem todo pós doutor em letras, por exemplo, fala mais de 10 idiomas. Alguns sabem fluentemente 3 e olhe lá. Todos os idiomas da Terra então, impossível.
Médicos pós doutores também não podem lhe dar vida eterna, nem novos olhos ou novas pernas.
4) Se tentar estudar todas as buzz-tools não se aprofundará em nenhuma delas, não fará nada produtivo e será um especialista em "Hello World", pois será só isso que irá fazer.
5) Convenhamos, se a cada dia aparece uma nova buzz-tool, chegará um momento em que existirá no mundo todo apenas meia dúzia de projetos feito em cada ferramenta, já que o número de ferramentas é tão grande.

O ponto onde quero chegar é que nem todas as buzz-tools precisam ser estudadas. Não que elas não sejam boas (algumas realmente não o são) ou que não mereçam ser estudadas. Mas é que você não vai aplicar todos os seus conhecimentos em todos os projetos. E perceberá que os seus melhores projetos serão os que você usou SEUS conhecimentos, SUAS idéias e SUA criatividade, sem usar padrões, metodologias e buzz-tools. (ou independentemente da que use).

Nenhuma revista, tutorial, fórum ou livro de buzz-tools pode te ensinar a ter criatividade e imaginação. Talvez um litro de cachaça te ensine mais sobre imaginação do que uma enciclopédia de assembly e todos os livros do Dijkstra e Tanembaum juntos.

Pense nisso. Buzz-tools são soluções, ferramentas. Você nunca criará uma solução ou ferramenta se o seu foco for em outras soluções ou ferramentas. Você deve ter o foco no problema. Para criar um bom programa você deve TER um PROBLEMA, FOCAR  no PROBLEMA e desenvolver a SUA SOLUÇÃO. Não outro  problema. Os únicos softwares que fogem a essa regra são os softwares para fins lúdicos como os games. Esses são mais complicados porque você não deve criar uma solução, mas sim criar um problema (de preferência solucionável com uma certa dificuldade).

Para desenvolver algo realmente complexo, útil e bem feito deve-se desprender totalmente das buzz-tools, abraçar o abstrato e seguir em frente, mesmo que seja em VB6 .... pronto, falei.

NÃO EXISTE MELHOR FERRAMENTA QUE O BOM SENSO.

Comentários

Postagens mais visitadas deste blog

Busca de CEP com o Lazarus - Parte 1 - UrlEncode

Botão Add This para adicionar seu post em qualquer rede

Uso de memória no SQL Server