Ultimamente, tenho notado muitas perguntas relacionadas a diferentes técnicas de abstração, e respostas dizendo basicamente que as técnicas em questão são "muito inteligentes". Eu acho que parte de nossos trabalhos como programadores é determinar as melhores soluções para os problemas que temos para resolver, e a inteligência é útil para fazer isso.

Portanto, minha pergunta é: as pessoas que pensam que certas técnicas de abstração são muito inteligentes em oposição à inteligência em si , ou há alguma outra razão para a objeção?

Edição: Este combinador analisador é um exemplo do que eu consideraria um código inteligente. Eu baixei e examinei por cerca de meia hora. Então eu passei pela expansão macro no papel e vi a luz. Agora que eu entendo, parece muito mais elegante que o combinador de analisador Haskell.

Soluções simples são melhores para manutenção a longo prazo. E nem sempre se trata de familiaridade com o idioma. Uma linha complexa (ou linhas) leva tempo para descobrir, mesmo se você for um especialista no idioma especificado. Você abre um arquivo e começa a ler: "ok, simples, simples, entendi, sim, WTF ?!" Seu cérebro pára bruscamente e agora você precisa parar e decifrar uma linha complicada. A menos que haja uma razão mensurável e concreta para essa implementação, ela é "inteligente demais".

Descobrir o que está acontecendo fica progressivamente mais difícil à medida que a complexidade cresce de um método inteligente para uma classe inteligente e um padrão inteligente. Além das abordagens conhecidas, você precisa descobrir o processo de pensamento que criou a solução "inteligente", o que pode ser bastante difícil.

Dito isto, odeio evitar um padrão (quando seu uso é justificado) apenas porque alguém pode não entendê-lo. Cabe a nós, como desenvolvedores, continuar aprendendo e, se não entendermos algo, é um motivo para aprendê-lo, não para evitá-lo.

Princípio do KISS

Mantenha isso simples, idiota. Soluções inteligentes são ótimas, mas geralmente a solução mais simples e direta é a melhor.

“A depuração é duas vezes mais difícil do que escrever o código em primeiro lugar. Portanto, se você escrever o código da maneira mais inteligente possível, por definição, você não é inteligente o suficiente para depurá-lo. ”

Brian Kernighan

Os tolos ignoram a complexidade; os pragmáticos sofrem; especialistas evitam; gênios o removem. - Alan Perlis

A melhor solução nem sempre é a solução mais inteligente. Às vezes, soluções simples são igualmente boas.

No software, você sempre precisa pensar em termos de manutenção. Se um pedaço de código é inteligente demais para alguém que vai mantê-lo, eu diria que a inteligência não vale a pena.

Para citar Brian Kernighan:

“A depuração é duas vezes mais difícil do que escrever o código em primeiro lugar. Portanto, se você escrever o código da maneira mais inteligente possível, por definição, você não é inteligente o suficiente para depurá-lo. ”

a inteligência é uma ferramenta; por si só, não é prejudicial. Só se torna prejudicial no contexto onde não é necessário.

"Inteligente", quando aplicado ao código, quase sempre é apenas um eufemismo para "desnecessariamente complicado".

Ler código bom, claro e simples já é bastante difícil. Ler código "inteligente" é como estudar poesia latina mais uma vez.

A confusão surge porque "inteligente" como atributo de uma pessoa tem um significado completamente diferente. Este caso também pode ser visto como um exemplo de por que é difícil projetar software para pessoas reais: porque são ambíguas.

E como alguns programadores sofrem para entender os protocolos sociais que a maioria das pessoas segue, o que os proíbe de denunciar diretamente o código como "desnecessariamente complicado", eles podem achar difícil diferenciar os dois significados da palavra inteligente . Ao contrário do que alguns pensam, acho que, em última análise, melhores "pessoas" (significando: pessoas que têm empatia, introspecção e paciência) são melhores desenvolvedores. Porque eles sabem para quem escrever.

A maioria das pessoas está se concentrando na inteligência de um aspecto de "O código requer muita decifração para descobrir o que está fazendo" e todas as coisas ruins que acompanham isso, como

