É melhor fazer fazer o código fucionar e dopois refatorar ou já criar o melhor codigo desde o começo

Eu trabalho com desenvolvimento web / arquitetura fullstack a 1 ano e meio e acho que posso dizer algo sobre o assunto:

Pra tudo existe hora e lugar e não existe bala de prata pra nada, contudo, voce vai querer morrer quando for refatorar um código mal feito.

O levantamento de regras de negócio e planejamento de um projeto é IMPORTANTÍSSIMO para que você não tenha trabalho em dobro.

Por isso, na minha opinião, o sistema deve ser bem feito desde o começo, mesmo com pressa, para que você não deixe pontas soltas na sua lógica. Economizar tempo hoje para ter mais trabalho amanhã não faz sentido. Você só vai piorar a sua vida.

Pensando num ambiente profissional, sempre imagino que a melhor forma de entregar valor e ter uma qualidade aceitável o mais rápido possível é seguir três passos:

• Fazer funcionar;
• Fazer certo;
• Fazer rápido;

Com isso, teríamos uma entrega o mais rápido possível para o cliente, caso necessário. Logo em seguida iríamos deixar o código sem as famosas gambiarras e por fim tentar aprimorar a performance do código (sempre atentando para verificar se realmente é necessário melhorar a performance ou apenas um tempo perdido atoa).

Outra questão que costumo observar é em relação a código copiado em vários lugares, acho que copiar uma vez o código (ao invés de abstrair) é interessante na primeira vez, mas a partir da segunda cópia (ter o mesmo código em três lugares) seria melhor pensar em uma forma de manter apenas um.

Isso é apenas um pouco da experiência que tive, não sei se há algum padrão melhor a ser seguido ou algo assim.

Pessoa! Pra responder sua pergunta, eu vou traduzir um texto escrito pelo Donald Knuth em 1974:

Não há dúvidas que o Graal da eficiência leva ao abuso. Programadores desperdiçam uma enorme quantidade de tempo pensando sobre, ou se precocupando com, a velocidade de partes não-críticas de seus programas, e estas tentaticas de eficiência têm um forte impacto quando debug e manutenção são considerados. Nós devemos esquecer sobre pequenas eficiências, diga 97% das vezes: otimização prematura é a raiz de todo o mal.
No entanto, não devemos negligenciar nossas oportunidades nos críticos 3 %. Um bom programador não deve ser embalado em complacência por tal racioncínio, ele deve olhar cuidadosamente o código crítico; mas apenas depois de identificá-lo.

Esse princípio também é descrito pelo modelo da curva ABC, que também enumera as contribuições de cada parte de um sistema para priorizar qual deve ser otimizada. Uma melhora de 30 % em uma parte que toma 70 % do seu processo é melhor do que uma melhora de 90 % em uma parte que toma 20 % (o primeiro caso reduz 21 % dos seus custos, o que já é mais do que a parte inteira do segundo).

Agora, repita três vezes:

Otimização prematura é a raiz de todo o mal.
Otimização prematura é a raiz de todo o mal.
Otimização prematura é a raiz de todo o mal.

Depende:
Código para projetos pessoais?

Pode ser qualquer coisa. Tem um empreendedor que o site dele mais acessado
era só um unico arquivo PHP. E o site recebia praticamente milhões de visitas por mês!
Ele fazia, funcionava, ele colocava no ar e via o que dava.
Uns deram certo, pegaram tração outros não!
Na lógica dele, feito sempre era melhor que perfeito.
Assim ele não perdia tempo com projeto que no final nunca ia vingar.
Depois do projeto rodando, pegando tração ele ia arrumando aos poucos!

O ebay rodava num só aquivo C++ com uma única classe!
https://twitter.com/alex_aquiles/status/1628061748652568576

Código no seu trabalho remunerado?

Prefiro fazer código melhores, não perfeitos.
Códigos bons o suficiente, se tiver revisão de código vão te ajudar a melhorar!

