É quase garantido, realmente. De novatos a experts , da arquitetura ao ASM e otimizando tudo, desde o desempenho da máquina até o desempenho do desenvolvedor, as chances são muito boas de que você e sua equipe estão causando um curto-circuito em seus próprios objetivos.

O que? EU? Minhas equipe?

Essa é uma acusação bastante pesada para levantar. Deixe-me explicar.

A otimização não é o Santo Graal, mas pode ser igualmente difícil de obter. Quero compartilhar com vocês algumas dicas simples (e uma montanha de armadilhas) para ajudar a transformar a experiência de sua equipe de auto-sabotagem em harmonia, realização, equilíbrio e, eventualmente, otimização.

O que é otimização prematura?

A otimização prematura está tentando otimizar o desempenho:

1. Ao codificar um algoritmo pela primeira vez
2. Antes de os benchmarks confirmarem, você precisa
3. Antes de definir o perfil, identifique onde faz sentido se preocupar em otimizar
4. Em um nível mais baixo do que o seu projeto determina atualmente

Agora, sou um otimista, Optimus.

Pelo menos, vou fingir ser um otimista enquanto escrevo este artigo. De sua parte, você pode fingir que seu nome é Optimus, então isso vai falar mais diretamente com você.

Como alguém da área de tecnologia, você provavelmente às vezes se pergunta como poderia ser $year e ainda, apesar de todo o nosso avanço, é de alguma forma um padrão aceitável para $task ser tão irritantemente demorado. Você quer ser magro. Eficiente. Impressionante. Alguém como os Programadores Rockstar, por quem essas ofertas de emprego estão clamando, mas com talento de líder. Portanto, quando sua equipe escreve código, você os incentiva a fazer certo da primeira vez (mesmo que “certo” seja um termo altamente relativo, aqui). Eles sabem que esse é o jeito do Clever Coder, e também o jeito daqueles que não precisam perder tempo refatorando depois.

Eu sinto isso. A força do perfeccionismo às vezes é forte dentro de mim também. Você quer que sua equipe gaste um pequeno hora agora de salvar um muito de tempo depois, porque todos estão trabalhando duro em sua parcela de“Código de merda que outras pessoas escreveram (o que diabos eles estavam pensando?).”Isso é SCOPWWHWTT para breve, porque eu sei que você gosta de siglas impronunciáveis.

Eu também sei que você não quer que o código da sua equipe seja para eles ou para qualquer outra pessoa no futuro.

Então, vamos ver o que pode ser feito para guiar sua equipe na direção certa.

o que para otimizar: bem-vindo a ser uma arte

Em primeiro lugar, quando pensamos em otimização de programa, muitas vezes assumimos imediatamente que estamos falando sobre desempenho . Até este já é mais vago do que pode parecer (velocidade? uso de memória? etc.), então vamos parar por aí.

Vamos acertar as contas Mais ambíguo! Só no começo.

Meu cérebro teia de aranha gosta de criar ordem sempre que possível, então vou precisar de cada grama de otimismo para considerar o que estou prestes a dizer como um coisa boa .

Existe uma regra simples de otimização (de desempenho) que vai Não faça isso . Parece muito fácil de seguir rigidamente, mas nem todos concordam com isso. Eu também não concordo totalmente com isso. Algumas pessoas simplesmente escreverão um código melhor do que outras. Esperançosamente, para qualquer pessoa, a qualidade do código que eles escreveriam em um novo projeto geralmente melhorará com o tempo. Mas eu sei que, para muitos programadores, esse não será o caso, porque quanto mais eles sabem, mais maneiras eles serão tentados a otimizar prematuramente.

Para muitos programadores ... quanto mais eles sabem, mais maneiras eles serão tentados a otimizar prematuramente.

Então, é isso Não faça isso não pode ser uma ciência exata, mas destina-se apenas a neutralizar a necessidade interna típica do técnico de resolver o quebra-cabeça. Afinal, é isso que atrai muitos programadores para o ofício em primeiro lugar. Entendi. Mas peça a eles para Salve isso , para resistir à tentação. Se alguém precisa de uma solução para quebra-cabeças agora mesmo , sempre se pode brincar com o Sudoku do jornal de domingo, ou pegar um livro Mensa, ou ir código de golfe com algum problema artificial. Mas deixe-o fora do repositório até o momento adequado. Quase sempre este é um caminho mais sábio do que a pré-otimização.

