Como treinar para evitar escrever código “inteligente”? [fechadas]

The problem is getting even more pushing as I'm now working with a team of experienced developers, and sometimes my attempts at writing smart code seem foolish even to myself after time dispels the illusion of elegance.

Sua solução está aqui. Estou supondo que "experiente" neste contexto significa "mais experiente do que você". No mínimo, você claramente os respeita. Essa é uma valiosa oportunidade de aprendizado - supondo que seu ego possa suportar o sucesso. (Coisas irritantes, egos. Uma pena que nós precisamos disso.)

Você tem revisões de código com essas pessoas? Se assim for, se eles já não estiverem fazendo isso, peça-lhes explicitamente que chamem você em sua besteira. Mencione que você notou uma tendência em si mesmo de projetar demais, usar uma britadeira pneumática top de linha meticulosamente projetada (de preferência empunhada por algum tipo de andróide automatizado de trabalhador de estrada) quando um simples martelo seria mais do que suficiente .

Você pode encontrar-se freqüentemente se contorcendo em seu lugar enquanto seu rosto fica vermelho durante as revisões de código. Suportar isso. Você está aprendendo.

Então, uma vez que você tenha algumas dessas informações, preste atenção nos momentos em que suspeita que talvez esteja super projetando. Quando esses momentos chegarem, pergunte a si mesmo: "Se alguém me denunciar durante a revisão do código, posso defender minha solução como a melhor disponível? Ou há uma solução mais simples que estou abandonando?"

Às vezes, a revisão por pares é a melhor maneira de ver bem o seu próprio trabalho.

A melhor coisa a fazer é ter em mente a máxima de Brian Kernighan:

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

Normalmente, existem pelo menos três soluções para problemas de software de qualquer importância: a maneira óbvia, uma maneira complexa não óbvia (inteligente) e uma maneira simples não óbvia (elegante). Uma citação sobre autores é aplicável aqui:

Put down everything that comes into your head and then you're a writer. But an author is one who can judge his own stuff's worth, without pity, and destroy most of it. — Colette

Você não poderá escrever código elegante até que possa julgar o valor de seu próprio código, sem piedade, e destruir a maior parte dele. Se você julgar um código elegante pelo resultado final, ele parecerá enganosamente fácil, mas requer uma desaceleração, passando por muitos rascunhos, buscando o conselho dos outros e extirpando o que não está na página. Isso significa que mesmo que seu código esteja funcionando perfeitamente, você pergunta a si mesmo ou a um colega por que algo não parece certo, até que você esteja satisfeito com a resposta. Talvez pareça muito longo, ou repetitivo, ou você acha que o compilador deveria ter sido capaz de detectar um certo tipo de bug. A maioria dos programadores com um mínimo de experiência pode reconhecer código deselegante com facilidade. O truque é descobrir por que .

Essa é a maneira metódica de escrever código mais elegante. Ele também requer frequentemente um flash de insight que ajuda você a analisar um problema de uma nova maneira. Isso é mais difícil de conseguir, mas ajuda a desacelerar e apenas pensar em um problema antes de mergulhar na codificação. Quando você encontrar uma boa solução, procure uma melhor. Ler outro código ajuda. Fazer aulas ou ler livros sobre melhores práticas ajuda. Aprender outros paradigmas de programação ajuda. Pedir conselhos de colegas cujo código você admira ajuda.

Eu adicionaria as respostas existentes, desenvolvesse de maneira TDD, para que você primeiro faça testes sobre o que seu código deve fazer e depois implemente para tornar seus testes mais ecológicos. Desta forma, você estará apenas cumprindo os requisitos que os testes estão impondo. Como você estará escrevendo o teste, é uma boa maneira de desenvolver uma abordagem autodisciplinada.

Ao trabalhar para uma equipe grande e dinâmica que abrange muitos conjuntos de habilidades e anos diferentes, o desenvolvimento tem uma progressão natural para ser "simplificado" até o nível mais baixo do membro mais conservador ou deficiente intelectualmente da equipe. ou histórico.

