Como treinar-se para evitar escrever código "inteligente"? [fechadas]

Você conhece esse sentimento quando só precisa mostrar esse novo truque com Expressions ou generalizar três procedimentos diferentes? Isso não precisa estar na escala do Architecture Astronaut e, de fato, pode ser útil, mas não posso deixar de notar que outra pessoa implementaria a mesma classe ou pacote de uma maneira mais clara, direta (e às vezes chata).

Percebi que costumo criar programas solucionando o problema , algumas vezes deliberadamente e outras por tédio. Em ambos os casos, geralmente acredito honestamente que minha solução é clara e elegante, até que eu veja evidências em contrário, mas geralmente é tarde demais. Há também uma parte de mim que prefere suposições não documentadas à duplicação de código e inteligência à simplicidade.

O que posso fazer para resistir ao desejo de escrever um código “inteligente” e quando a campainha deve tocar dizendo que estou fazendo errado ?

O problema está aumentando ainda mais, pois agora estou trabalhando com uma equipe de desenvolvedores experientes e, às vezes, minhas tentativas de escrever código inteligente parecem tolas até para mim mesmo depois que o tempo dissipa a ilusão de elegância.

O problema está aumentando ainda mais, pois agora estou trabalhando com uma equipe de desenvolvedores experientes e, às vezes, minhas tentativas de escrever código inteligente parecem tolas até para mim mesmo depois que o tempo dissipa a ilusão de elegância.

Sua solução está aqui. Presumo que "experiente" neste contexto signifique "mais experiente que você". No mínimo, você os respeita claramente. Esta é uma oportunidade valiosa de aprendizado - supondo que seu ego possa sofrer. (Coisas irritantes, egos. Pena que precisamos deles.)

Você tem análises de código com essas pessoas? Nesse caso, se eles ainda não o estão fazendo, peça-lhes explicitamente que o chamem de besteira. Mencione que você notou uma tendência em projetar demais, usar uma britadeira pneumática de ponta meticulosamente projetada (de preferência empunhada por algum tipo de andróide de trabalhador de estrada automatizado) quando um simples martelo de garra seria mais que suficiente .

Você pode frequentemente se contorcer no seu lugar enquanto seu rosto fica vermelho durante as revisões de código. Suportar isso. Você está aprendendo.

Então, depois de ter algumas dessas informações, preste atenção nos momentos em que você suspeita que esteja possivelmente projetando demais. Quando esses momentos chegarem, pergunte-se: "Se alguém me chamar sobre isso durante a revisão de 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 dar uma boa olhada no seu próprio trabalho.

A melhor coisa a fazer é ter em mente a máxima de 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. ”

Geralmente, existem pelo menos três soluções para problemas de software de qualquer significado: 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:

Coloque tudo o que lhe vier à cabeça e então você é um escritor. Mas um autor é aquele que pode julgar o valor de suas próprias coisas, sem piedade, e destruir a maior parte delas. - Colette

Você não poderá escrever um código elegante até poder julgar o valor do seu próprio código, sem piedade, e destruir a maior parte. Se você julga um código elegante pelo resultado final, parece enganosamente fácil, mas exige lentidão, passando por vários rascunhos, buscando o conselho de outras pessoas e excluindo o que não aparece na página. Isso significa que, mesmo que seu código esteja funcionando perfeitamente, você se pergunta 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ê sinta que o compilador deveria ter sido capaz de detectar um certo tipo de bug. A maioria dos programadores com um pouco de experiência pode reconhecer códigos deselegantes facilmente. O truque é descobrir o porquê .

Essa é a maneira metódica de escrever código mais elegante. Também frequentemente requer um flash de insight que ajuda a analisar um problema de uma nova maneira. Isso é mais difícil de obter, mas ajuda a diminuir a velocidade e 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. Ter aulas ou ler livros sobre práticas recomendadas ajuda. Aprender outros paradigmas de programação ajuda. Pedir conselhos de colegas cujo código você admira ajuda.

Eu acrescentaria às respostas existentes, desenvolveria de maneira TDD, para que você primeiro escreva testes sobre o que seu código deve fazer e depois implemente para tornar seus testes ecológicos. Dessa forma, você estará cumprindo apenas 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 "embotado" até o nível mais baixo do membro da equipe mais conservador ou com deficiência intelectual, atual ou histórica.

