ORM é um atoleiro?

#engenhariaDeSoftware #oop #pelancas
"falandosobre.software"
“ORM represents a quagmire which starts well, gets more complicated as time passes, and before long entraps its users in a commitment that has no clear demarcation point, no clear win conditions, and no clear exit strategy.”
("ORM representa um atoleiro que começa bem, fica mais complicado à medida que o tempo passa e, em pouco tempo, aprisiona seus usuários em um compromisso que não tem um ponto de demarcação claro, condições de vitória claras e nenhuma estratégia de saída clara.")

Esta definição, que está citada no excelente artigo de Mark Rickerby, é uma visão perfeita do que acontece quando embarcamos nessa tragédia do software corporativo.

https://maetl.net/talks/rise-and-fall-of-orm

OOP é um passo em falso?

#engenhariaDeSoftware #oop #pelancas
"falandosobre.software"
"Object-oriented programming languages are a major misstep; a tortuous detour that computer scientists should never have taken" - Ben Lynn, Phd.
("Linguagens de programação orientadas a objetos são um grande passo em falso; um desvio tortuoso que os cientistas da computação nunca deveriam tomar")

Agora, com o tempo e a sabedoria, tenho certeza que sim! OOP é um erro gigantesco, que leva tudo ao caos... Ainda mais se associada a frameworks e patterns "malucos", cujo objetivo final é nebuloso. Mas não precisa acreditar em mim. Leia o artigo de Ben Lynn.

http://crypto.stanford.edu/~blynn/c/object.html

OOP Bullshit

#engenhariaDeSoftware #pelancas #oop
"Não acredite em mim, sou apenas um Brasileiro"
"Object oriented programs are offered as alternatives to correct ones" - Edsger W. Dijkstra
("Programas OO são oferecidos como alternativas aos programas corretos").

O artigo que estou recomendando é curto e sensacional! Uma das suas melhores partes é:

"Recently, I was trying to convince a few of my readers that a better understanding of an object in OOP would help us solve many problems in existing pseudo-object-oriented languages. Then, suddenly, the question came up: "What problems?"

("Recentemente, estava tentando convencer alguns dos meus leitores que uma melhor compreensão do que seria um Objeto, dentro da OOP, poderia nos ajudar a resolver muitos problemas, nas linguagens pseudo-OOP existentes. Então, de repente, a questão surgiu: Que problemas?")

Leia: https://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html

Complexidade

#pensamentoDoDia
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare, Cientista da Computação e inventor do QuickSort.
("Há duas maneiras de construir um projeto de software: Uma maneira é faze-lo tão simples, que, obviamente, não existem deficiencias, e a outra é faze-lo tão complicado que não existem deficiências óbvias. A primeira maneira é muito mais difícil.")

Não acredite em mim! Sou apenas um Brasileiro...

#engenhariaDeSoftware #pelancas #oop #orm
Ok, você não precisa acreditar em mim, afinal, sou apenas um Brasileiro, não? Apesar de 40 anos de experiência, e quase 30 livros publicados, continuo sendo um Brasileiro.
Então, leia este artigo sobre #oop: http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end
E este artigo sobre #orm: https://www.yegor256.com/2014/12/01/orm-offensive-anti-pattern.html. São antigos, mas vão direto ao ponto.
COMPLICAR É BENEFICIAR APENAS AOS FORNECEDORES DE SOFTWARE E HARDWARE!

Como calcular o percentual de gordura do seu software

Sim, você leu corretamente! O software que criamos tem muita coisa que serve para nada, ou seja: pelancas e gordura, mas que nós mesmos "enfiamos" nele por comodismo ou comprometimento.

Aqui vai uma fórmula simples para calcular o percentual de "gordura" e "pelanca" que nosso software tem, e também o quanto gastamos com isso. Se você é um engenheiro ou arquiteto de software, pode otimizar seu projeto com isto, se você é um cliente, pode cortar custos.

YAGNI e as pelancas do software corporativo

#engenhariaDeSoftware #complexidade

“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.”
Edsger W. Dijkstra

SOLID, OOP, ORM, Frameworks... São realmente necessários? Compare duas soluções para um mesmo problema, e tire suas conclusões.

https://www.linkedin.com/pulse/yagni-e-pelancas-do-software-corporativo-de-melo-junior

Interfaces e indireção: Os problemas da OOP e do SOLID!

Sem dúvida, qualquer bom Programador já leu ou ouviu falar dos princípios S.O.L.I.D. certo?

• the Single responsibility principle (SRP),
• the Open-closed principle (OCP),
• the Liskov substitution principle (LSP),
• the Interface segregation principle (ISP), and
• the Dependency inversion principle (DIP).

OOP sem eles, é apenas uma confusão.

Porém, fica uma dúvida: Até onde são úteis? Sim, você me entendeu bem! Até quando devemos nos ater ferrenhamente aos princípios SOLID? Vale a pena em TODOS os casos?