O perfeccionismo pode ser bom e ruim ao programar.
Comente se a pergunta não está clara.
Respostas:
BEIJO e YAGNI , especialmente YAGNI.
Projete apenas uma solução para o que você sabe que precisará em breve. Não o projete para as coisas que podem ser necessárias em dois anos, porque provavelmente você precisará de coisas muito diferentes e precisará reprojetá-las de qualquer maneira.
No momento em que você começa a falar sobre "com esse design em algum momento no futuro, poderíamos executar X, ou até Y", em vez de "esse design nos permite fazer o requisito de cliente Z no próximo lançamento", é quando você recebe na astronomia da arquitetura.
Em resposta aos comentários:
YAGNIaté hoje.
Use uma abordagem iterativa e esse problema desaparece principalmente. Seu código deve ser executado no primeiro dia e quase todos os dias depois disso. Atenda primeiro aos requisitos mínimos e adicione mais conforme tiver tempo. Nunca desista de grandes mudanças, onde você não pode executar seu código por um longo tempo.
Uma solução é um exagero quando o tempo extra necessário para ser concluído vale mais do que o potencial impacto negativo, desde o momento em que a solução mais fácil é finalizada até quando ela será naturalmente atualizada / alterada.
Basicamente, você está negociando agora com o tempo posterior. Se você está gastando mais tempo agora, economiza mais tarde, está fazendo errado. Se você realmente está com mais de engenharia, está gastando um tempo agora que não afeta quanto tempo (ou até aumenta) você gasta mais tarde.
Você fica melhor trabalhando nisso, quanto mais experiência tiver. A melhor maneira de fazer as coisas (da minha experiência) é fazer o que você precisa agora, mas de uma maneira que seja mais facilmente aumentada caso os requisitos posteriores o exijam. Descobrir como fazer isso é complicado.
Eu costumava ser muito perfeccionista (gastando tempo criando estruturas, não soluções).
Mas o que realmente me ajudou a acelerar minha produção foi aprender e seguir os princípios do BDD / TDD, incluindo o princípio externo (que achei particularmente difícil aprender a adotar).
Isso realmente me ensinou a não escrever uma única linha de código antes que exista um teste para ela. Mas os testes de unidade também não existem antes de existir um teste de aceitação. E os testes de aceitação vêm de necessidades reais do usuário.
Portanto, todas as linhas de código se originam de uma necessidade real do usuário.
Se você não está familiarizado com o exterior, em princípio, determina que você comece a escrever testes para a camada mais externa do seu aplicativo (ou seja, a GUI em praticamente todos os casos) usando o teste dobre para simular o comportamento das camadas inferiores. Então você implementa apenas o suficiente para que os testes sejam aprovados. Essa implementação da camada superior determina os testes que você precisa escrever para a próxima camada, etc., até atingir a camada inferior do seu aplicativo.
Percebo que fico melhor com isso por experiência.
Quando eu era (muito) jovem, sempre procurava a solução mais perfeita, sem compromissos. Agora sou melhor em manter coisas como orçamento e tempo em mente.
O prazo limita essa linha.
Meu chefe realmente :)
Devo admitir que estou melhorando, mas ainda não tenho muito compromisso. Felizmente, eu tenho meu chefe para me controlar;)
Gostaria de levantar outro problema que não a engenharia excessiva, pois a engenharia é muito fácil de detectar.
Meu principal problema é com refatoração. O problema é que, na maioria das vezes, mesmo que eu tentasse escrever o código da melhor maneira possível, eu não sabia na época o que eu sei agora (vi mais códigos, mais padrões, novos idiomas, novos problemas, novos soluções). E assim, mesmo que funcione, agora conheço maneiras melhores de fazê-lo:
No entanto, está funcionando como está e, portanto, a refatoração não é uma prioridade, e a verdade é que está me incomodando; Entendo as razões econômicas e as expectativas dos clientes (eles não veem o código e preferem novos recursos e correções de bugs), mas gostaria de ter tempo para trabalhar ainda.
Por enquanto, apenas sigo a ordem do meu chefe, mas devo admitir que estou me sentindo desconfortável sabendo que o código entregue à produção não é o melhor que eu poderia apresentar agora. Perfeccionismo, eu acho.
Tanto profissionalmente como pessoalmente, o padrão que tento aplicar a mim mesmo é:
Satisfaça-se com a vitória.
Se meu código resolver o problema que ele pretende solucionar e não criar novos problemas *, é muito provável que seja hora de seguir em frente. Quando você aprende a definir a fasquia o mais alta possível, "" Bom o suficiente "se torna, bom, o suficiente.
A perfeição é como a velocidade da luz: você nunca chegará lá, mas não há limite para a energia que pode gastar tentando.
(* - Observe que "Buggy" e "Difícil de manter" se encaixam firmemente sob o título "Novos problemas". Portanto, não o concluo até que o código tenha sido testado, que os bits supérfluos tenham sido aparados e que os comentários / documentação da API atualizados.)
Com a experiência, percebi que o perfeccionismo não é possível até que eu tenha pelo menos alguns anos em um contexto particular (linguagem, estrutura, plataforma, padrão). Como novato, haverá todo tipo de idiossincrasias das quais você não estará ciente (escapamento, precedência, palavras reservadas, açúcar sintático, tempos limite, chamadas assíncronas, recursos e bugs não documentados); portanto, tentei uma boa solução, enquanto aprende o máximo possível. É importante ressaltar que sempre tento simplificar a refatoração do resultado - arquitetura modular, comentários quando necessário e nenhum truque inteligente .
Eu, como muitos outros programadores, tenho muito código legado para manter. A tentação de refazer tudo sempre estará lá, mas eu me reduzi a um princípio:
Eu (ou outra pessoa) vou ter que descobrir isso de novo ?
Isso geralmente cuida de muito código de espaguete em um código de espaguete-pedaço um pouco mais gerenciável. Abstraia alguns trechos, faça seus testes e agora ele não parece tanto com perfeição.