Lembre-se, esta prática é notória o suficiente para que as pessoas perguntem se Otimização prematura é a raiz de todo o mal . (Eu não iria tão longe, mas concordo com o sentimento.)

Não estou dizendo que devemos escolher a maneira mais sem cérebro que podemos pensar em todos os níveis de design. Claro que não. Mas em vez de escolher o mais inteligente, podemos considere outros valores :

1. O mais fácil de explicar para seu novo contratado
2. O mais provável de ser aprovado em uma revisão de código por seu desenvolvedor mais experiente
3. O mais sustentável
4. O mais rápido de escrever
5. O mais fácil de testar
6. O mais portátil
7. etc.

Mas é aqui que o problema se mostra difícil. Não se trata apenas de evitando otimizar para velocidade , tamanho do código, espaço de memória, flexibilidade ou compatibilidade com o futuro. É uma questão de equilíbrio e se o que você está fazendo está realmente de acordo com seus valores e objetivos. É totalmente contextual e às vezes até impossível de medir objetivamente.

É uma arte. (C.f. A Arte da Programação de Computador .)

Por que isso é uma coisa boa? Porque a vida é assim. É bagunçado. Nossos cérebros orientados para a programação às vezes querem tanto criar ordem no caos que acabamos, ironicamente, multiplicando o caos. É como o paradoxo de tentar forçar alguém a amá-lo. Se você acha que conseguiu isso, não é mais amor; Enquanto isso, você está acusado de fazer reféns, provavelmente precisa de mais amor do que nunca, e esta metáfora deve ser uma das mais estranhas que eu poderia ter escolhido.

De qualquer forma, se você acha que encontrou o sistema perfeito para alguma coisa, bem ... aproveite a ilusão enquanto dura, eu acho. Está tudo bem, as falhas são oportunidades maravilhosas de aprender.

Mantenha a UX em mente

Vamos explorar como a experiência do usuário se encaixa entre essas prioridades potenciais. Afinal, até mesmo querer que algo tenha um bom desempenho é, em algum nível, UX.

Se você estiver trabalhando em uma IU, não importa qual estrutura ou linguagem o código usa, haverá uma certa quantidade de clichê e repetição. Definitivamente, pode ser valioso em termos de tempo do programador e clareza de código tentar reduzir isso. Para ajudar na arte de equilibrar prioridades, quero compartilhar algumas histórias.

Em um emprego, a empresa para a qual eu trabalhava usava um sistema corporativo de código fechado baseado em uma pilha de tecnologia opinativa. Na verdade, era tão opinativo que o fornecedor que nos vendeu se recusou a fazer personalizações de IU que não se encaixavam nas opiniões da pilha, porque era muito doloroso para seus desenvolvedores. Eu nunca usei a pilha deles, então não os condeno por isso, mas o fato é que essa compensação 'bom para o programador, ruim para o usuário' era assim incômodo para meus colegas de trabalho em certos contextos que acabei escrevendo um complemento de terceiros reimplementando esta parte da IU do sistema. (Foi um grande impulsionador da produtividade. Meus colegas adoraram! Mais de uma década depois, é ainda economizando tempo e frustração para todos.)

Não estou dizendo que a opinião é um problema em si; só que muito disso se tornou um problema em nosso caso. Como contra-exemplo, um dos grandes atrativos do Ruby on Rails é precisamente que ele é teimoso, em um ecossistema front-end onde facilmente se fica com vertigem por ter tantas opções. (Dê-me algo com opiniões até que eu possa descobrir as minhas!)

Por outro lado, você pode ficar tentado a coroar a UX como o Rei de Tudo em seu projeto. Um objetivo digno, mas deixe-me contar minha segunda história.

Alguns anos após o sucesso do projeto acima, um de meus colegas de trabalho me pediu para otimizar a UX, automatizando um certo cenário confuso da vida real que às vezes surgia, para que pudesse ser resolvido com um único clique. Comecei a analisar se era mesmo possível projetar um algoritmo que não tivesse nenhum falso positivo ou negativo por causa dos muitos e estranhos casos extremos do cenário. Quanto mais conversava com meu colega de trabalho sobre isso, mais percebia que os requisitos simplesmente não compensariam. O cenário só aparecia de vez em quando - mensalmente, digamos - e atualmente demorava alguns minutos para uma pessoa resolver. Até E se se pudéssemos automatizá-lo com sucesso, sem nenhum bug, levaria séculos para que o tempo necessário de desenvolvimento e manutenção fosse pago em termos de tempo economizado por meus colegas de trabalho. O prazer das pessoas em mim teve um momento difícil para dizer 'não', mas tive que interromper a conversa.

