Quão "simples" é uma solução real do KISS? [fechadas]

Confesso : tenho um problema em "Manter as coisas simples e curtas" na maioria das vezes, porque tentar fazê-lo de acordo com os livros que li, os padrões de design que ouvi etc. me dá tanto entusiasmo - um entusiasmo vindo de a sensação de que estou no caminho certo para uma provável perfeição.

Por outro lado, sim, isso me coloca um estresse extra em termos de prazos às vezes ...

Mas sempre que digo para mim mesmo: "Da próxima vez, mantenha as coisas simples, seu estúpido!" Acho muito difícil torná-lo "simples" na próxima vez, porque começa a parecer estranho ... e desconfortável depois de um ponto.

Então eu começo a julgar meu entendimento de 'simples' ...

SIMPLE significa muito pouco que funciona, mas é difícil de manter e estender?

SIMPLES significa quebrar muitos dos princípios de POO?

SIMPLE significa trapaça?

SIMPLES significa apenas manter os prazos sem dealy? etc.

Na verdade, o que é isso?

A pergunta é : Você pode escrever a definição exata de SIMPLE em termos do princípio KISS? -se houver.

Obrigado!

Vamos aprender um beijo francês:

La perfeition estteinte, non pas lorsqu'il n'y a plus rien a ajouter, mais lorsqu'il n'y a plus rien a aposenter. - Antoine de Saint-Exupéry

Que é traduzido para:

A perfeição é alcançada, não quando não há mais nada a acrescentar, mas quando não há mais nada a ser levado. - Antoine de Saint-Exupéry

Cenário

Você precisa cortar e beliscar.

Solução A: Não é KISS

Solução B: KISS

Quanto a uma definição exata : é difícil definir uma escala absoluta para medir a simplicidade. Principalmente porque a verdadeira simplicidade impede a verdadeira compreensão do problema em questão, e isso raramente é possível. Mas digamos que as soluções A e B ilustrem a diferença entre soluções que tendem à supercomplicação e simplicidade, respectivamente.

"Torne as coisas o mais simples possível, mas não mais simples" -Einstein

Manter o código o mais simples possível, mas não mais simples, depende do problema que está sendo resolvido. Enquanto o problema que está sendo resolvido tende a mudar, o KISS também muda.

Existe um equilíbrio entre o excesso de engenharia (oh, cara, isso parece um ótimo lugar para mostrar minhas habilidades de Design Pattern!) E o sub-engenharia (se eu usasse uma fábrica, não teria esse acoplamento que me levou a fazer 20 código muda ...). O objetivo é a manutenção.

Simples não significa quebrar bons princípios de programação. De fato, significa mais do oposto.

SIMPLE significa muito pouco que funciona, mas é difícil de manter e estender?

Não. Ser difícil de manter e estender é um grande sintoma de complexidade. De fato, acho que tornar o código extensível leva a um código mais simples, já que você não lida com todos os casos, pode manter o código base mais simples.

SIMPLES significa quebrar muitos dos princípios de POO?

Não. A maioria dos princípios de POO é projetada para manter o código mais limpo e organizado, o que, no final, é mais simples.

SIMPLE significa trapaça?

Não. É difícil escrever código para manter códigos e hacks sob o pretexto de manter os prazos.

SIMPLES significa apenas manter os prazos sem dealy? etc.

Não. Os prazos e a simplicidade do seu código são dois problemas separados. Escrever código simples não leva mais tempo para escrever (embora seja um equívoco comum).

Isso é muito complicado de explicar, porque simples não significa a mesma coisa para todos.

Exemplo. Alguns desenvolvedores acham que isso ?:é simples, mas outros acham que uma ifdeclaração é melhor. Quando chegar a este nível, você não pode agradar a todos.

Em geral, simples significa sem complexidade . Para entender a simplicidade, precisamos entender a complexidade.

Existem dois tipos de complexidade:

Complexidade essencial refere-se a uma situação em que todas as soluções razoáveis ​​para um problema devem ser complicadas (e possivelmente confusas) porque as soluções "simples" não resolveriam adequadamente o problema. - Wikipedia

Complexidade acidental é a complexidade que surge nos programas de computador ou em seu processo de desenvolvimento (programação de computadores), que não é essencial para o problema a ser resolvido. - Wikipedia

Você pode verificar a complexidade essencial com as seguintes perguntas:

Esta solução é simples? Posso explicar isso para meus colegas em alguns minutos e eles entenderam? Existe uma solução mais simples para o problema? Se sim, existem vantagens e desvantagens entre a solução complicada e a solução simples? Podemos viver com essas trocas? Por exemplo, muitos programadores cometem um erro ao otimizar tudo e sua solução (e o código também) se torna excessivamente complicada.

Verificando sua complexidade acidental:

O código é simples? Se eu voltar em três meses, quanto tempo levarei para construir o contexto em meu cérebro para que eu possa fazer a mudança que preciso fazer? Tudo no meu código-fonte tem um objetivo claro e transmite esse objetivo efetivamente para mim e para outros desenvolvedores ? Quão difícil é testar meu código? Geralmente, quanto mais complicado é o seu código, mais difícil é o teste de unidade, por isso geralmente uso isso como uma medida de complexidade. Você geralmente deseja classes e métodos pequenos, bem nomeados e focados. Os padrões de design geralmente também ajudam você a alcançá-los.

Se você deseja usar um padrão de design apenas porque acabou de ler sobre ele, provavelmente introduzirá uma complexidade acidental. Se você deseja colocar algo porque acha que é inteligente, provavelmente introduzirá complexidade acidental.

Espero que isso ajude e não esqueça: Simples não significa FÁCIL .

Eu sempre senti que os princípios por trás do X11 ( http://en.wikipedia.org/wiki/X_Window_System#Principles ) valiam a pena. Nem sempre tenho sucesso nesse objetivo.

Especificamente, continuo tendo que me lembrar ... "Não adicione novas funcionalidades, a menos que você conheça algum aplicativo real que exigirá isso." E "Se você pode obter 90% do efeito desejado em 10% do trabalho, use a solução mais simples ".

A pergunta é: Você pode escrever a definição exata de SIMPLE em termos do princípio KISS? -se houver.

Não.

Simples - neste contexto particular, é exatamente o oposto do complexo. Simples não significa necessário: toda pessoa idiota precisa entender - mas você precisa ter certeza de que pode entender, mesmo que não tenha escrito por conta própria.

A complexidade pode ser alcançada se você entender bem as referências - livre-se delas! Muitos arquivos / classes ligados entre si - de jeito nenhum! E código complicado (significando: loops encadeados, várias camadas ITE, etc.) - ninguém quer ler isso.

Na minha opinião: É muito fácil adicionar outra função, nas classes você também pode adicionar funções privadas, para não mexer com a interface. Então, por que não usar essa vantagem e limitar suas funções / procedimentos a 50 linhas? Talvez até menos. Obtenha alguns nomes significativos. Dessa forma, você torna a maioria dos comentários obsoletos. Dessa forma, suas funções são fáceis de ler, fáceis de modificar / estender.

Claro ... as últimas frases teriam funcionado da seguinte maneira: Nas aulas, existe a disponibilidade para definir funções privadas, basta usar esta possibilidade para dividir funções em 50 linhas, para que fique muito mais legível (não se esqueça de bons nomes, então você não precisa comentar muito).

MAS: É muito mais simples (!) Ler tudo, se houver um ponto final que mostre: Eu terminei um pensamento, vamos continuar com o próximo.

Isso é o que eu definiria como simples.