Parece muitas vezes no stackoverflow, que as pessoas (especialmente os programadores) tendem a complicar demais uma solução para um problema, onde a solução é muito mais complicada do que o problema original? Eu não sou um especialista de forma alguma, mas muitas vezes eu tento usar a solução mais simples que funciona (e obviamente isso não funciona EM TODA PARTE), mas tive um bom sucesso ao sugerir soluções simples no trabalho que as pessoas parecem ignorar para soluções MUITO mais complicadas?

Isso é algo normal para programadores ... ou simplesmente não estou pensando na perspectiva correta.

Obviamente, alguns programadores estão ansiosos para mostrar o quão inteligentes são, criando um código escandalosamente complicado que ninguém consegue entender. Outros programadores estão disparando em um nível tão alto que a complicação nas soluções é uma evolução natural.

Um dos piores códigos que já vi foi um método que continha mais de 2000 linhas de código. Sem dúvida, esse código era complexo, mas também era muito ruim.

Eu acho que um bom programador evita código excessivamente complicado. Isso inclui evitar a tentação de forçar um padrão de design a se encaixar em uma solução que realmente não exige. Também inclui evitar objetos de Deus, botões mágicos, otimização prematura, generalização prematura e outros antipadrões.

Estou constantemente refatorando e procurando oportunidades para simplificar minhas soluções, porque o crescimento da complexidade é uma coisa orgânica. Como muitas outras coisas orgânicas, ele deve ser aparado e podado, se quisermos que continue sendo útil. Eu odeio ter que interagir com soluções excessivamente complicadas porque, com maior complexidade, aumenta a probabilidade de quebrar o código.

Penso que a legibilidade é o elemento mais importante da manutenção do código, e as soluções excessivamente complicadas quase sempre diminuem a legibilidade e aumentam os custos de manutenção.

Eu já vi muitos códigos mais complexos do que precisavam e quase sempre por esses três motivos:

1) Engenharia excessiva devido à generalização prematura ou à tentativa de antecipar necessidades futuras que nunca surgiram

2) Os desenvolvedores queriam aprender / experimentar um novo padrão ou tecnologia de design que eles não usavam antes e colocá-lo em prática mesmo quando havia um exagero. Eles fazem isso porque isso torna seu trabalho mais interessante e eles aprendem algo novo.

3) Recursos e correções foram adicionados, mas o código existente não foi refatorado corretamente no momento. Pode ser apenas um pequeno pedaço de duplicação ou colocar outro argumento de flag em um método, mas tudo se soma. Efetivamente, hacks são adicionados e não demora muito para que tudo fique muito complicado devido a todo o cheiro do código. Este é o mais comum e geralmente devido ao desconhecimento ou pressão do tempo.

É absolutamente uma coisa comum. Como a maioria dos livros diz, um bom desenvolvedor sabe como mantê-lo simples. É muito fácil complicar demais algo com uma nova tecnologia ou uma estrutura "legal" que você acabou de encontrar, para começar a procurar maneiras de usá-lo, em vez de pensar da perspectiva dos problemas.

Como Martin Fowler disse, aqueles que aprendem uma nova tecnologia têm um problema de curto prazo em que suas soluções direcionadas à "tecnologia".

Não acho que seja normal para todos os programadores, mas definitivamente vi muitos programadores fazer isso.

Eu acho que algumas pessoas acreditam que algumas pessoas veem tornar algo realmente simples 'muito fácil', e que não é uma boa demonstração de suas habilidades. Portanto, eles precisam criar uma solução grande e complexa, que possa dizer 'veja o que eu posso fazer!', Mesmo que essa não seja a melhor solução para o problema em questão.

Vi programadores frequentemente escreverem várias linhas de código para realizar uma tarefa que eles não sabiam que já estava embutida na linguagem. Isso não é exatamente intencional, mas certamente pode ser evitado.

Depende do que você chama de "simples". Algumas pessoas veem o código altamente refatorado como mais "complexo" porque há mais código e vários gráficos de chamada. No entanto, esse código é mais "simples", pois é muito mais fácil fazer alterações.

Costumo achar que uma função grande parece "simples" até que você precise fazer alterações, depois fica complexa rapidamente.

Em outras palavras, simples está nos olhos de quem vê, em muitos casos.