Portanto, deixe o computador fazer o que puder para ajudar o usuário, mas apenas até certo ponto. Mas como você sabe a extensão disso?

Uma abordagem que gosto de adotar é traçar o perfil da experiência do usuário como o perfil de seus desenvolvedores . Descubra com seus usuários onde eles passam mais tempo clicando ou digitando a mesma coisa repetidamente e veja se você pode otimizar essas interações. Seu código pode fazer algumas suposições sobre o que eles mais provavelmente irão inserir e tornar isso um padrão sem entrada? Além de determinados contextos proibidos (confirmação sem clique do EULA?), Isso pode realmente fazer uma diferença na produtividade e felicidade dos seus usuários. Faça alguns testes de usabilidade do corredor, se puder. Às vezes, você pode ter problemas para explicar o que é fácil para os computadores ajudarem e o que não é ... mas, no geral, esse valor é provavelmente de grande importância para seus usuários.

Evitando a otimização prematura: quando e como otimizar

Apesar de nossa exploração de outros contextos, vamos agora assumir explicitamente que estamos otimizando algum aspecto do desempenho bruto da máquina para o resto deste artigo. Minha abordagem sugerida se aplica a outros alvos também, como flexibilidade, mas cada alvo terá suas próprias pegadinhas; o ponto principal é que otimizar prematuramente para qualquer coisa provavelmente irá falhar.

Então, em termos de desempenho, quais métodos de otimização existem para realmente seguir? Vamos cavar.

Esta não é uma iniciativa popular, é Triple-Eh

O TL; DR é: Trabalhe de cima para baixo . Otimizações de nível superior podem ser feitas no início do projeto, e as de nível inferior devem ser deixadas para depois. Isso é tudo que você precisa para entender melhor o significado da frase 'otimização prematura'; fazer coisas fora dessa ordem tem uma grande probabilidade de desperdiçar o tempo de sua equipe e ser contra-eficaz. Afinal, você não escreve o projeto inteiro em código de máquina desde o início, não é? Então, nosso AAA modo de operação é otimizar nesta ordem:

1. Arquitetura
2. Algoritmos
3. Montagem

O senso comum diz que algoritmos e estruturas de dados costumam ser os locais mais eficazes para otimizar, pelo menos no que diz respeito ao desempenho. Porém, lembre-se de que a arquitetura às vezes determina quais algoritmos e estruturas de dados podem ser usados.

Certa vez, descobri um software que fazia um relatório financeiro ao consultar um banco de dados SQL várias vezes para cada transação financeira e, em seguida, fazia um cálculo muito básico no lado do cliente. A pequena empresa levou apenas alguns meses de uso do software antes mesmo de sua quantidade relativamente pequena de dados financeiros significar que, com desktops novos e um servidor bastante robusto, o tempo de geração de relatório já era de vários minutos, e isso era um que eles precisavam usar com bastante frequência. Acabei escrevendo uma instrução SQL direta que continha a lógica de soma - frustrando sua arquitetura movendo o trabalho para o servidor para evitar toda a duplicação e viagens de ida e volta da rede - e até mesmo vários anos de dados depois, minha versão poderia gerar o mesmo relatório em meros milissegundos no mesmo hardware antigo.

Às vezes, você não tem influência sobre a arquitetura de um projeto porque é tarde demais para que uma mudança na arquitetura seja viável. Às vezes, seus desenvolvedores podem contornar isso como eu fiz no exemplo acima. Mas se você está no início de um projeto e tem algo a dizer sobre sua arquitetura, agora é a hora de otimizá-lo.

Arquitetura

