Maneiras de quebrar a "Síndrome do programador perfeito" [fechado]

Provavelmente não sou o único que se sente assim. Mas tenho o que costumo chamar "A síndrome do programador perfeito", que muitos podem dizer que é o mesmo que ser perfeccionista, mas, neste caso, está no domínio da programação. No entanto, o domínio da programação é um pouco problemático para essa síndrome.

Você já sentiu que, ao programar, não está confiante ou confiante o suficiente para que seu código seja limpo e bom código que siga a maioria das melhores práticas? Existem tantas regras a seguir que eu sinto como se estivesse sobrecarregada de alguma forma. Não que eu não goste de seguir as regras, é claro que sou programador e adoro programar, vejo isso como uma arte e devo seguir as regras. Mas eu também adoro, quero dizer, quero e adoro seguir as regras para ter uma boa noção do que estou fazendo no caminho certo .. mas eu só gostaria de poder ter tudo um pouco mais em "controle" em relação a boas práticas e bom código.

Talvez seja uma falta de organização? Talvez seja uma falta de experiência? Talvez falta de prática? Talvez seja a falta de algo mais que alguém possa apontar? Existe alguma maneira de se livrar dessa síndrome de alguma forma?

Priorize . Primeiras coisas primeiro. Concentre-se no que importa.

Suas prioridades podem variar, mas em geral você deve se preocupar com:

• Código correto
• Código de manutenção
• Código limpo
• Código simples e elegante
• Código eficiente

Talvez nessa ordem. No entanto, o primeiro ponto é o mais importante. Sem ele, o código é inútil. O que você faz com um programa que não funciona corretamente?

Faça funcionar, tudo o resto é quase irrelevante para resolver os problemas que você precisa resolver. Claro, eu também sofro disso. O que aprendi que ajuda é apenas focar em soluções que funcionam . É suficiente. Isso é 99% do trabalho.

Você pode pensar em algo como um bom código . O que é isso? Que tipo de pessoas escrevem? Como escrever um bom código ? É muito simples. Escreva um código que funcione . Código de trabalho é um bom código. Tudo o resto vem depois.

Obviamente, ao escrever código em ambiente profissional, de equipe , código óbvio, legível e código de manutenção se tornam cada vez mais importantes. No entanto, ainda a primeira tarefa é fazê-lo funcionar e se concentrar nisso. Somente então você pode começar a refinar e refatorar para melhor - se necessário.

Muitas vezes, é bastante óbvio que a correção do código é muito importante - ainda assim, todos falhamos em entender sua importância ao escrever o código. Cortamos cantos, usamos otimização prematura, tentamos escrever um código elegante antes mesmo de escrevermos um código de trabalho . É da natureza humana buscar a perfeição desde o início, mas a programação e o desenvolvimento de software são processos iterativos e existem prioridades. Assim, novamente, faça com que funcione , se preocupe com tudo mais tarde. Entenda a importância do código correto e lute por ele.

Embora existam toneladas e toneladas de chamadas boas práticas , acho que o senso comum é o mais importante, pense por que as práticas são consideradas boas, quando e onde aplicá-las. Não se esforce para cumprir todas as boas práticas. Não há substituto ou substituto para a experiência pessoal. Você não pode evitar armadilhas comuns - não importa quantos livros você leia, seminários que assista ou outros enfeites. O que importa é aprender fazendo, fazendo as coisas corretamente e se divertindo - sempre que possível.

A maneira mais simples de evitar esse problema é mudar apenas o que dói. Não faça o polimento do código correto, legível e de manutenção, mesmo que você ache que algumas alterações possam torná-lo ainda melhor. Mas quando você estiver, por exemplo, tentando mudar algo e estúpido sobre uma variável cuja finalidade não é clara, ou uma função que é muito longa para ser compreendida, conserte-a. Não antes.

Isso não significa que você não deve se esforçar para obter um código bom e limpo, é claro que deve, mas deve considerar sua primeira tentativa "boa o suficiente", a menos que se prove o contrário.

Acho que o melhor antídoto para isso é lembrar-se de que todas essas práticas recomendadas e regras de limpeza de código não existem por si só, nem o próprio código.