1. Ninguém mais pode descobrir, muito menos mantê-lo / depurar.
2. A pessoa que escreveu nem sabe o que faz.
3. Na verdade, pode não ser tão brilhante assim para começar
4. etc ....

Tudo bem, mas há outro aspecto negativo da esperteza e esse é o antigo problema do ego. Isso causa problemas ao longo das linhas de

1. Alguém que é "inteligente" demais para usar as soluções de outras pessoas. Por que procurar o que outras pessoas fizeram quando você pode inventar sua própria maneira de esfolar o mesmo gato?
2. Alguém que pensa ter inventado a solução mais legal para um problema geralmente se recusa a aceitar qualquer opinião.
3. Não permitirá que ninguém modifique o código "deles", mesmo quando houver problemas óbvios ou for necessária uma alteração trivial.
4. De um modo inverso, eles pensam que são inteligentes e precisam usar a técnica "mais recente" para provar o quão inteligentes são, mas não conseguem identificá-la bem em projetos pessoais ou em códigos de não produção antes de lançá-los em partes críticas o sistema.

Às vezes somos todos culpados de muito ego, mas quando isso atrapalha a equipe, é um problema.

Boa Inteligência - alta proporção entre linhas de código inteligentes e linhas de uma alternativa não inteligente. 20 linhas de código que evitam que você escreva 20000 são extremamente boas. O Good Clever trata de salvar seu trabalho.

Bad Clever - baixa proporção entre linhas de código escritas e vs. linhas de código salvas. Uma linha de código inteligente que evita que você escreva cinco linhas de código é Bad Clever. Mau esperto é sobre "masturbação sintática".

Apenas para observar: Bad Clever quase nunca é chamado de "Bad Clever"; ele costuma viajar sob os pseudônimos "bonito", "elegante", "conciso" ou "sucinto".

Eu tenho que pensar sobre a definição de inteligente de todos.

Pessoalmente, sinto que tenho sido inteligente quando enfrentei um problema difícil e complexo e o implementei de maneira muito simples e direta, mantendo um nível aceitável de eficiência.

tl; dr me sinto inteligente quando, durante uma revisão de código, meu revisor diz "uau, isso foi mais fácil do que eu pensava que seria", em oposição a "wtf é tudo isso .."

Além das respostas da teoria listadas, muitas vezes isso é usado no contexto de muito inteligente para todos os outros.

Mova-se entre uma equipe de alto desempenho e uma equipe de manutenção de nível médio em algum momento para ver as diferenças da vida real no que é "inteligente demais".

Deixando de fora os argumentos da teoria, muito inteligente é muitas vezes baseado no que os membros menos qualificados da equipe podem trabalhar razoavelmente, por isso é muito relativo ao ambiente.

Às vezes eu tenho sido tão esperta que me enganei.

Desempenho, manutenção, pontualidade e baixo custo são as formas de medir uma solução. Eu acho que inteligente também pode fazer parte de uma solução, desde que não afete negativamente essas qualidades.

Se um código inteligente + a quantidade de comentários necessários para torná-lo um código compreensível <= código simples, então digo: vá para o código inteligente. Toda vez.

Acho que o problema surge quando as pessoas que escrevem "código inteligente" deliberadamente deixam de comentá-lo corretamente, porque somente por ser inicialmente incompreensível as gerações futuras que o encontrarem terão que gastar tempo "apreciando" como é inteligente.

Lembro-me de uma citação que já vi atribuída a muitas pessoas diferentes, como costumam ser as boas citações.

Parafrasear:

Qualquer pessoa inteligente pode tornar o complexo simples, é preciso um gênio para tornar o complexo simples.

Tomar uma ideia complexa e simplificá-la para que seja compreensível mostra a esperteza do construtor, mas pegar uma ideia simples e torná-la complexa mostra que o construtor deseja ser visto como inteligente.

Se a solução 'inteligente' é difícil de descobrir, ela não deve ser usada. Por exemplo, se através de efeitos colaterais você pode contratar um cálculo complexo para uma linha, é inteligente. Mas se levar uma hora para alguém descobrir o que você fez no mundo, é muito inteligente.