Em um projeto, a arquitetura é a parte mais cara de se alterar após o fato, então este é um lugar onde pode fazer sentido otimizar no início. Se seu aplicativo for entregar dados via avestruzes , por exemplo, você vai querer estruturá-lo em pacotes de baixa frequência e alta carga útil para evitar tornar um gargalo ainda pior. Neste caso, é melhor você ter uma implementação completa do Tetris para entreter seus usuários, porque um botão giratório de carregamento simplesmente não vai resolver. (Brincadeiras à parte: anos atrás eu estava instalando minha primeira distribuição Linux, Corel Linux 2.0, e fiquei encantado que o longo processo de instalação incluía apenas isso. Tendo visto as telas de infomercial do instalador do Windows 95 tantas vezes que as memorizei, foi uma lufada de ar fresco na época.)

Como um exemplo de mudança de arquitetura que é cara, a razão para o relatório SQL mencionado ser tão altamente não escalável em primeiro lugar está clara em sua história. O aplicativo evoluiu ao longo do tempo, de suas raízes no MS-DOS e um banco de dados personalizado desenvolvido internamente que não era originalmente multiusuário. Quando o fornecedor finalmente mudou para SQL, o esquema e o código de relatório parecem ter sido transferidos um por um. Isso os deixou com anos de melhorias impressionantes de mais de 1.000% no desempenho para espalhar por todas as suas atualizações, sempre que concluíssem a mudança de arquitetura fazendo uso das vantagens do SQL para um determinado relatório. Bom para negócios com clientes presos, como meu então empregador, e claramente tentando priorizar a eficiência da codificação durante a transição inicial. Mas atender às necessidades dos clientes, em alguns casos, é tão eficaz quanto um martelo gira um parafuso.

A arquitetura trata, em parte, de prever até que ponto seu projeto precisará ser escalonado e de que maneiras. Como a arquitetura é de alto nível, é difícil ser concreto com o que devemos e não devemos fazer sem restringir nosso foco a tecnologias e domínios específicos.

Eu não chamaria assim, mas todo mundo o chama

Felizmente, a Internet está repleta de sabedoria coletada sobre quase todos os tipos de arquitetura já sonhados. Quando você sabe que é hora de otimizar sua arquitetura, pesquisar as armadilhas basicamente se resume a descobrir a palavra da moda que descreve sua visão brilhante. Provavelmente, alguém pensou da mesma forma que você, tentou, falhou, iterou e publicou sobre isso em um blog ou livro.

A identificação de palavras da moda pode ser difícil de realizar apenas pesquisando, porque para o que você chama de FLDSMDFR, alguém já cunhou o termo SCOPWWHWTT e eles descrevem o mesmo problema que você está resolvendo, mas usando um vocabulário completamente diferente do que você faria. Comunidades de desenvolvedores para o resgate! Acesse StackExchange ou HashNode com uma descrição tão completa quanto possível, além de todos os chavões de sua arquitetura não é , para que saibam que você fez pesquisas preliminares suficientes. Alguém ficará feliz em esclarecê-lo.

Entretanto, alguns conselhos gerais pode ser um bom alimento para o pensamento.

Algoritmos e montagem

Dada uma arquitetura propícia, é aqui que os programadores de sua equipe obterão o máximo de resultados para seu tempo. A prevenção básica da otimização prematura se aplica aqui também, mas seus programadores fariam bem em considerar algumas das especificações neste nível. Há muito o que pensar quando se trata de detalhes de implementação que Eu escrevi um artigo separado sobre otimização de código voltada para programadores de linha de frente e seniores .

Mas uma vez que você e sua equipe implementaram algo não otimizado em termos de desempenho, você realmente deixa como Não faça isso ? Você Nunca otimizar?

Você está certo. A próxima regra é, apenas para especialistas, Não faça isso ainda .

É hora de fazer o benchmark!

Seu código funciona. Talvez seja tão lento que você já conhecer você precisará otimizar, porque é o código que será executado com frequência. Talvez você não tenha certeza ou tenha um algoritmo O (n) e imagine que provavelmente está tudo bem. Não importa qual seja o caso, se este algoritmo pode valer a pena otimizar, minha recomendação neste ponto é a mesma: execute um benchmark simples.

Por quê? Não está claro que meu algoritmo O (n³) não pode ser pior do que qualquer outra coisa? Bem, por dois motivos:

1. Você pode adicionar o benchmark ao seu conjunto de testes, como uma medida objetiva de seus objetivos de desempenho, independentemente de eles estarem sendo alcançados.
2. Mesmo os especialistas podem inadvertidamente tornar as coisas mais lentas. Mesmo quando parece óbvio. Mesmo óbvio.