Ao longo do tempo você vai desenvolver seu próprio critério para isso e saberá quando é o melhor momento para aplicar determinado contexto.

As demandas de problemas já conhecidos são chances de pegar o que já funciona e tentar fazer da melhor forma possível. Caso seja algo novo, irá focar na funcionalidade para depois gastar tempo em cosméticos. É mais ou menos essa linha que venho seguindo. Para mim não adianta perder tempo deixando algo bonito se não tenho confiança de que tá funcionando.

Sobre deixar o código "melhor"; ou "bonito"; ou "manutenível". Você poderá sempre recorrer aos patriacas da refatoração e boas práticas como o Martin Fowler ou Robert Martin, mas ainda vai ter que passar pelo seu próprio crivo, ou até de um revisor, do que é o melhor código para determinada base de código. Se estiver trabalhando em código legado ainda terá o crivo da confiabilidade de não ter adicionado um bug ao código.

Uma dica é sempre que possível criar seus códigos já pensando em testes unitários. Isso tornará o código mais acessível do ponto de vista da utilização e gerenciamento de estado. E esses detalhes farão a manutenção ficar muito mais agradável.

Tem que cuidar com os dois extremos, nem código ruim demais nem over engineering.

Acredito que desde dia 0 tem de ser escrito um código extensível, não necessariamente você deva prever todas as features possíveis, mas sim seguir bons princípios para que possa ser incrementado quando necessário.

Acredito que depende de diversos fatores, é importante alinhar as expectativas com os stakeholders para entender melhor qual o caminho a seguir, por muitas vezes eu fiz uma ferrari quando os meus lideres só queriam algo que meramente rodasse...

Eu pessoalmente prefiro fazer algo elaborado e completo pelo desafio mesmo, mas é importante ponderar com eles para que você sempre ponha o valor correto onde a empresa precise que você ponha.

Melhor feito do que bem feito.

Faça funcionar, nem que seja da forma mais "burra" o possível, depois você refatora.

Óbvio que se você tem a solução "perfeita" na cabeça, faça logo.

Esse princípio se aplica para evitar que você perca horas e horas fazendo uma funcionalidade simplesmente pelo desejo de fazer perfeito.

Olha eu levo muito a sério o contexto de DRY, KISS e YAGNI para todos os códigos que eu faço, normalmente as vezes eu faço ele o mais simples possivel para entender todo o fluxo e processo, após isso implemento tecnicas, conceitos entre outras regrinhas... Mas sempre envio para Code Review com ele já pronto funcionando e com melhor código possivel naquele momento.

Mas como a maioria disse, você precisa sempre ponderar ambas as partes, mandar o código meia boca pensando em refatorar depois não é bom.. porém ficar preso tentando fazer um código de foguete (over engineering) também não é bom... então sempre pondere os dois lados.

Deixo o link do artigo do "Vinícius Oliveira" sobre os 3 principios que citei acima.
https://vinioolvrs.medium.com/conhe%C3%A7a-os-princ%C3%ADpios-dry-kiss-e-yagni-9fc4ab46b0b9

Depende.
Se for um projeto pequeno, simples, as vezes só de funcionar já tá ótimo. Complicar demais querendo fazer um código bonito pode atrasar seu projeto a troco de nada.

Se é uma emergência, primeiro tu resolve, depois tu "embeleza" o código.

Se você tá criando algo do zero mas já sabe que esse projeto vai crescer com o tempo, já é interessante você ir construindo utilizando as boas práticas, pra não ficar muito bagunçado depois. As vezes o código funciona, mas basta aumentar um pouquinho as requisições e ele quebra.

No mais, é praticamente impossível escapar da refatoração. Digamos que não existe "código perfeito", e você precisa mante-lo atualizado. Então, geralmente, primeiro a gente foca em fazer funcionar, depois em otimizar.