O problema é que você não consegue ver claramente as soluções simples (é aqui que entram as discussões com os colegas) ou se você generaliza demais cedo demais.

Em outras palavras, você cria loops simples em funções avançadas da biblioteca porque pensa que que será necessário para o seu próximo projeto de qualquer maneira (exceto que não será desta forma exata). Faça isso por muito tempo e você terá um aplicativo imensamente complexo com um núcleo muito simples.

Você também pode achar que precisa ter um código muito robusto, e toda a robustez o torna complexo por padrão. Eu não acho que esse seja o seu problema, no entanto.

Em alguns casos, pode ser apenas a complexidade de encontrar uma solução limpa / simples.

Há uma citação que eu não consigo lembrar ou achar que vale algo sozinho, as linhas de "Código não está completo depois que você escreveu tudo o que precisa escrever, mas é concluído apenas quando você não tem mais nada a remover"

A falta de clareza dificulta a capacidade das pessoas de remover todo o excesso.

Os melhores engenheiros são os que conseguem resolver problemas realmente complicados e transformá-los em soluções fáceis de implementar e entender. Parece simples, mas não existem muitos engenheiros / desenvolvedores como esse. De fato, não existem muitas pessoas assim que existem. Na realidade, a maioria das pessoas lá fora faz exatamente o oposto. Eles pegam problemas simples e os complicam além do reconhecimento. Basta olhar para nossos políticos em busca de um exemplo de pessoas que conseguem resolver problemas simples e transformá-los em caos total. Programadores não são diferentes a esse respeito.

Pessoalmente, nunca tentei intencionalmente tornar um software mais complicado. No entanto, eu terminei algo e pensei "uau, isso é muito complicado" e voltei a ele e refatorado. Algumas pessoas podem ver isso e apenas pensam que funciona e é bom o suficiente e não o refatoram.

Um homem sábio teria dito que você deveria manter as coisas o mais simples possível, mas não mais simples. O mesmo pode se aplicar ao código. Às vezes, é necessário usar uma técnica que alguns consideram complexa (a recursão pode ser um bom exemplo, geralmente assusta os programadores juniores).

No entanto, em geral, acho que código complexo geralmente surge organicamente. Um problema simples é resolvido com um código simples, então o escopo se expande e o código é modificado sem muita reflexão. Com o tempo, você obtém um código que tenta cobrir o novo problema, mas foi realmente projetado para resolver um problema diferente. Torna-se uma colcha de retalhos de diferentes peças de lógica. Em geral, esse código pode parecer muito mais complexo do que o problema exige, mas ficou assim porque cada pequena alteração parecia, na época, a maneira mais fácil de fazer o código funcionar.

Eu não acho que a maioria dos desenvolvedores decidiu deliberadamente tornar o código complexo (embora você tenha uma ideia estranha de quem usará alguma técnica para provar sua própria habilidade), acho que o código fica assim se não for mantido e refatorado agressivamente .

Outro motivo que ainda não foi levantado é que as pessoas podem complicar demais as soluções fornecidas para garantir que você precisará dos serviços deles posteriormente para dar suporte a essas soluções. Em outras palavras: para segurança no emprego.

Talvez um problema de um erro clássico?

30. Desenvolvedor de revestimento de ouro.

Os desenvolvedores são fascinados por novas tecnologias e, às vezes, estão ansiosos para experimentar novos recursos de seu idioma ou ambiente ou para criar sua própria implementação de um recurso sofisticado que viram em outro produto - seja ou não exigido em seu produto. O esforço necessário para projetar, implementar, testar, documentar e dar suporte a recursos desnecessários aumenta o cronograma.

• Steve McConnell, Desenvolvimento Rápido.

Sim, às vezes complicamos demais o código para nos divertir. Principalmente, embora a percepção de que o código esteja sendo excessivamente complicado venha de um participante ignorante ou júnior do projeto.

SIM ... e eu paguei o preço muitas vezes.

Meu quadro branco agora tem uma declaração em asteriscos no topo, que diz

"Se não é simples, não está certo"

... e sempre que protótipo de algo no quadro branco, sempre me chama a atenção.

Realmente funciona para mim porque meus projetos complexos se tornam muito mais simples, o que se traduz em código mais limpo.