Não acredita em mim nesse segundo ponto?

Como obter melhores resultados com hardware de $ 1.400 do que com hardware de $ 7.000

Jeff Atwood da fama StackOverflow uma vez apontado que às vezes (geralmente, na opinião dele) pode ser mais econômico apenas comprar um hardware melhor do que gastar um tempo valioso do programador na otimização. OK, então suponha que você tenha chegado a uma conclusão razoavelmente objetiva de que seu projeto se encaixaria neste cenário. Vamos supor ainda que o que você está tentando otimizar é o tempo de compilação, porque é um projeto pesado do Swift em que você está trabalhando, e isso se tornou um grande gargalo para o desenvolvedor. Hora de comprar hardware!

O que você deve comprar? Bem, obviamente, iene por iene, hardware mais caro tende a funcionar melhor do que hardware mais barato. Então, obviamente, um Mac Pro de $ 7.000 deve compilar seu software mais rápido do que um Mac Mini de gama média, certo?

Errado!

Acontece que este as vezes mais núcleos significa compilação mais eficiente ... e, neste caso específico, o LinkedIn descobriu da maneira mais difícil que o oposto é verdadeiro para sua pilha.

Mas eu vi a administração que cometeu um erro ainda mais: eles nem mesmo compararam antes e depois e descobriram que uma atualização de hardware não fez seu software “parecer” mais rápido. Mas não havia como saber com certeza; e, além disso, eles ainda não tinham ideia de onde estava o gargalo, por isso continuaram insatisfeitos com o desempenho, tendo gasto o tempo e o dinheiro que estavam dispostos a alocar para o problema.

OK, eu já fiz o benchmarking. Posso realmente otimizar Ainda ??

Sim, supondo que você decidiu que precisa. Mas talvez essa decisão espere até que mais / todos os outros algoritmos sejam implementados também, para que você possa ver como as partes móveis se encaixam e quais são mais importantes por meio da criação de perfil. Isso pode ser no nível do aplicativo para um aplicativo pequeno ou pode se aplicar apenas a um subsistema. De qualquer forma, lembre-se de que um determinado algoritmo pode parecer importante para o aplicativo em geral, mas até mesmo especialistas, especialmente especialistas, estão propensos a diagnosticar mal .

Pense antes de interromper

'Eu não sei sobre vocês, mas ...'

Como alimento final para reflexão, considere como você pode aplicar a ideia de falsa otimização a uma visão muito mais ampla: seu projeto ou a própria empresa, ou mesmo um setor da economia.

Eu sei, é tentador pensar que a tecnologia vai salvar o dia e que podemos ser os heróis que fazem isso acontecer.

Além disso, se não fizermos isso, outra pessoa o fará.

Mas lembre-se de que o poder corrompe, apesar das melhores intenções. Não vou criar um link para nenhum artigo em particular aqui, mas se você ainda não leu nenhum, vale a pena pesquisar sobre o impacto mais amplo de desorganizar a economia e a quem isso às vezes serve. Você pode se surpreender com alguns dos efeitos colaterais de tentar salvar o mundo por meio da otimização.

PostScript

Você notou algo, Optimus? A única vez que te chamei de Optimus foi no início e agora no fim. Você não foi chamado de Optimus ao longo do artigo. Vou ser sincero, esqueci. Escrevi o artigo inteiro sem te chamar de Optimus. No final, quando percebi que deveria voltar e espalhar seu nome por todo o texto, uma vozinha dentro de mim disse: não faça isso .

Compreender o básico

O que é otimização prematura?

Tentando otimizar ao codificar pela primeira vez. A otimização do desempenho é melhor realizada a partir do nível mais alto possível em qualquer momento. Para projetos greenfield, em fase de arquitetura. Para projetos legados, após a criação de perfis adequada para identificar gargalos, em vez de jogar um jogo de adivinhação caro.

Por que a otimização prematura é ruim?

É uma armadilha oculta supor que o código (supostamente) com desempenho otimizado é, na verdade, sua primeira prioridade, acima da correção, clareza, testabilidade e assim por diante. Outra armadilha é presumir que o código em questão tem impacto suficiente no desempenho geral para valer a pena otimizá-lo. A otimização prematura atinge ambos.