Come dovrebbero essere strutturate le grandi applicazioni JavaScript?

10

Recentemente ho mostrato alcuni plug-in JavaScript scritti per OBIEE Mobile App Developer, oltre ad alcune librerie personalizzate per vari progetti.

Venendo da un background OOP, sono un po 'confuso riguardo la struttura di questi progetti. Vedo file con migliaia di righe lunghe. Sono abituato a suddividere le cose in file e classi ma capisco che questo è un framework diverso - per esempio, la dimensione del file è un problema - ma ci deve essere un modo migliore per fare tutto?

La lunghezza degli script influenza non solo la leggibilità e la maintanabilità, ma anche la comprensione generale di una persona su come funziona il programma.

Come sono strutturate le applicazioni di grandi dimensioni? Qualsiasi schema di progettazione OOP generale per questo?

    
posta turnip 13.07.2016 - 12:02
fonte

6 risposte

7

Se non hai familiarità con i pattern JavaScript, posso dire che molte applicazioni e librerie di grandi dimensioni utilizzano Modulo rivelatore Modello , ma ci sono molti altri modelli che puoi utilizzare in base alle tue esigenze.

Tuttavia, il Revealing Module Pattern dovrebbe darti un buon modo per dividere file di grandi dimensioni e organizzarli logicamente; Tuttavia, quando lavori con modelli di progettazione in JavaScript, tieni presente che questo può diventare molto confuso. Prova a utilizzare questo , nuovo , prototipo , .call() e .apply() saggiamente.

Mentre lavori su progetti di grandi dimensioni, questi possono essere utili anche:

  • Se possibile, passa a TypeScript o ES6.
  • Scrivi il codice Modulare . Esistono vari modi e librerie di terze parti, ma nessuna è meglio di niente.
  • Utilizza un Runner attività / Sistema di costruzione per automatizzare le attività.
  • Leggi di Modelli di design . Questo potrebbe essere un buon inizio. Come ho detto sopra, il Revealing Module Pattern è molto utile, specialmente se pensi di aver bisogno di tempo per dominare tutti i modelli popolari.
  • Scrivi Test delle unità . Lavorare con un linguaggio dinamico può essere più impegnativo. Testare le parti cruciali della tua applicazione può far risparmiare molto tempo.
  • Utilizza un IDE o Editor di testo che può aiutarti a scrivere codice e catturare bug. WebStorm è una buona scelta. Testo sublime anche.
  • Se il tuo IDE non offre un debugger, prova a controllare il debugger del tuo browser preferito.
  • Usa le librerie. A seconda della natura del progetto, prova ad utilizzare il miglior codice di terze parti che riesci a trovare. Se stai scrivendo un'applicazione web, dai un'occhiata a Angular , React e al vecchio backbone.js . Se stai scrivendo un'applicazione Node.js, prenditi il tuo tempo per cercare nel repository NPM . Sarai sorpreso di quanti pacchetti stanno già facendo ciò che stavi per fare.
  • Anche se sei l'unica persona che sta lavorando al progetto, usa ancora un sistema di controllo della versione come Git e segui uno standard di codifica che non è troppo severo e supponente ma fornisce comunque una buona linea guida che i tuoi compagni di squadra sarebbero anche felici di seguire.
  • Anche se opti per TypeScript o ES6, pur comprendendo l'OOP di classe JavaScript di JavaScript, l' Prototypal OOP può essere utile, specialmente durante il debug.
risposta data 18.07.2016 - 11:18
fonte
1

Sono uno sviluppatore C ++ e ho iniziato a fare sviluppo web ultimamente. Sto trasferendo una grande app desktop nell'ambiente web. Strutturo il mio codice JavaScript esattamente come ho strutturato il codice C ++, usando gli stessi pattern. Ho circa 25-30 file in tutto ma alla fine li ridurrò a 3-5 bastonando come appropriato e li minimizzerò tutti.

Per me, è solo il linguaggio che è cambiato, nel bene e nel male, ma non nel paradigma. JavaScript, nonostante i suoi difetti e le sue frustrazioni, è una bella miscela di stile funzionale e OOP. Le cose hanno funzionato bene finora.

