… ou lote.
(Adaptado de um memorando interno escrito durante a revisão de algum código e compartilhado com uma equipe nova na escrita de código que funciona com dados de um servidor remoto)
Você está no 6º andar aqui, imagine que precisa confirmar alguns números e levar um documento para ser assinado no 6º andar do prédio ao lado. Você também deve trazer dois documentos de lá. Os elevadores não estão funcionando em nenhum dos edifícios. Ligar para o telefone ou digitalizar e enviar esses documentos por e-mail não é permitido (lei / sigilo / o que for). Quantas viagens você fará?
Cenário A:
- Desça as escadas desse prédio, corra até a próxima, confirme os números e volte.
- Pegue o documento a ser assinado (novamente descendo e subindo as escadas) e volte.
- Vá novamente para trazer cada documento de volta.
Cenário B:
- Pegue os números a serem confirmados e o documento a ser assinado. Faça isso. Traga de volta os outros documentos de lá, todos em uma viagem
Se você escolheu o Cenário A e não está fazendo uma dieta especial ou programa de exercícios, nem está se preparando para uma maratona, temos um problema.
Se você escolheu o Cenário B, há esperança. Espero que você aplique a mesma analogia / lógica ao escrever o código. Ter que correr para baixo e subir as escadas é o que você pode pensar que acontece toda vez que você cruza um ” limite de código ” (TM não-real). É o que você está fazendo com que a CPU faça ao escolher / escrever um algoritmo que poderia ser melhor. Dependendo do nível que você deseja entender a analogia / metáfora, um “limite de código” pode ser muitas coisas – indo da máquina local para a rede, da RAM para o disco, de um nível de cache da CPU para outro, de Java para nativo código / C ++ (JNI) etc. Você viu oVídeo de desempenho da folha de Sprite Code And Web Texture Packer que recomenda o uso de um atlas de textura para minimizar as mudanças de estado? A mesma lógica se aplica – a execução vai do código do aplicativo, para o driver, para a GPU.
Um caso
Project / SendSentenceActivity.java e PlayGameActivity.java são duas fontes que foram revisadas. PlayGameActivitymostra as frases dos dois jogadores até agora e um botão de reprodução. SendSentenceActivityé mostrado quando o jogador pressiona o botão play. Mostra as palavras-chave bônus e palavras-chave que darão pontos ao jogador quando usadas na frase que ele joga / envia.
Quando o jogador pressiona o botão enviar SendSentenceActivity, ele verifica se há frases duplicadas, validação específica de outro modo de jogo (Double-Dog) etc., calcula uma pontuação e então …
(Se você adivinhou “envia a frase para o servidor”, resposta errada!)
… Envia para o servidor para “substituir palavras bônus”. O manipulador no servidor para isso recebe (apenas) as palavras bônus e atualiza seu status (usado ou não usado) para o jogo específico (história).
O SendSentenceActivityentão fecha e envia a frase (e pontuação) para PlayGameActivity(passado junto com o objeto Intent), que então inicia uma solicitação de rede subsequente ( ). Mas logo antes disso, ele faz até mais duas solicitações de rede para atualizar quaisquer conquistas desbloqueadas nessa frase.story.addSentence
De ambos os pontos de vista – cliente e servidor, isso pode ser claramente melhorado. Do lado do cliente, o aplicativo deve coletar todos os dados de que precisa para enviar ao servidor e enviá-los de uma vez (em lote). Do lado do servidor, ele deve fornecer os pontos de extremidade da API / solicitação de forma a minimizar o número de chamadas necessárias para o servidor. As equipes devem discutir seus planos e levar à revisão do código umas das outras (discutindo em um scrum ou separadamente – “Aqui está o que estou fazendo ou planejando fazer para X, alguém vê algum problema ou tem uma melhoria a sugerir?”) Para certifique-se de que problemas como esse sejam identificados com antecedência e que todos aprendam mais.
Neste caso particular, apenas uma API sendSentencepoderia fazer toda a validação, calcular pontos, conquistas, atualizar palavras usadas etc e retornar os dados necessários. Um benefício adicional de ter a validação acontecendo no servidor é o anti-cheating. Você não pode confiar nos dados do cliente em um modelo cliente-servidor. Se você acha que algo pode ser trapaceado, mova essa lógica para o servidor. A única razão pela qual você pode querer pensar em trabalhar no lado do cliente é equilibrar a distribuição do processamento nos clientes versus o processamento central no servidor, se não for “trabalho” que precise ser validado – mas isso é outra discussão.
Espero que os nomes das classes e a descrição acima forneçam contexto suficiente para o caso e ilustrem o conceito.
Uma conversa relacionada / veja também: Práticas recomendadas de rede da Apple WWDC 2012. Requer uma conta de desenvolvedor Apple registrada para visualizar. Uma conta gratuita também serve.