O que devo fazer quando meu código cheira?

Sou um programador iniciante e, muitas vezes, quando estou trabalhando em meus próprios projetos, sempre sinto que o design do meu código não é o melhor que poderia ser, e odeio esse sentimento. Acabo gastando tempo pesquisando as coisas, mas então fico sobrecarregado com muitos detalhes, como padrões de design para escolher e quando usar uma classe abstrata ou uma interface. Devo tentar aprender um pouco de tudo de uma vez?

Algumas sugestões:

1. Use o encapsulamento para gerenciar a complexidade, separando a funcionalidade em blocos de construção distintos. Prove que cada bloco funciona (através de testes de unidade) e você pode usá-lo sem se preocupar com seus detalhes internos.

2. Aprenda e estude padrões de software . Os padrões de software são métodos testados e comprovados para executar determinadas tarefas comuns e conhecidas.

3. Estudar e entender estruturas de dados. Aprenda os usos e características de desempenho apropriados para cada tipo de estrutura de dados.

4. Conheça bem sua linguagem de programação, seus pontos fortes e fracos e como melhor usar seus recursos.

Você não precisa saber tudo de uma vez, mas deve estudar tudo ao longo do tempo.

Meu conselho é: pare de se preocupar.

A experiência é o melhor professor e você não obtém experiência se não escrever código. Além disso, o código mal projetado que é escrito é melhor do que o excelente design que não é .

Então, escreva mais código. Termine seus projetos. Essa sensação de que o código não é ideal provavelmente está certa. E você provavelmente terá problemas com este código. E quando você tem esses problemas, então você aprender por que exatamente era ruim. Você aprenderia muito mais com a experiência em primeira mão do que com "procurar coisas".

Além disso, não espere que esse sentimento de "cheiro de código" desapareça. Conforme você está melhorando, você solucionará alguns problemas, mas começará a perceber problemas novos, mais obscuros / avançados.

Este é um problema comum com programadores iniciantes. Não se paralise pensando que tudo tem que ser perfeito. Essa é a maneira mais segura de nunca terminar um projeto. Uma das habilidades mais importantes para aprender como desenvolvedor é a diferença entre perfeita e boa o suficiente . Aceite que todo sistema que você criar possa ser aprimorado. Concentre-se em terminar seus projetos. Depois de terminar, você pode voltar e aprimorá-los. É por isso que temos a versão 2.0, afinal.

Devo tentar aprender um pouco de tudo de uma vez?

Espero que não. Por outro lado, você deve aprender e melhorar o tempo todo.

Leia livros, faça cursos, se qualifique, trabalhe e você deve melhorar.

Meu melhor conselho é focar nos fundamentos, como a lista que Robert Harvey sugeriu. O desenvolvimento de software é um monstro complexo que leva anos para se tornar remotamente bom, especialmente no tópico de bom design de interface. É realmente difícil apreciar muitos aspectos do desenvolvimento de software sem antes experimentá-los. Mesmo algo tão básico quanto comentar código pode ser subestimado. Desde o primeiro dia, você é ensinado a escrever um código bem documentado. Admito que não foi até que eu realmente estava tentando entender o código que escrevi meses atrás, antes de realmente apreciar o valor de bons comentários. O mesmo pode ser dito para muitos conceitos de programação. Por exemplo, encapsulamento de dados, módulos com baixo acoplamento e interfaces limpas.

O recurso mais valioso que encontro são meus colegas de trabalho. Você está indo para escrever código incorreto. Apenas aceite isso. É o que você faz para garantir que você escreva melhor o código ao longo do tempo que o define como programador. Por exemplo, quando comecei a trabalhar, minha empresa não tinha nenhum tipo de código formal ou procedimentos de revisão de design. Decidi submeter meu trabalho às críticas de meus colegas mais antigos e, para ser sincero, me senti um idiota por boa parte do meu primeiro ano de trabalho.

