Get best of the week

O que aprendi enquanto trabalhava no meu primeiro projeto em larga escala

Há oito meses, comecei a escrever um aplicativo no Electron. Para dominar essa tarefa, tive que desenvolver três subaplicações separadas que são executadas em ambientes diferentes. Abaixo vou falar sobre o que eu fiz para mim ao longo do caminho.



Fichário na sua forma original

Contexto


Antes de me aprofundar nos detalhes, começarei fornecendo algumas informações gerais necessárias para entender a situação. No início de 2019, comecei a procurar um estágio, conforme exigido pelo programa cooperativo da minha graduação. Em abril, enviei dezenas de currículos, cada um adaptado a um empregador específico, e no total recebi exatamente zero respostas. Você pode imaginar como eu reagi a isso - minhas mãos caíram, parecia que eu não estava apto para nada e não valia nenhum trabalho. Mas, em vez de deixar esses sentimentos prevalecerem, decidi provar a mim mesmo que ainda sei alguma coisa e posso me candidatar a algumas postagens. No final, descobri que, na verdade, sei menos do que esperava.

Comecei a revisar meus projetos em busca de um que pudesse ser transformado em algo de grande escala e complexo, que pudesse me estimular. Por fim, optei pelo Binder - na época, um aplicativo da Web simples que permitia gerenciar arquivos do Onedrive, Google Drive e Dropbox ao mesmo tempo. O objetivo era desenvolver um serviço de backup comparável em funcionalidade a essa trindade, menos a capacidade de transferir arquivos para outros usuários.

O começo do caminho


Provavelmente, eu não teria completado o projeto se não tivesse estabelecido alguns objetivos ilusórios desde o início. O primeiro marco que eu determinei foi a criação de uma versão alfa funcional para o meu aniversário, que eu celebro em meados de julho. Comecei a trabalhar imediatamente. No início de maio, criei um clone do Binder e comecei a desmontá-lo em partes, descartando muitas funções das quais não precisava mais. Em geral, peguei um aplicativo completamente decente e o transformei em um pedaço de código simples em algum lugar no nível do tutorial.

Decidi que escreverei quatro aplicativos separados. O primeiro é um cliente que funcionará nativamente no computador do usuário. A segunda é uma API com back-end, que facilitará o envio de solicitações seguras. Terceiro, o serviço de nuvem, responsável pela integridade de todos os dados armazenados nele. E, finalmente, uma página da web de "marketing", porque um produto não pode ficar sem um site brilhante.

E agora a diversão começa


Bem, bem, bem, admito: tudo o que eu disse até agora não tem nada a ver com a Electron, muito menos o desenvolvimento de aplicativos em larga escala. Mas eu precisava esclarecer o contexto para que você entendesse de onde obtive meu conhecimento. Aqui estão cinco lições principais que aprendi por mim mesmo:

# 1 Certifique-se de usar estruturas tradicionais para front-end e back-end, porque a comunicação entre processos é uma coisa estúpida

Com mais freqüência do que gostaria, eu surtei por causa de como a comunicação primitiva entre processos é implementada no Electron (e agora novamente no psico). Sim, a comunicação interprocessos não foi projetada para realizar a abstração de dados no espírito do Javascript, com a representação de funções como objetos e assim por diante. Mas quão mais fácil seria! E assim, em vez de criar um aplicativo cliente minimalista, enquanto a matriz principal de código estaria localizada no processo principal, fui forçado a separar claramente o que irá interagir com o usuário e o que não o fará. O critério pelo qual eu determinei o que entraria no processo principal e o que no processo de renderização foi formulado como uma pergunta simples: esse código serve alguma coisa? O tamanho do fragmento não importava. Se ele serviu outras partes do código,depois foi para o processo principal. A única exceção foi o ponto final do sistema de pagamento Stripe - por motivos de segurança, eu queria que ele fosse localizado o mais próximo possível do usuário.

№2 Fazer os dados manterem a integridade é muito, muito difícil,

até que comecei a trabalhar no Binder, não entendi o quão difícil era garantir que todos os dados provenientes de um número arbitrário e impressionante de usuários permanecessem sempre corretos e acessíveis. E apenas fornecer armazenamento seguro para eles não é uma tarefa fácil, mas agora você ainda quer que eu valide tudo e verifique se não há contradições com outros dados, sem ter idéia do que são os dados ?!