Infine, una cosa che ho capito subito è che JavaScript permette di scrivere un codice molto più conciso del C ++, quindi a volte avere un gran numero di LOC proveniente da un linguaggio non JS potrebbe essere dovuto al vecchio modo di fare le cose. Una volta affrontata questa cosa, non vedo nulla che dovrebbe essere davvero diverso. Il design e gli algoritmi sono in fin dei conti indipendenti dal linguaggio.

    
risposta data 16.07.2016 - 21:20
fonte
0

Diversamente varia da progetto a progetto, naturalmente, ma la pratica generalmente accettata è che, per cose che sono pensate per funzionare come librerie o moduli, per metterli in un unico grande file e usare l'incapsulamento per impedire il suo interno ( interfaccia "privata") da fuoriuscire verso l'esterno. È anche utile per gli sviluppatori che desiderano utilizzare la libreria / modulo - un file da aggiungere alla configurazione dell'applicazione o allo snippet di intestazione invece di un'intera gerarchia di cartelle e file da copiare e incollare. Riflette anche il fatto che, con la minimizzazione e il raggruppamento, in un sito di produzione sarebbe molto probabilmente tutto combinato in un unico file per ridurre il numero di richieste HTTP.

Il tuo codice applicazione non ha bisogno di seguire questa pratica e probabilmente non dovrebbe. Poiché l'app è l'unica che la utilizza, devi solo aggiungere i file una volta sola e probabilmente puoi contare sulla piattaforma per gestire la minimizzazione e il raggruppamento per te.

    
risposta data 15.07.2016 - 17:17
fonte
0

Quando si lavora sul codice, i diversi componenti sono tipicamente suddivisi in moduli, ognuno dei quali in genere implementa una singola classe, e ognuno vive in un file separato. Durante la produzione, questi file vengono poi raggruppati in un unico file (da cui le migliaia di righe di codice che stai visualizzando) usando qualcosa come Browserify ( link ) o RequireJS per ridurre il numero di richieste HTTP, ma anche per garantire che le dipendenze siano caricate nell'ordine corretto

Per quanto riguarda il modo in cui sono implementate le classi per questi moduli, è un po 'diverso da OOP nella meccanica sottostante, ma non così diverso sulla superficie. ES6 ha persino introdotto la parola chiave class , quindi dovrebbe sembrare abbastanza familiare. Questo articolo su MDN è utile per iniziare: link

    
risposta data 17.07.2016 - 16:11
fonte
0

Uso gli elementi di rete e le annotazioni (di Petri) per organizzare o "strutturare" il software per le mie applicazioni di modulo PDF: programmi JavaScript che utilizzano l'API di Acrobat / JavaScript. Forse può essere utile nella tua situazione.

Un diagramma è usato per stabilire le relazioni input-output di elementi di rete e due viste di forma delle annotazioni. Sulla base delle viste del diagramma e del modulo è possibile creare sistematicamente programmi JavaScript per le applicazioni del modulo PDF. Quindi "leggere" il codice sorgente è ridotto a verificare che corrisponda alle specifiche: il diagramma e due viste del modulo.

L'implementazione del mio software utilizza costruttori e prototipi. Se le prestazioni diventano un problema, la sostituzione dei prototipi con i membri di istanza può migliorare le prestazioni a scapito di un maggiore utilizzo della memoria. Vengono anche utilizzati gli array. Se le prestazioni diventano un problema, vengono utilizzati i riferimenti diretti.

Alcune proprietà sono create usando eval; per oggetti con molte proprietà questo ridurrebbe la quantità di codice nel file sorgente e ridurrebbe la quantità di digitazione da parte del programmatore.

    
risposta data 18.07.2016 - 07:08
fonte
0

È ancora possibile e consigliato scrivere JavaScript nel modo OOP a cui sei abituato. Ecco un buon libro che ha attraversato i modelli di progettazione più importanti in JavaScript.

link

Ci sono molti framework JavaScript anche là dove l'obiettivo principale è quello di essere in grado di dividere il codice in diversi file e moduli. Se il particolare framework in cui stai lavorando richiede di avere tutto il tuo codice in un file, allora dovresti assolutamente cercare di passare.

    
risposta data 19.07.2016 - 14:49
fonte

Leggi altre domande sui tag