As soluções ineficientes iniciais podem INSPIRAR as melhores e, assim, levar à resolução mais rápida de problemas?

5

Quando se depara com a escrita de um algoritmo para resolver um pequeno projeto / problema, é melhor criar um pseudo código que não seja eficiente / ótimo, mas resolva o problema e tente usar o código ineficiente para inspirar uma melhor / boa solução? A solução deve ser aceitável, não necessariamente do tipo "super-incrível-fora-deste-mundo".

A resposta é subjetiva, mas estou procurando uma opinião geral ou consenso de programadores experientes para desenvolver um melhor processo de geração de algoritmo / solução de problemas.

A razão pela qual eu pergunto isso é que eu frequentemente começo a compor o algoritmo mais intuitivo, mas então fico desorientado pensando em como ele é ineficiente e se eu deveria usar estruturas de dados melhores etc etc.

    
por rrazd 15.07.2011 / 17:29
fonte

7 respostas

5

Sim ... às vezes você precisa ter tempo para fazer "errado" (ou fechar) primeiro para finalmente acertar. Você geralmente chega a uma solução pela primeira vez - ENTÃO, vá para otimização e melhorias no design. Às vezes, você entenderá melhor o problema depois de passar pela primeira vez.

    
por 15.07.2011 / 17:45
fonte
3

Em geral, "eficiência" e "desempenho" precisam ser medidos. No entanto, se você estiver criando um algoritmo, existem técnicas para determinar (ou ter uma boa idéia) se ele será O (1), O (n), O (log n), O (n2) etc.

Às vezes, criar um código de trabalho ajuda a quebrar qualquer "bloqueio" que possa estar ocorrendo e, de fato, pode levar a outras soluções, e esperamos que melhores.

    
por 15.07.2011 / 17:35
fonte
0

Definitivamente.

Você precisa extrair exatamente o que deseja para descobrir o que precisa criar e o que deseja nem sempre é eficiente.

O oposto é muito pior - começando com métodos eficientes e tentando descobrir como fazer com que eles façam o que você precisa fazer. Você acaba com algo que pode ser rápido, mas não faz exatamente o que você quer. Ou você aplica alguns band-aids para fazer o que quiser e o código se torna uma bagunça.

Estou constantemente construindo algo para que funcione, refatorando para torná-lo mais amigável ao programador (sem copiar / colar código, comentários, dividindo métodos, etc.), verificando o desempenho para ver se o código precisa ser refinado em tudo.

    
por 15.07.2011 / 17:46
fonte
0

Absolutamente e de duas formas:

O primeiro é que, aplicando uma solução aproximada e não ideal, você começa a ver exatamente onde e por que ele falha, o que permite que você direcione seu esforço para problemas reais em vez de problemas que você acha que podem ocorrer.

O segundo é que às vezes você verá essas soluções difíceis e não ideais implementadas e funcionando bem, e essa é uma lição valiosa. Nem todas as soluções precisam ser projetadas com perfeição, às vezes difíceis e prontas fazem o trabalho e permitem que você gaste o esforço que você gastaria com o polimento desnecessário de algo que fará uma diferença genuína.

Pessoalmente, eu sofri pelo menos tanto com o código de engenharia que visava resolver problemas ou lidar com situações que nunca surgiram do que com soluções rápidas e sujas que não eram flexíveis e elegantes.

    
por 15.07.2011 / 17:52
fonte
0

TL; DR: Corre e corre bem, e quem são os padrões que você está cumprindo?

Você tem que olhar para isso como se o seu código é ineficiente ao ponto de ser impraticável. Você está aninhando para loops e switch declarações 5 deep, ou é algo tão simples como "whoops, usou uma matriz em vez de uma tabela de hash?"

Além disso, questionamentos posteriores, porque eu sei que faço isso, são seus próprios padrões para os quais você está mantendo seu código, ou é um padrão publicado ou padrão da empresa que você está tentando atender. Sim, é legal se seu código é executado em tempo O (nlogn), mas ele ocupa mais linhas do que sua empresa deseja que o código execute, ou talvez seja executado nesse tempo, mas é totalmente inatingível. Há um grande número de "padrões" que podem ser alcançados além da eficiência, e esses precisam ser levados em consideração.

    
por 15.07.2011 / 17:57
fonte
0

Eu sempre determino a melhor complexidade assintótica teórica antes de escrever qualquer código. Então eu tomo uma decisão consciente sobre se eu quero apontar para isso ou não. Se seus dados são finitos, como por exemplo, uma lista de países, você pode usar O (n) ou mesmo O (n 2 ) ao invés de um algoritmo O (1) e nunca notar. Nesse caso, minha principal consideração pode ser a manutenção em vez da eficiência.

Eu quase nunca reescrevo a eficiência a menos que um desenvolvedor anterior tenha feito uma escolha visivelmente ruim. Eu reescrevi meu primeiro rascunho para manutenção o tempo todo.

    
por 15.07.2011 / 18:09
fonte
0

O código que funciona agora é muito melhor que o código não lançado que pode funcionar mais rápido no futuro. É claro que bons programadores planejarão com antecedência e evitarão situações O (N ^ 2) desagradáveis, mas aqui está o meu ponto principal: Otimizar antes de medir é ruim.

Nada inspira a escrever código de uma maneira "melhor" do que ter código em execução para medir e, enquanto isso, você tem código em execução.

    
por 15.07.2011 / 20:54
fonte