Isso pode não necessariamente ser uma coisa ruim, porque códigos inteligentes podem ser mais difíceis de depurar, mais difíceis de transmitir em uma especificação técnica e demorar mais para serem escritos, o que diminui o tempo de desenvolvimento.

Há momentos em que um código inteligente é importante, como quando um código inteligente fornece ganhos de eficiência e desempenho mais tarde no ciclo de maturidade do software quando o desempenho se torna um requisito.

O código inteligente também tem uma maneira de transmitir um código mais rápido e legível para uma equipe que não pode ser exposta a um novo recurso de idioma ou uma chamada de biblioteca. Por exemplo, quando fui apresentado pela primeira vez ao Linq por um desenvolvedor júnior, tive um repúdio imediato a ele como desnecessário, difícil de depurar, tolo e "inteligente". Depois de brincar comigo mesmo e descobrir o quão útil e poderoso as consultas do Linq podem ser, investi o tempo necessário para aprendê-lo, e meu código DAL nunca foi tão limpo e legível, quanto mais fácil de depurar e estender.

Eu me arrependo de não ter uma mente aberta antes e gostaria de não ter sido tão duro com um desenvolvedor júnior tão "inteligente".

Meu ponto é que o código "inteligente" DEVE ser suspeito, mas não devemos entrar em uma cruzada contra ele porque pode sufocar a criatividade e a inovação.

EDIT: Acabei de perceber que não respondi totalmente à sua pergunta. Se você tem a capacidade em seu projeto de escrever muito facilmente código inteligente, então talvez a equipe deva adotar padrões de codificação mais rigorosos para seguir um modelo e um estilo uniformes e distintos. Isso ajudará a desenhar as linhas da sua caixa de areia, para que você não saia pela rua correndo atrás de uma bola.

Se 20% (seu% pode variar) ou mais de suas linhas adicionadas precisam ser documentação - é hora de voltar atrás e repensar .

Eu realmente acho que você deve se esforçar para ser inteligente, é um efeito colateral natural de se tornar mais proficiente. Dar a si mesmo uma diretriz geral como% de comentários necessários para ficar claro é uma boa maneira de se forçar a se afastar e avaliar se usar essa nova coisa que você aprendeu é uma escolha sábia ou apenas uma maneira de mostrar seu novo brinquedo. p>     

Eu não resisto a tentar algo inteligente.

Então eu faço em um projeto de brinquedo, no meu tempo, em casa.

Quando a novidade desaparece - problema resolvido.

Acredito que uma maneira de descobrir se seu código é muito "inteligente" é dar um passo atrás e se perguntar o seguinte:

If I were to give a printout of this code to someone who has never worked on this project / code, would they be able to read it and describe back to me what the function does (after giving them some brief context)? If not, how much explaining would I have to do? How would I explain this to someone taking CS101?

Se você precisar percorrer alguém em todas as linhas ou linhas em um método ou classe, provavelmente é muito inteligente. Se você tiver que explicar construções de linguagem (por exemplo, LINQ) para alguém que não esteja familiarizado com ela, provavelmente está tudo bem. Se você tiver que olhar para uma linha e pensar um pouco antes de explicá-la, seu código precisará ser refatorado.

1) Deixe-se queimar antes para que você saiba que é uma coisa ruim. A tentativa de depurar algo de muito tempo atrás que foi escrito de forma inteligente é muito divertida. Eu acho que você tem isso coberto.
2) Comente seu código, explique o que você está fazendo antes de cada seção do código.
3) Se você está lutando para explicar, ou sente a necessidade de inserir um diagrama, então o que você acabou de fazer é muito inteligente e provavelmente poderia ser feito de forma mais limpa.

Soluções inteligentes para problemas podem ser fantásticas, até você precisar depurá-las ou expandi-las. Às vezes é a única solução. Se você puder descrever com precisão exatamente o que faz e como faz, soluções inteligentes podem ser aceitáveis.