O desenvolvimento de software é uma experiência de aprendizado contínuo. Faça muitas perguntas, revise seu código, entenda o porquê das sugestões que os seniores dão, não tenha medo de questionar a validade das sugestões que os desenvolvedores seniores dão e, acima de tudo, não tenha medo de estar errado. Eventualmente, o fator de intimação ou a sensação de ser modismos oprimidos. Para o registro ... as curvas de aprendizado são péssimas.

• Primeiro: refatoração (ainda cheira, mas será um pouco mais organizado)
• Segundo: Veja se você pode usar algum Design Patter para fazer com que as peças refatoradas correspondam à sua lógica.
• Terceiro: quando as coisas começarem a parecer melhores, lembre-se do tempo que você passou executando o primeiro e o segundo passo. Dessa forma, quando você escrever um novo recurso, você pensará nisso enquanto o faz e não como outro processo.

Dê uma olhada no livro Refatoração: Melhorando o design do código existente , de Martin Fowler. A primeira coisa que você deve fazer é refatorar seu código , a fim de melhorar a legibilidade do código e reduzir a complexidade para melhorar sua manutenção.

Ao refatorar seu código, você já está usando Design Patterns , Encapsulating code , etc.

Este é um dos melhores livros que eu já li sobre esse tópico. Ele fornece muitas receitas úteis.

Um bom recurso é o programador pragmático . O capítulo "Windows quebrado" descreve onde você se vê. A resposta curta e concisa é corrigir os problemas.

Quando você começa a consertar seu design, ajuda a entender o que você não gosta. É fácil chegar a respostas vagas, como "isso acontece em todo lugar" ou "por que eu fiz isso lá?". Mas reserve um tempo para verificar se existem padrões comuns que você usou.

• Um bom design reutilizará um pequeno número de conceitos em toda a base de código (o ideal é um conceito, mas na prática você pode precisar de mais alguns)
• Um bom design tornará mais fácil descobrir onde corrigir problemas (princípio DRY, princípio SRP)
• Um bom design terá um bom relatório de erros (relacionado ao ponto acima, mas chamado como um item separado, pois é um aspecto frequentemente negligenciado)

Depois de descobrir onde você quer ir, siga etapas pequenas e facilmente reversíveis para chegar lá (ou seja, é disso que trata a refatoração ). Toda vez que você melhorar seu código, considere o impacto no restante do código. Você melhorou ou piorou as coisas? Essa pelo menos é a minha abordagem para trazer ordem ao caos.

Se você já tem alguma experiência em programação, por que não estuda alguns projetos de código aberto que possuem código limpo ? Você pode olhar para ESTA pergunta da SO, que possui alguns links relevantes.

Além disso, os padrões de design são um conhecimento obrigatório - pense bem, a idéia de ter padrões é resolver problemas conhecidos sem reinventar a roda ou escrever código de buggy.

Finalmente, parece que você precisa de uma dose de programação funcional para limpar sua cabeça. Olhe Haskell ou Ocaml para começar.

Se você não é um monstro perigoso, deve encontrar um amigo chamado , que pode revisar seu código e vice-versa. Além disso, se você criar coisas que serão revisitadas ou supervisionadas por outras pessoas, é uma boa pressão fazê-lo da melhor maneira.

E não se esqueça, a programação começa antes da codificação, sempre revise suas idéias, planos. Se seu plano é ruim, é um ato de alegria jogá-lo fora: você acabou de salvar a frustração de jogar fora um monte de código (e o tempo de sua criação) com base em um plano ruim.

Meu conselho é levar cada um dos cheiros a sério e tentar consertá-lo. Existem muitos bons livros sobre o assunto (código limpo e GOOS são os melhores IMHO). Porém, mais do que livros, vão a conferências para ouvir e discutir com outras pessoas e em comunidades online (lista de discussão, grupos). Ainda melhor, tente ingressar no seu xxug local (dotnetug, jarro, xpug, etc.) ou encontrado um.

Discutir com outros programadores é a única maneira que realmente sei melhorar (a menos que você tenha a sorte de trabalhar em conjunto com outros programadores dedicados).