Na minha opinião, a inteligência em si não é um problema. Normalmente, podemos fazer confusões sobre o código "inteligente" (sem sarcasmo) e o "insightfull". O que eu vejo como um problema é o fato de que geralmente o código "inteligente" (com sarcasmo) contém requisitos implícitos não visíveis, dificultando a depuração e a manutenção ao longo do tempo.

Existem vários algoritmos conhecidos que são inteligentes. Quicksort é um, IMO.

O código "inteligente" (com sarcasmo) geralmente faz suposições sobre as variáveis ​​que estão sendo definidas e os estados do sistema que estão virtualmente desconectados do código "inteligente" (como arquivos abertos anteriormente, conexões de rede, bancos de dados, etc ...).

A quantidade de dados que você precisa carregar no seu cérebro para manter corretamente um código "inteligente" geralmente é grande demais para ter uma boa relação custo-benefício.

"Código inteligente" é qualquer código para o qual o programador tenha que pensar muito ou usar alguma habilidade avançada para escrevê-lo. O problema com isso desconsidera a necessidade de uma certa "margem de esperteza", melhor expressa por Brian W. Kernighan:

"A depuração é duas vezes mais difícil do que escrever o código em primeiro lugar. Portanto, se você escrever o código da maneira mais inteligente possível, você não será, por definição, inteligente o suficiente para depurá-lo."

Porque o que parece ser inteligente para um desenvolvedor em uma explosão de criatividade pode simplesmente passar por confusão e ser apenas um bloco ilegível e inatingível de enigmas obscuros para os outros.

Ainda assim, é um bloco de enigmas bom, inteligente e com bom desempenho, mas se você tiver a experiência, muitas vezes perceberá que isso custará muito mais aos seus negócios (não a você, o desenvolvedor) para manter essa coisa no médio prazo. ou a longo prazo. Então, você prefere acalmar o ardor de seus colegas desenvolvedores quando eles se deixam levar.

Exceto, é claro, se há uma justificativa para a esperteza. E se houver uma boa documentação que acompanha a coisa ofuscada que você acabou de escrever. Você comentou esse pedaço de código inteligente, certo? Explique sua intenção, por que precisa ser e como se comporta?

Se não houver justificativa, provavelmente é apenas a otimização prematura, a engenharia excessiva ou um problema do tipo YAGNI. Se forem necessários 15 níveis de indireção para fazer algo simples, há uma boa chance de você também se enquadrar nas categorias anteriores. E se não estiver documentado, será apenas um problema.

Um ótimo código não deve exigir que o mantenedor esteja 100% o tempo todo para entendê-lo. Um bom código é inteligente. Um ótimo código pode ser quase tão eficiente, mas melhor em muitos outros aspectos. Um ótimo código não deve exigir um IDE com 15 visualizações para seguir o design do seu aplicativo.

Nota: ei, eu escrevi algumas coisas que achei inteligentes, mas que atraíram o WTF? da boca do meu gerente, se não dos meus co-desenvolvedores. Tem que olhar para isso da perspectiva deles.

Costumo ser inteligente , mas me esforço para ser elegante .

Desenvolva o código agora que outras pessoas não tentarão evitar mais tarde .

Esta é minha compreensão do problema, com base na minha experiência e nas outras respostas:

1. O código que exigia inteligência para escrever, mas que sai legível e de manutenção não é considerado prejudicial. No entanto, a maioria dos desenvolvedores não chamaria esse tipo de código de "inteligente"; eles podem usar um termo diferente como "elegante". Pode ou não haver algum debate sobre se esse código existe.
2. O código de produção que exige tempo e esforço significativos para a compreensão, mesmo por um desenvolvedor experiente familiarizado com o idioma, é "inteligente" e considerado prejudicial a todos.
3. O código de produção que requer tempo e esforço significativos de desenvolvedores inexperientes é considerado prejudicial para alguns. Vi respostas de qualquer maneira e trabalhei com desenvolvedores que disseram explicitamente que prefeririam manter tudo "o menor denominador comum".