Isso pode não ser necessariamente uma coisa ruim, porque o código inteligente pode ser mais difícil de depurar, mais difícil de transmitir em uma especificação técnica e levar mais tempo para escrever, diminuindo o tempo de desenvolvimento.

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

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

Lamento 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".

O que quero dizer é que o código "inteligente" DEVE suspeitar, mas não devemos fazer uma cruzada contra ele, pois pode sufocar a criatividade e a inovação.

EDIT: Acabei de perceber que não respondi completamente à sua pergunta. Se você tem capacidade no seu projeto para escrever com muita facilidade códigos inteligentes, talvez a equipe deva adotar padrões de codificação mais rígidos para seguir um modelo e estilo uniforme e distinto. Isso ajudará a traçar as linhas da sua caixa de areia, para que você não entre na rua correndo atrás de uma bola.

Se 20% (o seu% pode variar) ou mais 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 eficiente. Dar a si mesmo uma orientação geral como% de comentários necessários para deixar claro é uma boa maneira de se forçar a se afastar e avaliar se o uso dessa coisa nova que você aprendeu é uma escolha sábia ou apenas uma maneira de mostrar seu novo brinquedo.

Não resisto a tentar algo inteligente.

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

Quando a novidade desaparece - problema resolvido.

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

Se eu desse uma impressão deste código a alguém que nunca trabalhou nesse projeto / código, eles poderiam lê-lo e descrever de volta para mim o que a função faz (depois de fornecer a eles um breve contexto)? Se não, quanta explicação eu teria que fazer? Como eu explicaria isso para alguém que toma o CS101?

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

1) Se queime antes, para que você saiba que é uma coisa ruim. Tentar depurar algo de muito tempo atrás que seja escrito de maneira inteligente é muito divertido. 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ê se esforçar para explicá-lo ou sentir a necessidade de inserir um diagrama, o que você acabou de fazer é muito inteligente e provavelmente poderia ser feito de maneira mais limpa.

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

Normalmente, uso comentários para descrever o que estou fazendo com uma seção de código. Se parecer menos confuso, 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, é um sinal claro de que preciso dar um passo atrás e tentar novamente.

Provavelmente, uma boa maneira de começar a escrever código simples é liberar a paixão pela esperteza 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 código aberto para trabalhar, nas quais basta pedir Expressionconhecimento de truques, há F # e uma maravilhosa variedade de tarefas pelas quais alguém pode querer tentar.

Se você gosta de matemática (e isso é independente da linguagem ), existe o Projeto Euler para você.

Por último, mas não menos importante, no mundo .NET existe o Mono Project que tem muitas áreas que precisam de atenção do desenvolvedor , algumas delas bastante complicadas. Que tal contribuir para uma ferramenta de análise de código .NET estática de código aberto ? Há algumas análises de IL envolvidas, bem como coisas de alto nível. Jb Evain sempre trabalha em algo interessante, seja a biblioteca de reflexão Cecil, Expressionsuporte ou um descompilador .NET.

Se nada se encaixar, basta iniciar sua própria estrutura de zombaria :-)

Você conhece esse sentimento quando só precisa mostrar esse novo truque com Expressões ou generalizar três procedimentos diferentes?

Não

Essa é uma das razões pelas quais eu sempre digo que é bom quando novos desenvolvedores são lançados em uma grande e velha bagunça de código speghetti não documentado para manter e refatorar. Isso ensinará a eles a realidade de manter código excessivamente 'inteligente' que eles não escreveram e, esperançosamente, instilará alguma empatia pelo pobre idiota que terá que depurar seu código daqui a cinco anos.

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

Em uma nota diferente, inteligente ou não, o código deve ser documentado. Existe uma incompatibilidade inerente de impedância entre as linguagens de programação aceitas pelo setor e os conceitos de alto nível que nós, como seres humanos, estamos acostumados em nosso pensamento. O código de auto-documentação simplesmente não é realizável - até que se torne uma linguagem natural. Mesmo o código Prolog precisa ser documentado, pois, por mais alto nível que seja, ele ainda é bastante formal.

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

