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

Primeiro de Abril dos programadores

Quem é do ramo de TI sabe o que são as normas RFC. São conjuntos de convenções onde são estabelecidos padrões para que computadores possam se comunicar e trocar dados entre si, e para que esses dados sejam reconhecidos por todos. Se não fossem essas normas o mundo da TI seria um caos (e já não é).

É insteressante o fato de que a norma RFC 2550 foi criada em 1° de abril de 1999, e tratava do bug y2k, o bug do milênio. Desde que a convenção de dadas expressa em 2 dígitos para o ano foi criada sabia-se que em 2000 isso ia dar merda parar de funcionar, mas mesmo assim a solução foi deixada para 1999, a véspera.

Lendo a norma, é possível encontrar o seguinte texto, bem - humorado apesar da seriedade e sobriedade das normas RFC:


" Nearly everyone now regrets the
   short-sightedness of the programmers of yore who wrote programs
   designed to fail in the year 2000.  Unfortunately, the current fixes
   for Y2K lead inevitably to a crisis in the year 10,000 when the
   programs are again designed to fail."


Numa tradução livre:

"Quase todo mundo lamenta a falta de visão dos programadores de antigamente, que criaram os programas já designados para falhar em 2000. Infelizmente, as correções correntes para o Y2K conduzirão inevitavelmente a uma crise no ano 10.000, quando os programas falharão novamente"

Sei lá, eu nunca esperaria encontrar esse tipo de ironia sutil numa norma RFC mas é a mais pura realidade: prepare-se porque todos os programas falharão no ano 10.000, o que fizemos foi uma gambiarra que tem 8000 anos de duração.

Há também na norma um padrão de nomenclatura para o bug do ano 10.000, chamado de YXK, em algarismos romanos (X) ou YAK, em hexadecimal (A = 10).

Seja pró-ativo, não espere o pior acontecer, antecipe-se, corrija agora mesmo o bug do ano 10.000 no seu software :)

Isso poderá gerar royalties e patentes para os seus tatatatatatatatatatatatatatatata (são 14 ou mais tatas?) ranetos.

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