Eu conheço um cara; ele é provavelmente a pessoa mais brilhante que eu já conheci. Ele é definitivamente um programador inacreditável, provavelmente melhor do que jamais serei em toda a minha vida em termos de pura programação. Ele escreve código como se estivesse digitando um documento do Word e pode reverter uma lista vinculada como você não acreditaria. Se você quer falar sobre escrever um código seriamente complexo, ele é seu homem e se eu me deparo com um problema incrivelmente difícil, sempre recorro a ele. No entanto, trabalhar em um projeto com ele em um ambiente de equipe é torturante. Ele não consegue direcionar diretamente o problema comercial e fornecer uma solução lógica, eficiente e concisa para ele. Para ele, uma lista de códigos de 1000 linhas seria melhor que 100. Em vez de usar as ferramentas fornecidas a ele via IDE ou estrutura, ele lançará sua própria ferramenta super otimizada.

Embora admire sua capacidade de fazer essas coisas complexas, o que preciso é de alguém que possa resolver o problema e seguir em frente. Não é bom dizer ou admitir, mas às vezes em um ambiente de negócios é tudo e você precisa resolver o problema e seguir em frente com sua vida. Você sempre pode voltar mais tarde e refatorar o inferno para melhorar seu código. Há uma linha tênue entre ser inteligente e também ser uma dor na bunda. Meu lema para minha equipe é sempre, qual é a coisa mais simples possível que funcionará nessa situação e depois seguirá em frente. Às vezes, mais simples nem sempre é a resposta, mas é um bom lugar para começar.

"Inteligente", neste contexto, significa "inteligente demais para seu próprio bem", isto é, algo que funciona agora, mas será um pesadelo para entender e mudar mais tarde.

Especialmente se for um truque que explora um recurso obscuro da linguagem de programação, ou utiliza efeitos colaterais estranhos, ou é uma maneira realmente bizarra de resolver o problema na linguagem de destino.

Eu prefiro soluções simples, gosto muito da maneira ruby. Quando você deseja, por exemplo, somar os 2 primeiros elementos da lista. primeiro você corta a lista para que ela tenha tamanho = 2 e depois a soma.

Lembro que uma vez usei 1 lista em vez de 3 e criei uma grande função que era muito difícil de manter / alterar.

no mundo de hoje, não precisamos sacrificar a clareza do código pelo desempenho (exceto c ++, eles não precisam, mas sim).

Normalmente, quando você precisa ser "inteligente", é possível solucionar um problema no código. Se for uma solução alternativa e não muito direta, você terá muitas faces confusas ou outros efeitos colaterais estranhos ao assumir determinadas condições (que podem ser 100% corretas no momento da escrita do código)

