Onde você desenha a linha para o seu perfeccionismo? [fechadas]

37

O perfeccionismo pode ser bom e ruim ao programar.

  • Quando e onde você desenha a linha quando está resolvendo problemas?
  • Quando você decide quando uma solução é um exagero, muito geral ou simplesmente muito futurista?

Comente se a pergunta não está clara.

Amir Rezaei
fonte
7
Boa pergunta - eu sempre luto com isso.
Ninguém

Respostas:

40

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:

  • KISS = Mantenha as coisas simples, estúpido = finja que você é um idiota e precisa entender o design
  • YAGNI = Você não precisa disso = pare de fingir que pode prever o futuro em seu design
Joeri Sebrechts
fonte
5
+1 - Já é difícil resolver os problemas que sabemos que temos, sem tentar resolver os problemas que achamos que podemos ter.
Jon Hopkins
6
Eu gosto disso, mas uma definição clara dos acrônimos seria útil. Eu nunca tinha ouvido falar YAGNIaté hoje.
Philip Regan
+1 para Philip que aprende algo hoje! +1 para o KISS também.
Bem, a resposta é boa. Embora, obviamente, qualquer interface (seja para armazenamento permanente (arquivos), rede ou IPC) deva pelo menos ser versionável ou você saiba que seu novo design tornará a compatibilidade retroativa impossível.
Deduplicator
7

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.

Sean McEligot
fonte
6

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.

Dan McGrath
fonte
6

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.

Pete
fonte
5

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.

Thomas Stock
fonte
11
+1 Por experiência, faça você comprometer mais.
Amir Rezaei
4

O prazo limita essa linha.

Simon
fonte
11
Bom ponto, mas uma solução ruim pode precisar de mais tempo para corrigir no futuro.
Amir Rezaei
Eu acho que você tem que fazer um julgamento sobre o que é software "bom o suficiente". A linha deve ser definida pela especificação e seu senso comum.
Ninguém
3

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:

  • Maneiras de melhorar a capacidade de uso e reduzir as chances de obter um bug no
  • Maneiras de reduzir as dependências, melhorando o tempo de compilação

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.

Matthieu M.
fonte
Eu compartilho com você o incômodo. Acredito que a programação é como algum tipo de arte em que não há perfeição.
Amir Rezaei 14/01
2

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.)

BlairHippo
fonte
0

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 .

l0b0
fonte
O perfeccionismo não é possível, mesmo após MUITOS anos de experiência; isto é, se você realmente quiser ENTREGAR alguma coisa. A coisa mais valiosa que a experiência ensina é quando reconhecer "suficientemente bom".
precisa saber é o seguinte
0

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.

MPelletier
fonte