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ística de fazer:1) se Ver…

Verdades sobre programação

Esse blog, do @luisdalmolin, contém um excelente texto sobre verdades não tão conhecidas sobre programação. Não tão conhecidas talvez pelos nossos chefes / stakeholders, mas muito bem conhecidas por nós. O post foi traduzido desse aqui  em inglês.

Basicamente, o texto fala sobre o que já sabemos:
1) Dez programadores não farão o programa em um décimo do tempo assim como nove mulheres não fazem um bebê em um mês. (apenas uma grande suruba lésbica).
2) Bons programadores passam muito mais tempo lendo, estudando, pensando, refatorando do que escrevendo, codificando e debugando. É fato! Scrum e XP pregam isso. O resto é XGH (eXtreme Go Horse).
3) Programadores (e hoje analistas de sistemas também) são tratados como peões, na rabeira do organograma da empresa, muitas vezes mesmo se destacando em sua área, possuindo graduação, pós graduação e certificações, o que significa que um programador é tratado como um operário mesmo tendo estudado tanto quanto (em alguns casos muito mais) um médico ou advogado, e continuar estudando ao longo de TODA sua carreira.
4) Planejamento é fundamental antes, durante e depois.
5) Mesmo os requisitos sendo flexíveis, isso não significa "festa do caqui" com os requisitos. E os prazos e escopo deveriam ser flexíveis proporcionalmente à flexibilidade dos requisitos.
6) Mudanças de requisitos geram entropia, ok, mas mudanças sem planejamento, sem levantamento de requisitos, direto no código, por meio de tentativa e erro até funcionar geram mais entropia ainda, tendendo ao caos, e inevitavelmente vão falhar. FALHARÃO MISERAVELMENTE.

Alguns quadrinhos humorísticos tirados do site Vida de Programador ilustram isso:



Essa outra ilustra bem a situação.


Não podemos esquecer do vídeo hug a developer! Ele ilustra de maneira bem humorada os problemas, desafios e DORES pelas quais um programador passa nas mãos e chefes porcos, cães sarnentos ignorantes ...


Comentários

Postar um comentário

Postagens mais visitadas deste blog

Detectar o encoding de um arquivo para não corromper ao transformá-lo

erro "ora-12154: tns: não foi possível resolver o identificador de conexão especificado"

Factory Reset do Samsung Galaxy S