No final, o que importa mais do que qualquer outra coisa é que o software funciona e pode ser usado. E isso não acontecerá se você não terminar.

Não gosto da comparação entre codificação e arte, mas, nesse sentido, funciona: artistas ( especialmente autores ) também querem continuar trabalhando em uma peça, porque sempre há algo que não é perfeito. Mas que valor há na perfeição quando adia a publicação indefinidamente e, assim, impede que alguém aprecie o trabalho?

O mais importante a ser percebido é que seu código sempre será alterado e sempre haverá espaço para melhorias. Nenhum código é perfeito. Na maioria das vezes, uma biblioteca de classes em que você trabalha hoje será muito diferente seis meses depois. Você aprende alguma nova técnica ou encontra um padrão que realmente funciona para você. Desde que o código seja fácil de manter e legível, você deve ser bom. Idealmente, você teria testes de unidade para facilitar a refatoração mais tarde no caminho.

É fácil se deixar levar pelo código perfeito e seguir todos os padrões que você puder imaginar. Isso acontece com todos nós. Examinar o código que escrevi algumas semanas atrás me faz pensar em fazer alterações. Adicione uma propriedade aqui, refatorar o método lá. E isso parece acontecer no final do projeto. Mas se você se envolver demais com isso, poderá acabar causando um erro de parada. Eu já fiz isso algumas vezes no início da minha carreira. Algumas sessões de correção de bugs das 3h da manhã me curaram desse problema.

Faça o contrário.

Em vez de "o que pode ser feito melhor?" procurar "o que me irrita?" até que nada faça.

Como programador, seu trabalho é produzir código. O objetivo das práticas recomendadas é aumentar sua taxa de produção, facilitando a compreensão / execução / memorização. Se aderir a essas práticas está atrapalhando a execução das coisas, você está fazendo algo errado. Simplesmente tente produzir código o mais rápido possível, e suas práticas devem evoluir para permitir que você faça exatamente isso.

Faça o trabalho, faça-o limpo, faça-o SÓLIDO, faça-o com desempenho.

Os três primeiros são um ditado que defendo sempre que alguém se pergunta como escrever código SOLID em uma linha do tempo. Quando você escreve uma linha de código pela primeira vez, ela simplesmente tem que funcionar, então faça o que você precisa fazer e não seja extravagante. A primeira vez que você revisita uma linha de código, ela não é mais única e você deve limpar o código, tornando-o legível e, portanto, mais sustentável. Na terceira vez que o cursor entra nessa linha, provavelmente é um grande negócio agora, e você deve refatorá-lo para aderir à metodologia SOLID, abstraindo dependências, implementando padrões e geralmente facilitando o código ou a conexão do código para aprimoramento futuro.

A elegância no código deve ser alcançada onde o programador percebe uma oportunidade e geralmente é uma função de simplificar, limpar e geralmente melhorar a legibilidade e a manutenção do código enquanto segue as etapas anteriores. Não é algo a ser maximizado .

O código de desempenho é quase sempre a menor preocupação em linguagens gerenciadas por memória (Java, família .NET, linguagens mais funcionais etc.). Nesses ambientes, o objetivo é escrever o código correto ("correto" aqui definido como produzindo o resultado esperado em todos os casos esperados, esendo compreensível e bem estruturado e, portanto, mantenível), e o desempenho é secundário (geralmente, ele irá prosseguir até certo ponto a partir do código correto). Em todos os casos, um algoritmo tem desempenho quando é "bom o suficiente". Lembre-se: "a otimização prematura é a raiz de todo mal"; fazer otimizações que você não sabe que precisará faz pouco mais do que perder tempo, ofuscar código e geralmente impedir o progresso. Ele precisa funcionar primeiro e, depois que funcionar, você o executa e vê com que rapidez ele é executado. Se não for rápido o suficiente (conforme definido por algum benchmark que é um requisito publicado), você o aprimora até que seja e depois para.

Você realmente precisa ser pragmático em programação. Sim, todos gostamos de fazer as coisas da maneira certa, mas você é pago pelo fornecimento de software funcional, não pelo aprimoramento pelo resto da vida.

A abordagem a ser adotada é "fazê-lo" em sua vida profissional. Entregar e seguir em frente. Salve seu perfeccionismo para projetos pessoais.