Ruby on Rails modulare con Packwerk Episode II

Nicolas Nisoria

Nella seconda puntata della nostra modularizzazione dell'Ruby on Rails con Packwerk esamineremo da vicino il concetto di applicazione come pacchetto.

Applicazione come pacchetto

L'approccio per modularizzare la nostra applicazione consiste nel convertire l'intera applicazione in un pacchetto.

Creare la struttura

Per prima cosa, è necessario creare app/pacchetti in cui verranno inseriti tutti i nostri pacchetti. Per isolare i nostri pacchetti, dobbiamo separare tutti i pacchetti da Concetto MVC in una cartella. Prendendo il CodiceTriage progetto come esempio avremo qualcosa di simile alla seguente immagine.

Se proviamo a eseguire il server, non riuscirà a trovare le costanti. Ecco perché dobbiamo aggiungere una riga di configurazione al nostro file applicazione.rb

config.paths.add 'app/packages', glob: '*/{*,*/concerns}', eager_load:true

Ora l'applicazione funziona, ma non riesce a trovare le viste, quindi dobbiamo aggiungere un'altra riga di configurazione al nostro file application_controller.rb

append_view_path(Dir.glob(Rails.root.join('app/packages/*/views'))

Creare i pacchetti

La nostra struttura è pronta, quindi ora possiamo iniziare a creare i pacchetti. Per farlo, dobbiamo solo aggiungere un elementopacchetto.yml in ogni cartella con la seguente configurazione:

enforce_privacy: false
applica_dipendenze: true

applicare_privacyci dà la possibilità di isolare tutte le costanti del pacchetto e di lavorare con un'API pubblica. Per esporre le costanti pubbliche, dobbiamo aggiungere le costanti, ad esempio, in packages/users/app/public.Per ora impostiamo questa configurazione a falso.

applicare_dipendenze imporrà la dipendenza di un pacchetto e controllerà tutti i riferimenti alle costanti. Se una dipendenza non è definita esplicitamente, sarà una violazione del limite.

Convalida del sistema di pacchetti

Packwerk ha stabilito un criterio da seguire per avere un sistema di pacchetti valido. Possiamo iniziare a eseguire packwerk convalidare nella nostra console.

In questo modo si controllerà la struttura delle cartelle, configurazione del pacchettoe la cache dei percorsi con caricamento automatico.

In questo momento, la nostra applicazione non è valida e dobbiamo correggere i percorsi di caricamento inpackwerk.yml. A tal fine, è sufficiente aggiungere i percorsi mancanti.

# packwerk.yml

load_paths:
.
.
.

# Utenti
- app/packages/utenti/controllori
- app/pacchetti/utenti/modelli
- app/packages/users/package.yml
- app/packages/users/views

A questo punto, siamo pronti a verificare le violazioni dei limiti nella nostra applicazione. Per verificare le violazioni, possiamo eseguirepackwerk aggiornamento-deprecazioni , questo comando genererà riferimenti_deprecati.yml per ogni pacchetto. In ogni file si trovano il nome del pacchetto, il tipo di violazione e il percorso del file. Con tutte queste informazioni sappiamo dove si verifica la violazione e possiamo prendere una decisione per risolverla.

# deprecated_references.yml

.
.
.

app/packages/repos:
  "::Repo":
    violazioni:
    - dipendenza
    file:
    - app/packages/users/models/user.rb

Riprendendo l'esempio, descriveremo ogni parte dell'informazione generata
da Packwerk.

– app/pacchetti/repos - dove la violazione della costante è
trovato.

– ::Repo - percorso del file contenente la costante violata.

– dipendenza - un tipo di violazione, sia della dipendenza che della privacy.

– app/packages/users/models/user.rb - percorso del file contenente la costante violata.

Come ultimo passo di questa sezione, non dimenticate di aggiungere i nuovi percorsi dei file generati a packwerk.yml ed eseguire nuovamente le convalide.

Visualizzazione delle dipendenze

Con tutte le informazioni contenute nel file package.yml e nel file riferimenti_deprecati.ymlpossiamo quindi
visualizzare un grafico delle dipendenze. Per farlo, dobbiamo aggiungere un'altra gemma, in questo caso useremo Pocky.

Rastrello in corsa pocky:generare genereremo un file chiamato packwerk.png dove possiamo visualizzare il nostro primo grafico delle dipendenze.

Con tutti i pacchetti definiti, il nostro grafico avrà questo aspetto.

Le dipendenze esistono già, ma non significa che siano accettate da Packwerk. A
accettare una dipendenza, dobbiamo aggiungere la configurazione delle dipendenze al file pacchetto.yml
in ogni pacchetto. Ci concentreremo su costruttori_di_posta poiché si tratta di un pacchetto senza dipendenza circolare. Vale la pena ricordare che Packwerk non ci permette di accettare dipendenze circolari.

# app/packages/mail_builders/package.yml

``ruby
enforce_privacy: false
enforce_dependencies: true
dipendenze:
- app/pacchetti/docs
- app/pacchetti/problemi
- app/pacchetti/repos

Dopo aver aggiunto questa configurazione, Pocky colorerà di verde le dipendenze accettate.

Possiamo eliminare riferimenti_deprecati.yml da app/packages/mail_builders ed eseguire
packwerk aggiornamento-deprecazioni di nuovo. Il file non verrà generato di nuovo, poiché tutti i file
sono state corrette per questo pacchetto. È importante menzionare che, anche se non si tratta di Grafico con dipendenze accettate

Ruby on Rails modulare con Packwerk accettare le dipendenze la nostra applicazione continuerà a funzionare come prima, ma ora abbiamo più
informazioni per prendere decisioni e rifattorizzare.

Rimuovere le dipendenze circolari

Nel nostro grafico precedente, avevamo molte dipendenze circolari che dovevano essere risolte in qualche modo. Abbiamo diverse strategie per farlo:

- Non fare nulla,

- Accettare le dipendenze, unire i pacchetti,

- Muoversi codice tra i pacchetti,

- Duplicare una funzionalità,

- Eseguire l'iniezione di dipendenza o l'iniezione di dipendenza con tipizzazione.

Un problema è che per fare un refactor corretto, dobbiamo conoscere la base di codice. Non ho molta familiarità con la base di codice di questo progetto, dato che l'ho preso come esempio, quindi per ragioni pratiche sceglieremo la prima strategia, non fare nulla. Anche se eviteremo la maggior parte delle operazioni di refactoring, vogliamo lavorare sulle dipendenze nel radice pacchetto.

Il pacchetto radice contiene tutto il collante del pacchetto Struttura RailsTutte le classi da cui ereditiamo e che facciamo funzionare insieme. Quindi, per risolvere il problema delle dipendenze circolari, creeremo un nuovo pacchetto chiamato rails nei seguenti passi:

Spostare tutti i file e le cartelle dell'applicazione dall'app a app/pacchetti/rails.
Creare unpacchetto.yml per il pacchetto con la stessa configurazione dei pacchetti precedenti.
Aggiungete tutti i nuovi percorsi dei file a packwerk.yml.
Aggiungi app/pacchetti/rails come dipendenza dal resto dei pacchetti.

Una volta creato il pacchetto, inizieremo a notare molti file che possono essere ristrutturati. Dopo aver spostato tutto nel pacchetto corrispondente e dopo aver accettato
dipendenze, avremo una nuova struttura e un grafo più pulito.

Struttura del pacchetto con pacchetto di binari

Grafico senza dipendenze circolari dalla radice

Rimuovere le dipendenze dal pacchetto principale

Ora il nostro grafico ha un aspetto migliore, sarebbe bello se potessimo rimuovere tutte le dipendenze dal pacchetto principale. Se controlliamo deprecated_references.yml nel pacchetto radice, noteremo che la maggior parte di esse proviene da test , lib/tasks , db e configurazione
cartella. Per risolvere queste dipendenze, creeremo una cartella di test all'interno di ogni pacchetto. Avendo qualcosa come app/pacchetti/utenti/test. Successivamente, escluderemo lib/tasks , db e configurazionetra le altre cartelle di Packwerk poiché queste dipendenze non sono importanti per la nostra analisi e non abbiamo un modo semplice per risolverle. Aggiungeremo quanto segue al nostro file packwerk.yml.

escludere:
- "{bin,node_modules,script,tmp,vendor,lib,db,config,perf_scripts}/**/*"
- "lib/tasks/**/*.rake"

Dopo aver spostato tutti i test dal pacchetto root ed escluso le cartelle dall'analisi, avremo un nuovo grafico senza le dipendenze da root.

Come possiamo vedere, abbiamo ancora dipendenze circolari inutenti , repos , e documenti . Anche se non li abbiamo risolti, ora abbiamo informazioni importanti da trasmettere. Sappiamo che ogni squadra che esegue modifiche in uno di questi pacchetti dovrà probabilmente eseguire modifiche nei pacchetti con la dipendenza circolare. D'altra parte, sappiamo che un team può lavorare su github_fetchers esclusivamente, sapendo quali sono i pacchetti
che si fa influenzare dai cambiamenti in ogni momento.

Potete trovare il risultato finale del progetto qui.

Passo successivo

Come passo successivo, si potrebbe imporre una privacy costante in ogni pacchetto ed esporre solo l'API pubblica che sarà accessibile da altri pacchetti. Si può facilmente configurare la posizione dell'API in pacchetto.yml.

enforce_privacy: true
enforce_dependencies: true
public_path: my/custom/path/

Conclusioni

Packwerk ci fornisce molte informazioni sulla nostra applicazione e con queste informazioni possiamo prendere decisioni per migliorare il flusso di lavoro dei nostri team. Anche se il processo sembra essere lungo e con molte configurazioni, non deve essere sempre così. Possiamo iniziare a creare pacchetti solo per il nuovo codice aggiunto alla nostra applicazione e poi modulare gradualmente. Ora possiamo iniziare a parlare di modularizzazione graduale, un concetto introdotto da Stephan Hagemann. "Possiamo, per la prima volta, decidere di iniziare a modularizzare una porzione di codice in modo aspirazionale... Questo ci permette di creare un sistema di supporto in graduale espansione verso una migliore struttura dell'applicazione".