Como escrever menos código [fechado]

Uma qualidade que eu gostaria de desenvolver é escrever um código mais conciso. Com a escrita mais concisa, pelo menos na minha opinião, a oportunidade de adicionar bugs ao código é menor. É mais fácil ler o código para outros.

Minha pergunta é se é algo que só vem com a experiência ou é algo que você pode fazer explicitamente para desenvolver essa qualidade?

Eu diria que, no geral, é algo que vem com o tempo e a experiência, mas você pode achar que, se você trabalha com linguagens mais concisas, traz essa qualidade de volta às suas línguas de trabalho regulares.

Certamente, depois de um ano ou dois trabalhando com Ruby, descobri que meu C # ficou muito mais tenso. Acho que se eu entendesse melhor a programação funcional (uma ambição em andamento), provavelmente tiraria mais proveito disso.

Além disso, existem algumas diretrizes que podem ajudar, por exemplo, se você escrever as mesmas duas linhas mais de uma vez, dividi-las em seu próprio método. Essa é uma orientação simples, mas reduz rapidamente as linhas de código e a programação de cortar e colar, da qual muitos de nós somos culpados de tempos em tempos.

Se você entende de herança, geralmente pode economizar repetindo o mesmo código em locais diferentes, fornecendo funcionalidade comum às classes pai. Isso é óbvio em princípio, mas algo que as pessoas geralmente sentem falta na prática.

Pode haver uma diferença entre escrever menos código e ter menos código em seu aplicativo. Às vezes, você pode usar a geração de código para evitar repetições, escrevendo apenas algumas linhas de código, mas essas geram muitos outros códigos para você. - isso pode lhe dar muita influência. Veja o que uma ferramenta como Rails ou Entity Framework faz a esse respeito para entender como ela pode ser útil. Seja claro sobre a necessidade disso e pense duas vezes, três e quatro vezes sobre como lançar sua própria geração de código - que pode levá-lo ao inferno YAGNI.

Entenda seu idioma, sua API e suas ferramentas. Novamente, isso parece óbvio, mas ao longo dos anos escrevi tanto código que percebi mais tarde que estava reproduzindo uma funcionalidade que eu poderia ter herdado da API ou usado um recurso de linguagem para simplificar que percebi que algumas horas lendo sobre a documentação da API com a qual estou trabalhando economizará muitas horas de codificação ou depuração posteriormente. Da mesma forma, a maioria das plataformas com as quais você trabalha tem um pouco de conhecimento - aprenda a trabalhar da maneira que eles esperam e sua vida será muito mais fácil. Passe algum tempo encontrando a direção de menor resistência para a plataforma com a qual você está trabalhando e você fará as coisas muito melhor.

Se você está se perguntando se existe uma maneira melhor de fazer algo, provavelmente existe e sempre vale a pena descobrir como fazer as coisas melhor.

Uma ótima maneira de escrever menos código é evitar reinventar a roda e usar componentes de software existentes, quando disponíveis.

Uma resposta comum que recebo quando pergunto por que as pessoas criaram seu próprio ORM, seu próprio mecanismo de registro, seus próprios componentes de interface do usuário ou tudo:

Mas o nosso é melhor

Acredito que esta afirmação esteja correta na maioria dos casos, mas na maioria dos casos o impacto negativo no ROI é muito alto. Sua mãe faz os melhores pratos, certo? Mas você não pode pedir para sua mãe voltar para casa e prepará-los todos os dias.

É por isso que acho que os desenvolvedores devem se interessar pelo impacto financeiro de suas escolhas. Alguns deles são:

• Trabalho extra necessário para construir o componente
• Trabalho extra para iniciantes aprenderem
• Enorme trabalho extra para mantê-lo

Eu gosto de pensar que esses fornecedores de componentes são sua equipe estendida trabalhando para você por uma pequena fração do que você pagaria para criar, manter e melhorar você mesmo.

É melhor para toda a empresa obter o ROI máximo em vez de maximizar a satisfação do ego;) Quanto mais dinheiro sua empresa obtiver, maior será a probabilidade de aumentar suas condições de trabalho e salário.

Na minha opinião, escrever menos código pode ser feito de várias maneiras:

• Você não vai precisar disso . Não codifique algo que você não precisa ainda. Código apenas os requisitos afirmam isso. Dessa forma, reduziremos o código necessário para escrever.

• Não se repita . Acredito que o uso do CMS, da estrutura ou da biblioteca de terceiros seja uma maneira de aplicar o princípio DRY.

• Abstração . E por último, mas não menos importante, a programação de abstração também pode reduzir muito o código. Abstraindo o código, a chance de reutilizá-lo aumentará, pois reduz a duplicidade.

Além da compreensão de uma linguagem de programação, acho que a compreensão de um problema e a criação de uma boa solução têm muito a ver com isso. Existem muitas soluções para a maioria dos problemas, nem todas são ideais. Você pode dirigir da cidade A para a cidade B por estradas diferentes - uma pode levar duas horas e a outra pode levar o dobro. É a mesma ideia na programação. Você pode conhecer um idioma muito bem, mas pode encontrar uma solução que consiga, digamos, duas páginas de código, enquanto outra pessoa descobrirá uma solução que pode ser implementada em um quarto da metade do tamanho do código. Eu já vi isso muito ao longo dos anos.

Certifique-se de ter um bom entendimento do problema. Analise, encontre soluções, pese os prós e os contras (é claro que "soluções com 's'" variarão muito de problema para problema - geralmente falando aqui.) Depois, há a implementação da solução escolhida, que é onde a sua compreensão do idioma (e da estrutura, se aplicável) entra em jogo.

Pode-se dizer que toda a arte da programação se resume a isso.

Você pode estudar linguagens que enfatizam tradicionalmente a clareza e a concisão (por exemplo, Haskell, Scheme, Python) ou até mesmo paradigmas terser como o Factor e outras linguagens concatenativas, mas, no final das contas, tudo o que você poderia escolher para estudar deveria contribuir para ajudá-lo a escrever mais curto , código menos redundante.

Como todas as outras aflições, se você não admitir ter um problema, não procurará uma solução. A experiência começa a ser um fator quando você aprende como menos código se parece. Quando você revisita seu código, é um ótimo momento para determinar se você pode reutilizar o código ou refatorá-lo para menos códigos. A Microsoft conseguiu melhorar a velocidade de impressão com o Windows 2000, NÃO colocando o spool duas vezes (citação de funcionário da Microsoft em uma de suas demos gratuitas).

1. Volte para o seu código longo e antigo,
2. coloque-o sob controle de versão,
3. escreva alguns testes para que tenha uma esperança razoável de não introduzir novos bugs,
4. reescrever.

Repita ad libitum. E bem vindo ao inferno.

O desenvolvimento orientado a testes pode ajudar. Usando isso, você escreve apenas o código mínimo necessário para passar nesse teste.