Estilo de codificação (faça mais, simplifique) [duplicado]

Soa como um bom hábito para mim. A primeira regra na codificação é fazer com que funcione. Depois disso, limpe seu código e torne-o simples, compreensível e mais simples, se possível.

No entanto - se você está gastando muito tempo projetando sua solução e perdendo muito tempo criando coisas que não precisam existir, isso pode ser um mau hábito - como se você estivesse criando um monte de classes e apenas indo um pouco descontroladamente louco. Mas enquanto você está trabalhando para "fazer funcionar", não parece que é um problema.

Minha resposta pode ser um pouco fora do assunto, mas esse método funciona para mim.

Antes mesmo de começar a programar, você tem que pensar: que tipo de estruturas eu preciso para resolver um problema, e que tipo de algoritmos.

Muitas vezes você descobrirá que essa solução já existe e que você só precisa implementá-la no seu projeto *. Nunca tente reinventar uma roda - se você precisar de algo, há sempre uma chance significativa de alguém já ter feito isso melhor.

Uma vez que você faz isso, você só fica com colando essas partes (algoritmos e estruturas) juntas e isso é geralmente mais simples do que pensar em um problema como um todo.

* É por isso que a educação é tão importante em TI. Quanto mais algoritmos e tipos de estruturas você conhecer com mais frequência, durante a programação você vai se pegar pensando: "Ah, eu sei, eu tenho que usar isso . Ah, e aqui eu preciso usar > que . "

Esse hábito é típico do TDD. Primeiro, implemente-o e refatorie. Eu acho que todo desenvolvedor não implementa da melhor maneira em sua primeira tentativa. Contanto que você tenha testes de unidade para verificar se tudo ainda funciona após a refatoração, não há problema com isso.

Eu acho que quando eu faço no papel o que eu quero fazer antes, eu faço menos código desnecessário. Às vezes acabo com vários rascunhos no papel, então ainda é um processo iterativo, mas as iterações tendem a ser mais rápidas, já que você não precisa chegar ao código de trabalho para perceber que algo que você acha que foi uma boa ideia ganhou trabalhe depois de tudo. (Ele nem precisa ser tão detalhado quanto um pseudocódigo; um desenho simples pode ser muito útil. Além disso, não há nada de mágico no papel; os quadros brancos funcionam bem também.)

Limpar o código é um bom hábito, mas o mesmo está voltado para o código limpo. Você ainda precisa limpar as coisas, mesmo se você planejar com antecedência, mas você não terá muita confusão para começar.

Escrever e reescrever o código não é um problema, nem está escrevendo mais código do que é absolutamente necessário. Toda vez que você escreve código e joga fora ou refatora, você está aprendendo - na verdade, é possivelmente a melhor maneira de aprender. Tentar ser "Ótimo" em relação ao tipo de codificação ou ao tempo de digitação é realmente prejudicial a todos os envolvidos.

Além disso, todas essas variáveis "Extra" são geralmente uma boa ideia - se elas o ajudarem a entender seu código inicialmente, é melhor que ele fique lá! Não caia na armadilha de escrever o mínimo de pensamento de código que é o caminho para torná-lo legível, o código Terse não se equivale a legível.

Estou sugerindo que você não fique muito entusiasmado com "Como remover" seu código. Se for absolutamente desnecessário, mas criar funções extras e mais variáveis tende a ser uma coisa boa, se você as remover assim que entender a solução, você só estará prejudicando a todos que olharem o código depois de você (inclusive alguns meses) mais tarde).

Os melhores codificadores e codificadores médios geralmente têm código semelhante, a diferença é quanto tempo leva para fazê-lo. Se você tomar o tempo para planejar com antecedência e resolver o problema antes de começar a codificar, isso o ajudará a se tornar um dos melhores codificadores. Obviamente você não será capaz de prever todos os problemas, então você terá que fazer as coisas pequenas funcionarem e isso pode ficar muito confuso, então o que você está fazendo é chamado de refatoração do código (e esta é uma boa prática). A melhor coisa a fazer é primeiro resolver o algoritmo no papel e descobrir como você vai realizar a tarefa. Em seguida, codifique-o e faça-o funcionar, depois refatore para limpar, tornar mais legível e otimizar. Veja quanto tempo você está levando para resolver / code / debug e, desses três, a depuração deve levar menos tempo, depois codificar um pouco mais e resolver o problema na maior parte do tempo. Espero que ajude.

