Bom eu tento ao maximo pensar em detalhes e coisas que seriam necessarias para o codigo, procuro por boas práticas e etc mas mesmo assim sempre vejo aquele codigo depois e fico decepcionado como pude escrever algo tão ruim, e isso vem me deixando meio frustrado com meu desempenho. Pessoal mais experiente como vcs lidam com isso? Tem algum jeito de notar que o código está ruim de maneira rapida?
Isso é comum, ainda mais quando não se tem muito tempo.
Depende do conhecimento que você tiver, ao escrever o código você já vai notar que tem coisas ficando complexas de se ler.
Acho que algo legal de se fazer é pegar partes mais complexas de algo que você fez e mostrar pra alguém que nunca leu o código, pra você entender como essa pessoa tentou interpretar.
Ruim de que forma?
Fica complicado de ler ou ele apresenta erros quando executado ?
Constumo passar por isso por conta da pressa que a empresa tem pro projeto ficar pronto. Quando isso acontece, costumo voltar no código quando tenho um tempo livre e revisá-lo pra tentar melhorar. Realmente dá uma decepção em ler aquele código feio, mas depois que vc passa por ele novamente com um tempo e cabeça fresca pra melhorar, dá um alívio.
Não sei se isso que eu faço é uma boa prática, mas é o que me sobra atualmente.
Ruim como? Código ilegível, com erros, falta performance, mal otimizado ou um pouco de tudo?
Sei que é óbvio, mas dependendo do que for da pra melhor o que for mais urgente. Legibilidade é muito importante e uma coisa puxa a outra, mas não apresentar erros é fundamental, ter performance minima também é muito importante.
Mal organizado, mas eu diria um pouco de tudo tambem
Não sei bem qual stack vc usa, mas de modo geral, o que me ajuda muito é fazer um levantamento de requisitos sério primeiro e então seguir para uma file tree (no caderno, bloco de notas, voice note, mind map ou onde der pra anotar), descrevendo +/- as funcionalidades e regras de negócio. A partir dai a gente tem uma estrutura mais clara pra começar. Arquivo x será para coisa y, diretório A será para arquivos B, etc.
Já dentro de cada arquivo, uma coisa que sempre faço é separar funções e grupos de funções com comentários sucintos, mas descritivos.
Sei que são dicas bem óbvias, mas é eficiente.