Assim inteligente == confuso == ruim :( Mas também é incrível como eu os usei para soluções práticas para problemas limitados.

Cotando novamente para contexto e compreensão mais fácil:

"A depuração é duas vezes mais difícil do que escrever o código em primeiro lugar. Portanto, se você escrever o código da maneira mais inteligente possível, você não será, por definição, inteligente o suficiente para depurá-lo."

O que Brian Kernighan escreveu aqui obviamente se refere à convolução, e ele erroneamente usou a palavra inteligente.

"A depuração é duas vezes mais difícil do que escrever o código em primeiro lugar. Portanto, se você escrever o código o mais complicado possível, por definição, você não é inteligente o suficiente para depurá-lo."

Convolução:

A thing that is complex and difficult to follow.

Esperto:

Showing intelligence or skill; ingenious

Programadores instruídos sabem que código simples é engenhoso. Um código o mais inteligente possível deve ser simples por definição. Programadores educados também evitarão trabalhar e escrever código complicado como a praga. Eles também transformarão código complicado em código inteligente sempre que tiverem a chance. O código geralmente começa complicado e aborda a esperteza, à medida que o conhecimento sobre o domínio e a compreensão da capacidade cognitiva humana na programação é melhor compreendido através da experiência e do conhecimento compartilhado.

Devido à popularidade dessa citação e ao Brian Kernighan ser bastante popular na indústria, esse uso indevido da palavra tem um impacto social negativo e eu sinceramente gostaria de ver isso abordado pelo próprio homem. Antes de escrever este artigo, tentei ver se podia simplesmente enviá-lo por e-mail, mas não consegui encontrar nenhuma informação de contato por e-mail que entendesse :(.

O impacto social negativo que tenho visto é de outros programadores que ostracizam com seus colegas mais inteligentes, porque agora veem a inteligência como um problema. O verdadeiro problema são os colegas estúpidos que pensam que estão sendo espertos, fazendo as coisas de uma nova maneira unidiomatic, e constantemente inventando coisas novas quando não há vantagem em vez de obter e entender a comunidade maior e reutilizar idéias inteligentes o máximo possível.

Preciso esclarecer que, muitas vezes, obter entendimento é mais difícil do que inventar o seu. Por causa do problema comum na indústria de prazos irreais, inventar o seu próprio para um problema de nicho menor será usado para economizar tempo. Isso se baseia na observação de que coisas úteis e reutilizáveis ​​geralmente têm como alvo um nicho maior ou fornecem uma abstração útil para a invenção. Também se baseia no fato de que as pessoas visam nichos grandes para ganhar mais dinheiro, quando isso geralmente torna a ferramenta extremamente difícil de usar devido à complexidade envolvida em tornar algo utilizável para uma ampla área de aplicativos.

O outro impacto social negativo é que isso impede o progresso e o desejo de compreender, porque em nosso mundo egocêntrico imediatamente negaremos nossa própria falta de entendimento e anularemos o código de como sendo complicado, mesmo que, uma vez entendida, a idéia seja realmente bastante inteligente.

TODO Gostaria de citar algumas referências, mas também gostaria que a falta de referências não impedisse minha capacidade de compartilhar informações, por isso cito rapidamente o que me lembro como as fontes de minhas informações e talvez eu encontre as informações reais dia (ou você pode encontrar para mim! :)

• A palestra de Guido Van Rossum sobre loops de eventos e como ele os entendeu
• Um funcionário do GitHub que afirmou que evita contratar pessoas inteligentes no Y-Combinator
• Grande parte da discussão e aprendizado que ocorre na comunidade Python. A comunidade Python é especialmente crítica em relação a novas idéias, mas não descarta novas idéias que eles não entendem de imediato, e normalmente você pode ver os recursos que foram inicialmente considerados complicados e a luz do dia como um recurso / pacote da linguagem principal.
• Minha própria experiência e opinião profissional com base em minhas observações de 10000 pés. No entanto, não consigo ver as especificidades a serem esclarecidas :( Esperemos que sua experiência e observação lhe digam a mesma coisa e que alguém possa comentar abaixo para dar algum mérito a esta resposta.

Sinta-se livre para adicionar suas próprias citações! Além disso, fique à vontade para adicionar vírgulas ao meu texto. Não atualizo meu conhecimento sobre o uso de vírgula em inglês há algum tempo ...

Porque muitas vezes as pessoas não conhecem um idioma, expressões idiomáticas e padrões. Eles poderiam pegar um livro e aprender, mas não o fazem. E por causa dessas pessoas, você deve escrever um código simples.

Não é uma inteligência. É um conhecimento.

Como não consegui encontrar a palavra disciplina mencionada em nenhum lugar por aqui, vou entrar. Não quero postar a resposta, mas compartilhar uma visão diferente sobre o assunto, talvez uma que a pergunta original não tenha em mente. .

Um desenvolvedor inteligente é uma coisa boa.

No entanto, antes da inteligência vêm outras características. Como você deve ter percebido, falarei sobre disciplina . Um desenvolvedor inteligente e indisciplinado pode ser muito ruim para a manutenção de longo prazo do sistema.

Suponha que surja um erro ou que um novo requisito apareça. Um desenvolvedor inteligente poderá em breve perceber que algumas correções locais farão o trabalho em 2 minutos. Se esse desenvolvedor for disciplinado, ele evitará aplicar essas correções no código-fonte e, em vez disso, encontrará uma maneira significativa de compor o comportamento desejado para o sistema. Dessa forma, na próxima vez que surgir a necessidade de modificar partes específicas do código, o mantenedor terá um tempo fácil para entender o código e implementar as novas alterações sem interromper nada. Se não, bem, você entendeu.