Edição posterior: Um exemplo mais eloquente é aquele que transcende os computadores. Um livro pode ser muito bem escrito, mas geralmente queremos processá-lo em diferentes níveis de abstração. Muitas vezes, um resumo do livro é suficiente, e é isso que os comentários podem oferecer ao código. É claro que o código bem abstraído pode percorrer um longo caminho para a auto-documentação, mas não pode fornecer todos os níveis de abstração.

E os comentários também podem agir como notas de rodapé de um livro, quando precisamos explicar o processo de raciocínio por trás de uma reivindicação no texto principal sem descarrilá-la.

Nesse contexto, acho 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 a documentação, explicar de maneira esparsa a abstração incorporada no texto ou fornecer desvios sem atrapalhar o texto principal. Com a observação de que um código bem abstraído já pode ter sido um longo caminho para se auto-documentar.

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 incluídos em uma lista de etapas não falam no mesmo nível de abstração, o que justifica imediatamente 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 fornecer essa ajuda para esclarecer a lógica por trás e as facetas do nosso código, e eu os acho um companheiro agradável que fala um idioma mais suave para beneficiar a pessoa por uma mudança.

Quão? Continue mostrando seu código para os desenvolvedores experientes. e quando você se sentir culpado por ser sophomoric e vistoso, sugá-lo e perguntar-lhes como eles fariam isso e por quê (de uma maneira sem confronto, é claro).

Editar à luz de -1:

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

Eu aprendi porque perguntei o porquê e eles se deram ao trabalho de explicar porque achavam que eu poderia significar algo - LOL ....

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

Perceba também que, concentrando-se no software funcional, pontual e facilmente mantido, você obterá o reconhecimento que procura. Desenvolvedores experientes entrarão em contato com você e dirão "Cara, o módulo que você escreveu foi bem projetado. Eu só precisei implementar um componente para conectá-lo ao meu projeto". ao contrário de "Eu tive que refazer todo o módulo que você escreveu 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 subproduto da solução de problemas da maneira inteligente.

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

0% de código excessivamente complicado não é uma meta alcançável. Talvez nem seja o melhor objetivo pelo qual lutar. 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.

Revisões de código ajudam. Passar anos consertando o código "inteligente" de outras pessoas ajuda. Manter o foco no que o cliente realmente precisa hoje ajuda.

Escolas e empresas contam com equipes de pessoal de limpeza e manutenção. O código também precisa de limpeza e manutenção! Sempre que possível, limpe a bagunça (especialmente a sua)! 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 TDD), você deve (re) ler periodicamente os (melhores livros imho) sobre boas práticas de codificação:

• Programador pragmático
• Código completo
• Código Limpo

e outros, dependendo da tecnologia que você usa.

Apenas lembre-se de YAGNI - Você não precisará disso .

O programador não deve adicionar funcionalidades até que seja considerado necessário ...

YAGNI é um princípio por trás da prática XP de "fazer a coisa mais simples que poderia funcionar" (DTSTTCPW). Ele deve ser usado em combinação com várias outras práticas, como refatoração contínua, teste de unidade automatizado contínuo e integração contínua. Usado sem refatoração contínua, pode levar a códigos confusos e retrabalho maciço ...

De acordo com aqueles que defendem a abordagem do YAGNI, a tentação de escrever código que não é necessário no momento, mas pode ser no futuro, tem as seguintes desvantagens:

• O tempo gasto é gasto na adição, teste ou aprimoramento da funcionalidade necessária.
• Os novos recursos devem ser depurados, documentados e suportados.
• Qualquer novo recurso impõe restrições sobre o que pode ser feito no futuro; portanto, um recurso desnecessário pode impedir que os recursos necessários sejam adicionados no futuro.
• Até que o recurso seja realmente necessário, é difícil definir completamente o que ele deve fazer e testá-lo. Se o novo recurso não for definido e testado corretamente, ele pode não funcionar corretamente, mesmo que eventualmente seja necessário.
• Isso leva ao inchaço do código; o software se torna maior e mais complicado.
• A menos que haja especificações e algum tipo de controle de revisão, o recurso pode não ser conhecido pelos programadores que poderiam fazer uso dele.
• Adicionar o novo recurso pode sugerir outros novos recursos. Se esses novos recursos também forem implementados, isso poderá resultar em um efeito bola de neve no sentido da fluência ...