Eu costumo usar comentários para descrever o que estou fazendo com uma seção de código. Se isso parece confuso, eu também descrevo como estou fazendo isso. Idealmente, o código deve ser direto e auto explicativo. Mas se eu me esforçar para explicar como fiz o que acabei de fazer, então é um sinal claro de que preciso dar um passo atrás e tentar de novo.

Provavelmente, uma boa maneira de começar a escrever código simples é liberar a paixão pela astúcia em um projeto que pede esperteza . O restante da resposta é específico do .NET, mas Tenho certeza de que é possível encontrar projetos de nível semelhante em qualquer outro idioma.

Existem estruturas de injeção de dependência de software livre para trabalhar em que apenas pedir Expression truques conhecimento, há F # e maravilhosa variedade de tarefas que alguém pode querer experimentar.

Se você gosta de matemática (e isso é idioma agnóstico ), existe Projeto Euler para você.

Por último, mas não menos importante, no mundo .NET existe Mono Project que tem muitos áreas que precisam de atenção do desenvolvedor , algumas delas bem complicadas. Que tal contribuir para uma ferramenta de análise de código .NET estática de código aberto ? Há alguma análise de IL envolvida, bem como material de alto nível. O Jb Evain sempre funciona em algo interessante, seja na biblioteca de reflexão do Cecil, no Expression support ou no decompiler do .NET.

Se nada se encaixa, apenas comece sua própria estrutura de zombaria : )

Do you know that feeling when you just need to show off that new trick with Expressions or generalize three different procedures?

Não

Esta é uma das razões pelas quais eu sempre digo que é uma coisa boa quando novos desenvolvedores são jogados em uma grande bagunça de código speghetti não documentado para manter e refatorar. Isso lhes ensinará a realidade de manter um código excessivamente "inteligente" que eles não escreveram, e esperamos que instigue alguma empatia pelo pobre idiota que terá que depurar seu código daqui a 5 anos.

Eu acho que o tema é bem escolhido. É "legal" escrever uma linha de Perl que faça dez mil coisas de uma só vez, mas é uma droga quando você precisa revisitá-la.

Em uma nota diferente, inteligente ou não, o código deve ser documentado. Há um desajuste de impedância inerente entre as linguagens de programação aceitas pela indústria e os conceitos de alto nível que nós, como humanos, estamos acostumados em nosso pensamento. O código de auto-documentação simplesmente não é realizável - até que se torne linguagem natural, isto é. Mesmo o código do Prolog precisa ser documentado, pois, mesmo sendo de alto nível, ainda é bastante formal.

O código imperativo refinado serve para implementar planos de granulação grossa - que precisam ser documentados. Eu não quero ter que ler todas as 50 linhas do método quando um comentário rápido de roadmap de 3 linhas serve.

Edição posterior: Um exemplo mais eloqüente é aquele que transcende os computadores. Um livro pode ser muito bem escrito, mas muitas vezes queremos processá-lo em diferentes níveis de abstração. Muitas vezes, um resumo do livro serve, e é isso que os comentários podem oferecer ao código. É claro que o código bem abstraído pode ir muito longe em direção à auto-documentação, mas não pode dar a você todos os níveis de abstração.

E os comentários também podem agir como sidenotes em um livro, quando precisamos explicar o processo de raciocínio por trás de uma reivindicação no texto principal sem descarrilar isso.

Com esse contexto, descubro que minha declaração anterior referente à linguagem natural que transcende a necessidade de comentários está incorreta. Mesmo a linguagem natural, como em um livro, pode se prestar à documentação, explicar de maneira esparsa a abstração incorporada no texto ou fornecer desvios sem descarrilar o texto principal. Com a nota que o código bem abstraído pode já ter percorrido um longo caminho para ser auto-documentado.

Por último, mas não menos importante, os comentários podem ajudar o codificador a manter um alto nível de abstração. Muitas vezes percebo que dois comentários consecutivos que incluí em uma lista de etapas não falam no mesmo nível de abstração, o que imediatamente garante uma análise crítica do que estou fazendo com esse código.

Certos problemas transcendem a codificação e afetam a codificação como outras atividades. Os comentários podem ajudar a esclarecer a razão por trás e as facetas do nosso código, e acho que eles são um companheiro agradável que fala uma linguagem mais suave para beneficiar a pessoa em troca de uma mudança.