É claro que exagerei um pouco aqui, mas a essência do problema não é distorcida. A validação deve ocorrer o mais cedo possível nos estágios iniciais e depois ser repetida (em uma escala mais modesta) à medida que o fluxo de dados avança. Manter a consistência fica mais fácil se você usar um modelo transacional toda vez que alterar os dados. Para dizer a verdade, além dos dados em si, também há uma grande quantidade de metadados, o que não é muito mais fácil de gerenciar. Sempre pareceu uma ótima idéia escrever uma função que lê os dados do usuário e depois executa verificações de integridade. Mas, após muita deliberação, cheguei à conclusão de que as entradas secretas não são diferentes das portas da frente - toda a diferença é quem as usa.

No. 3 Interfaces - como sapatos que são costurados por encomenda



Uma ótima maneira de criar uma interface bonita e que funcione bem é encará-la como um par de sapatos de alfaiataria individuais (ou um terno adaptado à forma, isso não importa). A primeira pergunta que fiz a mim mesmo quando comecei o design do Binder: quem examinará a interface do aplicativo? Nota: Eu não falei sobre quem usará a interface. Esta deve ser a segunda pergunta, porque tudo está ligado precisamente à aparência. No passado, conduzi muitos projetos e posso lhe dizer com total confiança: as pessoas queriam cuspir no seu aplicativo se ele não parecer como deveria.



Comecei fazendo pequenos rascunhos em um caderno (com uma caneta esferográfica, porque tenho o hábito de duvidar constantemente de minhas idéias). Nos primeiros rascunhos, a ênfase estava na estrutura geral da interface e, só então, detalhando mais detalhadamente como cada uma das “páginas” deveria aparecer. Na minha opinião, as informações apresentadas não são tão importantes quanto sua legibilidade.

No. 4 Não há muita tolerância a falhas

Não sei você, mas, pensando que a API falhará depois que eu aceitei o pagamento, um suor frio surgirá. Começando a trabalhar no sistema de pagamento, eu disse a mim mesmo: "Agora você não pode perder um único erro". Certifiquei-me de implementar mecanismos de segurança durante todo o processo: desde o momento em que a API recebe uma solicitação para comprar um pacote de serviços, e até o Stripe passar as informações de pagamento ao sistema de notificação de eventos e o pacote ser ativado. É claro que esse tipo de paranóia atrasa o processo de desenvolvimento, mas não me arrependo de nada. Mas eu sempre tenho informações completas sobre quando o pagamento chegou, qual é o seu objetivo e qual o status das ações que devem segui-lo.

No. 5 Não é perfeito? Não assustador

Eu sou um perfeccionista, e minhas tentativas de criar algo impressionante muitas vezes ficam fora de controle e tornam infinitas dicas para cada linha de código e duvidam que elas tenham o direito de existir. Eu tenho que suportar batalhas comigo várias vezes sobre o que é ainda mais importante - eficiência ou legibilidade. Nos primeiros meses, eu ainda não tinha recebido minha visão e não entendi que grande parte do que desperdicei minha energia não tinha nenhum benefício prático - o objetivo é criar um produto que possa ser usado com uma mente calma e sem ferir. por algum prêmio de prestígio. É engraçado que minha quinta lição vá parcialmente contra a quarta, mas é até boa. A quarta lição me lembra cautela e atenção às expectativas do usuário, e a quinta estabelece limites para que eu não fique preso,melhorando uma função infinitamente.

Antes de dizermos adeus


Você leu meu artigo até o final e pode ter notado (bem ou não) que o Binder ainda não está totalmente operacional. No momento da redação, eu estava apenas lançando a primeira versão pública (beta 4). Não estou particularmente inclinado a transformar o Binder em um produto completo, mas mesmo assim o desenvolvi para que funcione como um aplicativo normal - de repente, todas as ambições repentinas tomam conta de mim. Uma página da web iridescente pode ser admirada aqui .

Tudo o que eu achava seguro para acesso aberto foi postado na página do projeto no GitHub. Lá postarei atualizações (e você poderá fazer o download do cliente para que ele se atualize). Ah, bem, aqui estão as estatísticas que eu compilei em quatro subaplicações para lisonjear minha vaidade:

fichário-local (cliente no Electron)



binder-web (página da web de beleza)



Nos outros dois, não comecei a contar automaticamente as linhas de código por motivos de segurança.

API do fichário

  • JavaScript: 21 arquivos, 4117 linhas
  • Outros arquivos: ~ 150 linhas

binder-mongo (serviço para verificar a integridade)

  • JavaScript: 16 arquivos, 2374 linhas
  • Outros arquivos: ~ 140 linhas

Número total de linhas de código: 30.015

More articles:


All Articles