É um fluxo de trabalho ineficiente para escrever código e, em seguida, voltar e otimizar?

4

Sou um programador entusiasta mais recente. Eu tenho feito pequenos e grandes projetos dentro e fora nos últimos dois ou três anos.

Sempre encontro pequenas dificuldades no meu código que resultam em grandes porcos de memória ou linhas de código desnecessárias no futuro. Minha filosofia em grandes projetos sempre foi apenas "tirar isso da cabeça" e escrever todo o código em um produto funcional, depois voltar e reduzir o código para uma forma mais simples e otimizada. No entanto, isso nem sempre funciona: ao fazer estruturas de banco de dados, tenho a tendência de voltar muitas vezes para adicionar recursos que surgem no momento. Blocos inteiros de código precisam ser apagados por causa de uma criação espontânea.

A minha pergunta é: é mais eficiente escrever um programa inteiro e, ENTÃO, voltar e otimizá-lo, ou devo otimizar o código enquanto o escrevo?

    
por esqew 14.09.2011 / 06:00
fonte

6 respostas

10

A otimização prematura é a raiz de todo o mal.

Essa citação é usada em demasia e aplicada além do contexto pretendido original, mas o ponto geral certamente se aplica aqui: não pare de otimizar até ter certeza de que precisa otimizá-la, e você não terá certeza até depois de escrevi a maior parte do programa.

    
por 14.09.2011 / 06:33
fonte
9

is it more efficient to write an entire program and THEN go back and optimize it, or should I optimize code as I write it

Nenhum dos dois.

Você está perdendo um componente inteiro enorme para o SDLC: design .

