Sobre otimização Prematura — a raíz de Todo o Mal

Minhas anotações da palestra do Fabio Akita no fechamento do 18 Encontro Locaweb em São Paulo.

• Qual o seu motivo para querer criar um site SPA (Single Page Applications)?
• Se você quer fazer um sistema como Spotify, Google Drive, ou até um Dashboard administrativo, é indicado que você faça um SPA
• Mas se vai fazer um site de conteúdo, e-commerce ou qualquer coisa que dependa de conteúdo, não faça SPA.
• Esse é o problema da otimização prematura. Queremos otimizar algo que nem sabemos se precisa de otimização. O que você quer otimizar com SPA? Quer exibir texto mais rápido?
• A maioria dessas tecnologias, arquiteturas e etc, otimiza muito bem em alguns tipos de ambientes e isso não significa que o seu ambiente (contexto) precisa ou pode ser otimizado
• Existem casos e casos para usar Microserviços. Se você está sozinho ou se o time é pequeno, não há motivo para fazer microserviço. Vocês conseguem ter o controle total de um produto/sistema monolítico
• Entenda o seu contexto. Existem empresas que gastam mais de USD$100.000,00 apenas em infra. Mas elas faturam quase 1 Bilhão.
• Custo mínimo de TI:
  USD$1000 — Cloud
  USD$3000 — 1 Developer
  USD$4000 — 1 Responsável (manager, marketing, etc)
• Você tem que estar preparado para gastar por volta de USD$96.000. Este é o mínimo.
• Você precisa ganhar algo em torno de 2 milhões de dólares no ano para o custo de TI precisa ficar por volta de 5%.
• Não tente diminuir custo, tente aumentar a receita.
• Tente conseguir mais pessoas comprando seu produto, aumentando sua receita.
• Isso acontece quando você tira os bugs do sistema e o usuário consegue finalizar a compra. É quando seu site consegue se manter no ar em dias de pico de visitação e as pessoas conseguem finalizar as compras. É aí que você ganha dinheiro
• Não se atenha a uma stack específica de tecnologias. Se você usa .NET, não precisa ser tudo Microsoft. Best of Breed.
• Escolha as melhores tecnologias que te trazem os maiores retornos.
• Não faz sentido uma empresa de produto ter suas próprias máquinas, racks e servidores.
• A menos que essa empresa seja de comunicação e que seu core business seja mensageria, talvez, quem sabe, NodeJS é uma tecnologia a se considerar.
• Veja os serviços como Pusher, PubNub
• O Pusher custa USD$ 49 para 500 conexões simultâneas. Você não vai conseguir melhor que isso fazendo você mesmo. Só de cloud você vai gastar uns USD$30.
• Todo mundo ainda tem falado sobre SEO como se soubesse de algum segredo. SEO é astrologia. Se qualquer um que soubesse realmente os detalhes de fazer um site bem posicionado, essa pessoa trabalharia no Google.
• Acredite sempre no básico:
  - Você tem URLs amigáveis
  - Usa sitemap.xml?
  - Redireciona HTTP301
  - Usa botões de redes sociais?
  - Tem conteúdo original relevante? Se seu conteúdo é irrelevante, não adianta…
  - Não copie conteúdo dos outros.
• Pronto, voce não precisa saber mais nada de SEO. É isso que todo mundo sabe e o que os sistemas de busca divulgam.
• The Twelve-Factor App I. Codebase One codebase tracked in revision control, many deploys II. Dependencies Explicitly declare and isolate dependencies III. Config Store config in the environment IV. Backing services Treat backing services as attached resources V. Build, release, run Strictly separate build and run stages VI. Processes Execute the app as one or more stateless processes VII. Port binding Export services via port binding VIII. Concurrency Scale out via the process model IX. Disposability Maximize robustness with fast startup and graceful shutdown X. Dev/prod parity Keep development, staging, and production as similar as possible XI. Logs Treat logs as event streams XII. Admin processes Run admin/management tasks as one-off processes
• Quando falamos em código, não precisamos estar preocupados em ganhar tempo. O que é ruim e não faça:
• Seu sistema não tem pelo menos 70% de cobertura de testes
• Não tem analise estática de código. É um programa lendo seu programa para dar uma nota. (Sugestão: CodeClimate)
• Nenhum código fonte pode ter centenas de linhas por arquivo
• Não deve ter Copy Paste em todo o lugar do código.
• Não pode haver funções com o tamanho de mais de um page down
• Banco de dados com vários campos inúteis
• Se você faz um clone no projeto, você precisa rodar na máquina em minutos, não horas.
• Spree: 68k de linhas de código. 40k dessas linhas são testes.
• Magento: 300k de linhas 127k são testes. Poucos testes, 10 vezes mais problemas.
• Sua preocupação não pode ser só com performance, é preocupação com manutenabilidade.
• Programadores são ruins para priorizar coisas.
• Instale New Relic. Não importa sua linguagem. Ele vai coletar seus dados de produção e vai te dar um monte de números para você conhecer seu produto. #ficadica
• Teoria das Correntes: como você determina a força de uma corrente, pelo elo mais fraco. Como você resolve? você troca o elo mais fraco. Quando você fizer, um outro elo será mais fraco.
• Sem métricas, sem otimização. Voce tem número? Se não, você está chutando.
• Primeiro você faça funcionar, depois você corrige, depois você pensa em tornar rápido e finalmente, você pensa me tornar barato — Alan Kay
• Essa é a ordem, você não pode mudá-la!
• O facebook precisa do React? O Google precisa do Angular? Eles não precisam dessas tecnologias para sobreviver.
• Você precisa usar tecnologias de empresas que realmente precisam das suas próprias tecnologias, que realmente ganham dinheiro com elas.
• Não se preocupe em reduzir custos, se preocupe em fazer funcionar, para você ganhar dinheiro e sobreviver.
• Best of Breed Open Source
• Na dúvida, não faz do zero. Use SAAS.
• SEO = Astrologia
• Manutenção > Performance
• Prioridades. Não otimize sem métricas.
• O maior problema dos programadores é a Otimização Prematura.

Originally published at diegoeis.com.