Como? Continue mostrando seu código para os desenvolvedores experientes. e quando você é criticado por ser sophomoric e showy, sugá-lo, e perguntar-lhes como fazê-lo e por quê (de uma forma não-confrontacional, claro).

Edite à luz de -1:

Muitas luas atrás, eu estava na mesma situação - eu tinha um chefe que se encolhia toda vez que eu usava um ponteiro em Delphi ou o 'com construção', outro que ameaçava demitir-me se eu não parasse de curto-circuito todos os meus booleanos com 0-1 e usando variáveis de letra única em todos os lugares.

Eu aprendi porque eu perguntei por que e eles se deram ao trabalho de explicar porque achavam que eu poderia ser algo - LOL ....

Eu sinto a necessidade de me exibir? Não, não mais. Como eu consegui passar por isso? Como a maioria das pessoas supera qualquer outro mau hábito ... prática consciente e deliberada de técnicas apropriadas. Você faz isso o suficiente para entender o valor das melhores práticas e, através de seu uso constante, você desenvolverá bons hábitos.

Perceba também que, ao se concentrar no software funcional, que está no prazo e de fácil manutenção, você obterá o reconhecimento que procura. Desenvolvedores experientes virão até você e dirão "Cara, esse módulo que você escreveu foi bem desenhado. Eu só tive que implementar um componente para conectá-lo ao meu projeto." ao contrário de "eu tive que retrabalhar todo o módulo que você escreveu apenas para usá-lo em outro componente? Você já ouviu falar de Bob Martin ou Ward Cunningham?"

TLDR: Você não está sozinho. O reconhecimento da habilidade é melhor alcançado como um subproduto da solução de problemas de maneira inteligente.

Para mim, o código excessivamente inteligente muitas vezes se esforça para resolver os requisitos futuros imaginários, em vez de se concentrar nos requisitos atuais. Grande armadilha!

0% de código complicado não é um objetivo alcançável. Talvez nem seja o melhor objetivo para lutar. Um código muito complicado é ruim, mas você precisa tentar coisas novas para crescer como programador. Você não deve experimentá-los no código de produção se puder evitá-lo. Ao contrário das máquinas, os humanos cometem erros.

Ajuda de comentários de código. Passar anos corrigindo o código "inteligente" de outras pessoas ajuda. Ficar focado no que o cliente realmente precisa hoje ajuda.

Escolas e empresas têm equipes de limpeza e manutenção da equipe. O código também precisa de limpeza e manutenção! Quando possível, limpe as bagunças (especialmente as suas)! Eu acho que é o melhor que se pode fazer.

Além dos bons conselhos dados até agora (revisão de código, depuração, abordagem de TDD), você deve (re) ler periodicamente os (melhores livros) sobre boas práticas de codificação:

• Programador pragmático
• Código concluído
• Limpar código

e outros, dependendo da tecnologia que você usa.

Lembre-se YAGNI - Você não vai precisar .

programmer should not add functionality until deemed necessary...

YAGNI is a principle behind the XP practice of "do the simplest thing that could possibly work" (DTSTTCPW). It is meant to be used in combination with several other practices, such as continuous refactoring, continuous automated unit testing and continuous integration. Used without continuous refactoring, it could lead to messy code and massive rework...

According to those who advocate the YAGNI approach, the temptation to write code that is not necessary at the moment, but might be in the future, has the following disadvantages:

• The time spent is taken from adding, testing or improving the necessary functionality.
• The new features must be debugged, documented, and supported.
• Any new feature imposes constraints on what can be done in the future, so an unnecessary feature may preclude needed features from being added in the future.
• Until the feature is actually needed, it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, it may not work correctly, even if it eventually is needed.
• It leads to code bloat; the software becomes larger and more complicated.
• Unless there are specifications and some kind of revision control, the feature may not be known to programmers who could make use of it.
• Adding the new feature may suggest other new features. If these new features are implemented as well, this may result in a snowball effect towards feature creep...