Nada de errado com este habbit na minha opinião. Quanto mais tempo você codificar, melhores serão as suas habilidades de codificação e resolução de problemas, assim todo o código "extra" terá menos.

Trabalho como engenheiro de software júnior há cerca de dois anos, e ainda uso esse tipo de abordagem, com a diferença de que, com o passar do tempo, tenho ido com mais frequência direto para o aparado. solução / algoritmo.

As variáveis de teste ainda são comuns para mim, mas são usadas com muito mais eficiência.

Portanto, não há preocupações reais aqui, apenas certifique-se de mantê-lo o mais limpo possível e use muitos comentários e regiões.

Apenas tente marcar seu código estranho, se possível. As verificações de variáveis podem ser escritas como asserções , por exemplo, que adicionam informações semânticas ao seu código, ou seja, essas propriedades precisam ser atendidas, etc. Como as asserções geralmente são descartadas no "modo de liberação" (dependendo do idioma / plataforma), muitas asserções não precisam ser removidas, mas podem funcionar como ajuda adicional de depuração ao alterar partes do programa.

Da mesma forma, para variáveis temporárias que você usa para depuração de código, nomeie-as com um prefixo debug_ ou algo semelhante, para que você possa dizer o seu objetivo imediatamente. A programação é um processo iterativo, portanto, o que você faz é perfeitamente normal.

Uma coisa a notar: afirmações podem ser ainda melhores do que comentários para explicar seu código. Use-os (sabiamente)!

A verbosidade é muito comum no programador júnior, mas você está mais adiantado sabendo que essa verbosidade e tenta removê-la.

A princípio, pode soar como um bom hábito que você sempre refatorou, mas se precisar de muita refatoração após a primeira vez, isso significa que você deve melhorar seu desempenho inicial de codificação.

Refatorar mais frequentemente é a chave. Não espere até que sua implementação seja concluída antes de refatorar. Se você funcionar é muito longo, faça uma nova função. Se o seu código é repetitivo, faça uma função dele. Pense em refatorar o tempo todo quando você codifica, não apenas depois de terminar a codificação.

A refatoração constante ajudará você quando precisar revisar o que escreveu e é mais fácil depurá-la. É comum que seu código não funcione corretamente após a primeira vez, e até mesmo você mesmo, alguns dias depois, pode esquecer sua própria lógica se seu código parecer uma bagunça.

Eu acho que ter problemas para "prever o que é necessário" é natural, dada a sua curta experiência: você está apenas começando a aprender a escrever programas. É preciso muita tentativa e erro para aprender a projetar e essa é a habilidade necessária para evitar a codificação externa. Parece que você está no caminho certo.

Talvez você já tenha escrito comentários detalhados, mas se não, você poderia tentar usar comentários como uma ferramenta de design de pequena escala. Tente escrever descrições primeiro. Antes de escrever uma única linha de código em um método, escreva uma descrição para ele: o que ele faz, que parâmetros toma e o que retorna, que efeitos colaterais tem e que tipo de exceções ele pode lançar. Você também pode descrever a implementação usando comentários antes de escrever o código. O mesmo vale para classes ou módulos: tente descrevê-los como um todo antes de mergulhar em detalhes e implementação.

Essa abordagem força você a criar algo antes de codificar. Também poderia levar você a pensar sobre a estrutura em primeiro lugar, que será essencial no futuro.

A sequência usual é "corrigir, depois torná-la elegante e torná-la eficiente". O primeiro passo pode resultar em um código tão longo quanto você precisar, contanto que você possa acompanhar o que está acontecendo.

A refinação gradual de código é um processo contínuo, e até mesmo os melhores programadores são conhecidos por dizer que alguns de seus os dias mais produtivos foram quando eles removeram 1000 linhas de código . Você deve se preocupar quando não puder simplificar seu código grande e complexo, e não o contrário.

A abordagem "Faça mais e simplifique" tem uma grande desvantagem: os métodos grandes e complexos são muito difíceis de testar. E você quer um teste que documente que seu código refatorado produza os mesmos resultados.

É difícil fazer isso no começo (ainda é para mim um monte de folgas), mas à medida que você ganha experiência, você lentamente aprenderá a identificar padrões no código e saberá como dividir esses padrões em simples e estruturas testáveis.