Come strutturare i grandi moduli Node.JS

2

Sto lavorando a un progetto Node.JS piuttosto ampio con diverse migliaia di righe di codice. Non è una homepage, ma si comporta più come un server delle applicazioni generico configurabile. Come tale porta alcune parti che sono utili nella maggior parte dei progetti che faccio.

Il problema è che ho facilmente perso la visione d'insieme nei moduli principali. Così ho fatto un po 'di ricerche e ho trovato una struttura interessante basata su strutture di file C ++ Header / Code. Voglio sapere se questa struttura è buona a lungo termine (manutenibilità, testabilità, estensibilità), come può essere migliorata e se esiste già un (migliore) metodo "standard" per fare la strutturazione che non ho trovato.

La struttura ha tre tipi di file, dove xxx è il nome del modulo e yyy è il nome del metodo.

  • xxx.h.js: il file "header", che contiene le dichiarazioni di classe e metodo
  • xxx.yyy.c.js: i file "codice", che contengono un metodo ciascuno (e possibilmente funzioni di supporto locali)
  • index-xxx.js: la colla e il file principale per il modulo

Mi piacerebbe strutturare tutti i miei sotto-moduli come questo e poi usare un meccanismo di caricamento per caricare tutti i moduli, namespace e infine usarli globalmente.

Ecco un esempio:

package.json

{
    "name": "Foo",
    "version": "1.0.0",
    "description": "Does something in the core system",
    "author": "Marco Alka",
    "main": "index-foo.js"
}

// index-foo.js
'use strict';

// return class
module.exports = require('./foo.h.js');

// overwrite definitions with declarations
// this part can and most probably will be done generically by my module loader. I write it down for easier overview.
require('./src/foo.bar.c.js');
require('./src/foo.baz.c.js');

// foo.h.js
'use strict';

/**
 * Easy-to-read interface/class
 * No obstructive code in my way
 */
module.exports = class Foo {

  constructor() {}

  /**
   * Put comments here
   */
  bar() { throw 'Not Implemented'; }

  /**
   * More comments for methods
   * See how the method declarations+documentations nicely dominate the file?
   */
  baz() { throw 'Not Implemented'; }
}

// src/foo.bar.c.js
'use strict';

// include header
var h = require('../foo.h.js');

// implement method Foo::bar
h.prototype.bar = function () {

  console.log('Foo.bar');
}

// src/foo.baz.c.js
'use strict';

// include header
var h = require('../foo.h.js');

// implement method Foo::bar
h.prototype.baz = function () {

  console.log('Foo.baz');
}


Esempio su come utilizzare il tutto dalla cartella principale

'use strict';

// later on a module loader will be used which loads the folder as module instead of the index file directly
var F = require('./index-foo.js');

// make object
var foo = new F();

// call method
foo.bar();

Output in console: Foo.bar\n

    
posta Marco Alka 18.01.2016 - 15:00
fonte

1 risposta

1

Sono un principiante e sono abbastanza sicuro che questa è una risposta basata sull'opinione che è davvero al di fuori dell'ambito del consiglio di amministrazione. Con ciò, ecco la mia esperienza pratica:

  • Non ci sono modi implicitamente cattivi per strutturare il codice, a patto che la struttura possa essere descritta semplicemente.
  • L'unica cosa negativa di una cattiva struttura del codice è la mancanza di disciplina: se segui costantemente la struttura durante lo sviluppo, allora tu o chiunque altro che modifica il tuo codice dovrebbe essere in grado di discernere rapidamente il contesto.
  • Anche se sei l'unica persona del tuo team di sviluppo (che è come te), usa Git o qualche altro tipo di repository con spiegazioni valide per ciò che hai cambiato e perché.

È stata la mia esperienza che le strutture di codice non sono di solito i responsabili di rendere le cose difficili da gestire. È un'architettura e una documentazione logica. Se hai una buona architettura logica che definisce chiaramente la modularità delle funzionalità e documenti ciò che hai fatto, sarà un investimento che paga.

    
risposta data 27.01.2016 - 01:12
fonte

Leggi altre domande sui tag