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

43

Eu sou um estudante de Comunicação Social e tenho codificado há alguns meses há um ano, e parece que desenvolvi o que acho que pode ser um hábito "ruim" e estou imaginando se alguém faz o mesmo. (ou se é um mau hábito). Quando estou codificando / resolvendo um problema com código, descubro que minha implementação inicial é demorada e excessivamente complicada; em outras palavras, há muito código estranho (variáveis, verificações) que simplesmente não é necessário. Quando termino o "rascunho" inicial e certifico-me de que o código realmente funciona, simplifico e facilito o entendimento / menos verbosidade.

Acho que a razão pela qual faço isso é que tenho dificuldade em prever o que precisarei para concluir uma tarefa e acabo compensando e criando complexidades que não devem ou não precisam existir. Alguém tem alguma dica ou conselho sobre como melhorar essa faceta do meu estilo de codificação, ou qualquer informação sobre se o hábito é realmente ruim?

    
por George Greg 28.04.2013 / 19:14
fonte

12 respostas

47

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.

    
por 28.04.2013 / 19:23
fonte
20

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

    
por 28.04.2013 / 20:27
fonte
10

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.

    
por 28.04.2013 / 19:16
fonte
7

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.

    
por 28.04.2013 / 20:43
fonte
4

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).

É, no entanto, importante manter seu código DRY, na verdade é o que eu considero o princípio mais importante em todo o desenvolvimento de software, mas uma vez que seu código é DRY, reduzindo ainda mais a verbosidade do que o ajudou a compreendê-lo e projetá-lo é geralmente prejudicial.

    
por 29.04.2013 / 08:41
fonte
3

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.

    
por 29.04.2013 / 05:24
fonte
3

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.

    
por 29.04.2013 / 08:28
fonte
2

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)!

    
por 28.04.2013 / 20:10
fonte
2

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.

    
por 29.04.2013 / 07:45
fonte
1

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.

    
por 29.04.2013 / 16:28
fonte
0

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.

    
por 29.04.2013 / 18:13
fonte
0

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.

Então você realmente precisa começar a pensar sobre a separação de preocupações o mais cedo possível, ou então você passará muito tempo lutando com testes de unidade realmente difíceis, que poderiam ser evitados. Você precisa de pequenos pedaços de código desde o início. Para mim, compreender o "Princípio da Responsabilidade Única" (SRP) foi muito importante neste contexto. Além disso, a injeção de decência desempenha um papel muito importante aqui.

É 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.

    
por 01.05.2013 / 00:20
fonte