Como os grandes aplicativos JavaScript devem ser estruturados?

Recentemente, foram mostrados alguns plug-ins JavaScript criados para o OBIEE Mobile App Developer, bem como algumas bibliotecas personalizadas para vários projetos.

Vindo de um histórico de OOP, estou um pouco confuso sobre a estrutura desses projetos. Estou vendo arquivos com milhares de linhas. Estou acostumado a dividir as coisas em arquivos e classes, mas entendo que essa é uma estrutura diferente - por exemplo, o tamanho do arquivo é um problema -, mas deve haver uma maneira melhor de fazer tudo isso?

A duração dos scripts afeta não apenas a legibilidade e a manutenção, mas também a compreensão geral de uma pessoa sobre como o programa funciona.

Como os grandes aplicativos são estruturados? Algum padrão geral de design de OOP para isso?

Se você não conhece os padrões JavaScript, posso dizer que muitos aplicativos e bibliotecas grandes estão usando o Revealing Module Pattern , mas existem muitos outros padrões que você pode usar, dependendo de suas necessidades.

O Revealing Module Pattern, no entanto, deve oferecer uma boa maneira de dividir arquivos grandes e organizá-los logicamente; No entanto, quando você estiver trabalhando com qualquer padrão de design em JavaScript, saiba que isso pode se tornar muito confuso. Tente usar este , novo , protótipo , .call()e .apply()com sabedoria.

Ao trabalhar em grandes projetos, eles também podem ser úteis:

• Se possível, mude para TypeScript ou ES6.
• Escreva código modular . Existem várias maneiras e bibliotecas de terceiros, mas qualquer uma delas é melhor que nada.
• Use um Task Runner / Build System para automatizar tarefas.
• Leia sobre Design Patterns . Este poderia ser um bom começo. Como eu disse acima, o Revealing Module Pattern é muito útil, especialmente se você acha que precisa de tempo para dominar todos os padrões populares.
• Escreva testes de unidade . Trabalhar com uma linguagem dinâmica pode ser mais desafiador. Testar as partes cruciais do seu aplicativo pode economizar muito tempo.
• Use um IDE ou editor de texto que possa realmente ajudá-lo a escrever código e capturar bugs. WebStorm é uma boa escolha. Texto sublime também.
• Se o seu IDE não oferecer um depurador, tente dominar o depurador do seu navegador da web favorito.
• Use bibliotecas. Dependendo da natureza do projeto, tente empregar o melhor código de terceiros que você puder encontrar. Se você estiver escrevendo um aplicativo Web, consulte Angular , React e o bom e velho backbone.js . Se você estiver escrevendo um aplicativo Node.js., reserve um tempo para procurar no repositório do NPM . Você ficará surpreso com quantos pacotes já estão fazendo o que você estava prestes a fazer.
• Mesmo se você for a única pessoa que está trabalhando no projeto, ainda use um sistema de controle de versão como o Git e siga um padrão de codificação que não seja muito rigoroso e opinativo, mas ainda forneça uma boa linha de orientação à qual seus colegas de equipe também ficariam felizes em Segue.
• Mesmo se você optar pelo TypeScript ou ES6, ainda entendendo o OOP sem classe do JavaScript, o OOP Prototypal pode ser útil, especialmente durante a depuração.

Sou desenvolvedor de C ++ e comecei a desenvolver web recentemente. Estou portando um aplicativo de desktop grande para o ambiente da web. Estruturo meu código JavaScript exatamente como estruturei o código C ++, usando os mesmos padrões. Eu tenho cerca de 25 a 30 arquivos no total, mas acabarei reduzindo-os para 3-5, discotecando conforme apropriado e minimizando todos eles.

Para mim, é apenas a linguagem que mudou, para o bem ou para o mal, mas não o paradigma. O JavaScript, por todas as suas falhas e frustrações, é uma boa mistura de estilo funcional e OOP. As coisas funcionaram bem até agora.

Por fim, uma coisa que eu percebi desde o início foi que o JavaScript permite escrever um código muito mais conciso do que o C ++; portanto, às vezes, ter um grande número de LOC provenientes de uma linguagem não JS pode ser devido a uma maneira antiga de fazer as coisas. Depois que isso é resolvido, não vejo nada que realmente deva ser diferente. Afinal, design e algoritmos são independentes de linguagem.

Isso varia muito de projeto para projeto, é claro, mas a prática geralmente aceita é que, para itens que devem funcionar como bibliotecas ou módulos, coloque-os em um único arquivo grande e use o encapsulamento para impedir que ele seja interno ("privado") ) de vazamento para o exterior. Também é útil para desenvolvedores que desejam usar a biblioteca / módulo - um arquivo para adicionar à configuração do aplicativo ou ao snippet de cabeçalho, em vez de toda uma hierarquia de pastas e arquivos para copiar e colar. Também reflete o fato de que, com minimização e empacotamento, em um site de produção, provavelmente todos seriam combinados em um arquivo para reduzir o número de solicitações HTTP.

Seu próprio código de aplicativo não precisa seguir essa prática e provavelmente não deveria. Como seu aplicativo é o único a usá-lo, você só precisa adicionar os arquivos uma vez e provavelmente pode contar com a plataforma para lidar com a minimização e o empacotamento.

Ao trabalhar no código, os diferentes componentes são normalmente divididos em módulos, cada um implementando uma única classe e cada um vivendo em um arquivo separado. Durante a produção, esses arquivos são agrupados em um único arquivo (daí as milhares de linhas de código que você está vendo) usando algo como Browserify ( http://browserify.org/ ) ou RequireJS para reduzir o número de solicitações HTTP, mas também para garantir que as dependências sejam carregadas na ordem correta

Na medida em que as classes desses módulos são implementadas, é um pouco diferente da OOP na mecânica subjacente, mas não é tão diferente na superfície. O ES6 até introduziu a classpalavra - chave, por isso deve parecer bastante familiar. Este artigo sobre MDN é útil para começar: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain

Uso Net Elements e anotações (da Petri) para organizar ou "estruturar" o software para meus aplicativos de formulário PDF - programas JavaScript que usam a API Acrobat / JavaScript. Talvez possa ser útil na sua situação.

Um diagrama é usado para estabelecer as relações de entrada e saída dos elementos da rede e duas vistas de formulário das anotações. Com base nas visualizações de diagrama e formulário, é possível criar sistematicamente programas JavaScript para aplicativos de formulário PDF. Assim, “lendo” o código fonte é reduzido para verificar se ele corresponde às especificações: o diagrama e duas visualizações de formulário.

A implementação do meu software utiliza construtores e protótipos. Se o desempenho se tornar um problema, a substituição de protótipos por membros da instância poderá melhorar o desempenho à custa de mais uso de memória. Matrizes também são usadas. Se o desempenho se tornar um problema, as referências diretas serão usadas.

Algumas das propriedades são criadas usando eval; para objetos com muitas propriedades, isso reduziria a quantidade de código no arquivo de origem - e a quantidade de digitação do programador.

Ainda é possível e recomendado escrever JavaScript da maneira OOP com a qual você está acostumado. Aqui está um bom livro que aborda os padrões de design mais importantes em JavaScript.

https://addyosmani.com/resources/essentialjsdesignpatterns/book/

Existem muitas estruturas JavaScript por aí também, onde o objetivo principal é poder dividir o código em diferentes arquivos e módulos. Se a estrutura específica em que você está trabalhando exige que você tenha todo o seu código em um arquivo, você deve definitivamente procurar mudar.