Você deve provar conceitos com os quais não está familiarizado em um ambiente de área restrita (o que significa que ele não se vincula ao resto do projeto ou, se isso acontecer, é fácil trocá-lo por algo com um pouco de mais pensamento por trás disso.

Pegue os aprendizados do seu protótipo e escreva um projeto técnico. Até agora, você deve ter provado todas as incógnitas e descoberto possíveis pequenas dicas técnicas. A intenção aqui é liberar totalmente o seu design e torná-lo tão ideal quanto necessário (refatoração para otimização enquanto codificação é uma prática ruim).

Então implemente seu design. Pode haver pequenas descrições que você pode ter que explicar, mas quando você começar a escrever o código que entrará no seu projeto principal, você terá seu conceito comprovado (por prototipagem). bem como um design eficiente que considera tantos casos extremos como você e seus colegas podem pensar (design técnico).

    
por 14.09.2011 / 07:39
fonte
5

Eu vou te fazer uma contraproposta. Suponha que você tenha que delinear suas turmas primeiro, seja por algo parecido com brincadeiras UML, ou simplesmente esboços de classes, não importa, então, depois de ter determinado qual parece ser a melhor abordagem, comece a escrever. Depois de ter terminado uma parte notável do projeto, é apropriado voltar e limpar o lixo.

Dependendo da escala do projeto e do desenvolvedor, isso pode ser um conjunto de classes, uma classe individual ou até mesmo (raramente) um método. Mas quase nunca é uma boa ideia esperar até que tudo seja feito para otimizar. OTOH, também é igualmente ruim otimizar muito cedo. Isso deixa como única opção o processo de escrever e depois limpar, escrever e depois limpar.

    
por 14.09.2011 / 06:17
fonte
2

Não otimize tudo até que o programa em execução informe o que precisa ser otimizado .

Eis o que quero dizer.

Se otimizarmos sem saber o que otimizar , somos um pouco como bêbado procurando por suas chaves .

    
por 14.09.2011 / 14:19
fonte
1

No seu caso, parece que o melhor momento para "otimizar" depende do que você está fazendo.

Se o seu código é muito modular, brincar com ele mais tarde pode não ser muito chato, então pode ser melhor "otimizar" mais tarde. Se você depende muito do seu esquema de banco de dados, então mexer com seu esquema de banco de dados posteriormente pode ser irritante, então pode ser melhor "otimizar" antes.

("Otimizar" está entre aspas porque não tenho tanta certeza do que você quer dizer com "otimizar").

    
por 14.09.2011 / 07:08
fonte
1

Para mim, é sempre mais produtivo errar no lado da otimização em retrospectiva, apenas dar um tapa em uma implementação básica que é fácil de raciocinar em termos de correção e revisitar conforme necessário, com o profiler em mãos. Eu prefiro iterar para soluções mais rápidas quando possível / prático, porque eu gosto de ver meu sistema ser concretizado mais cedo, mesmo que eu tenha que voltar e detalhar tudo em áreas-chave.

Mas eu preciso colocar grande ênfase na parte prática , já que não é como você pode escrever um software cujo design gira em torno de interagir com pequenos objetos em um escalar, um por vez moda, e esperamos encontrar muito espaço para otimizar isso sem alterar o design. Não adianta ter um carro de corrida se houver apenas 10 metros de estrada para ser ultrapassado, e projetar interfaces excessivamente granulares que lidem com pequenas coisas uma por vez podem encurralar você assim com um design que não deixa a respiração espaço para otimização.

Por isso, ajuda quando você prevê uma área de desempenho crítico, que acredito que você pode antecipar sem medir *, para projetar interfaces suficientemente grosseiras, não granulares.

  • As said I believe you can anticipate where the performance-critical parts are in your system reasonably well, even if you may not be able to anticipate the details fully until measuring. All you have to do is ask basic questions like, "where are we going to be looping over a million things"? Well, if you are implementing a GUI system, it's obvious where you'll be looping over a million things, and that'll be in the GUI drawing functions where you can potentially be looping over a million pixels to process. It's not unreasonable to deduce, in foresight, that this area is probably going to be a performance-critical so that you design it with sufficient breathing room to optimize and optimize it in the future.

Por exemplo, em vez de fazer o sistema girar em torno da interação com objetos granulares Pixel , projete-o para interagir com coleções de Pixels com Image objetos que podem representar milhões de pixels de uma só vez. Da mesma forma, em vez de Particle objetos, interaja com um ParticleSystem . Em vez de Creature , interaja com Creatures . Em vez de um retorno de chamada que é projetado para processar uma pequena coisa de cada vez (um pixel de cada vez, por exemplo), tenha um retorno de chamada projetado para processar uma série de coisas por vez (um intervalo de pixels de uma só vez). Esses tipos de coisas vão te deixar muito mais espaço para otimizar sem alterar o design.

Bibliotecas de propósito geral

Dito isto, este conselho é orientado para pessoas como você que querem seguir em frente e lidar com grandes projetos. Se você está, digamos, na mentalidade de projetar uma biblioteca de propósito geral de estruturas de dados cujas intenções sejam tão amplamente aplicáveis quanto possível, e que é basicamente o produto final, então você pode economizar mais tempo pensando em como fazê-lo. o mais eficiente possível - claro, ainda medindo, ajustando e iterando o que você quiser, mas não apenas aplicando uma implementação básica, se você tiver certeza de que precisará reescrevê-la.

Nesses casos, eficiência e aplicabilidade são conceitos relacionados, pois se sua biblioteca é distorcida em características de desempenho e não possui estruturas de dados completas, as pessoas podem não usá-las muito ou você pode acabar com a introdução de mais e mais dados estruturas ao sintonizar as antigas poderiam ter bastado. Então, às vezes, pode ser que realmente se pague para tentar obter a versão mais eficiente que você pode, na maioria das vezes, antecipar. Eu descobri, ao longo dos anos, que melhorei a otimização de código e, especialmente, para a referência local, que posso usar cada vez menos estruturas de dados, acabando com estruturas de dados mais completas que posso usar em um ambiente mais amplo. gama de áreas em vez de aquelas com características de desempenho distorcidas que são estreitamente aplicáveis. O resultado final é muito menos código para manter e produtividade aprimorada, mesmo que isso tenha surgido de uma mentalidade de otimização.

    
por 17.12.2017 / 07:03
fonte