Packwerk Episode IIによるRuby on Railsのモジュール化

パッケージとしてのアプリケーション

アプリケーションをモジュール化するアプローチは、アプリケーション全体をパッケージに変換することである。

構造を作る

まず app/パッケージ フォルダにすべてのパッケージを配置する。パッケージを分離するために、すべての MVCコンセプト を1つのフォルダにまとめる。を取る。 コードトリアージ プロジェクト 例として、次の図のようなものがある。

サーバーを実行しようとすると、定数を見つけるのに失敗する。そのため、設定行を application.rb

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

アプリケーションは動作しますが、ビューを見つけることができません。 application_controller.rb

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

パッケージの作成

構造の準備ができたので、パッケージの作成に取りかかろう。そのために必要なのはpackage.yml を以下のような設定で各フォルダに追加する：

enforce_privacy: false
enforce_dependencies: true

プライバシーを使えば、パッケージのすべての定数を分離して、パブリックAPIで作業することができる。パブリックな定数を公開するためには、例えば次のように定数を追加する必要がある。 packages/users/app/public.今のところ、この設定を 擬似.

強制依存 はパッケージの依存関係を強制し、すべての定数参照をチェックする。依存関係が明示的に定義されていない場合は、境界違反となる。

パッケージシステムの検証

パックワーク は、有効なパッケージシステムを持つために従うべき基準を確立した。我々は パックワーク検証 私たちのコンソールで。

 これでフォルダ構造がチェックされる、 パッケージ構成とパスキャッシュのオートロードを行う。

今現在、我々のアプリケーションは有効ではない。packwerk.yml. そのためには、足りないパスを追加するだけでいい。

# packwerk.yml

load_paths：
.
.
.

# ユーザー
- app/packages/users/controllers
- app/packages/users/models
- app/packages/users/package.yml
- app/packages/users/views

この時点で、アプリケーションの境界違反をチェックする準備ができた。違反をチェックするにはpackwerk update-deprecations を生成する。 deprecated_references.yml ファイルを作成する。どのファイルにも、パッケージ名、違反のタイプ、ファイルパスがある。これらの情報があれば、どこで違反が起きているかがわかり、それを解決するための決断を下すことができる。

# deprecated_references.yml

.
.
.

app/packages/repos：
  "::Repo"：
    violations.repos.レポ"::レポ
    - 依存関係
    ファイル
    - app/packages/users/models/user.rb

例として、生成された情報のすべての部分を説明する。
によって パックワーク.

– app/packages/repos  - パッケージで、定数違反は
を見つけた。

– :レポ  - 違反した定数を含むファイルへのパス。

– 従属  - 依存かプライバシーのいずれかを侵害する。

– app/packages/users/models/user.rb  - 違反した定数を含むファイルへのパス。

このセクションの最後のステップとして、新しく生成されたファイルパスを パックワークlを実行し、バリデーションを再実行する。

依存関係の可視化

package.ymlのすべての情報と deprecated_references.ymlそうすれば
依存関係のグラフを可視化する。そのためには、別のgemを追加する必要がある。 ポッキー.

ランニングレーキ ポッキー：生成 というファイルを生成する。 packwerk.png ここで、依存関係の最初のグラフを視覚化することができる。

すべてのパッケージが定義されると、グラフは次のようになる。

依存関係はすでに存在するが、それが受け入れられるとは限らない。 パックワーク.へ
依存関係を受け入れるには、依存関係の設定を package.yml
すべてのパッケージに私たちは次のことに重点を置いています。 メールビルダー 循環依存性のないパッケージだからだ。特筆すべきは パックワーク は、循環的な依存関係を受け入れさせてはくれない。

# app/packages/mail_builders/package.yml

``ruby
enforce_privacy: false
enforce_dependencies: true
依存関係
- app/packages/docs
- app/packages/issues
- app/packages/repos

この設定を追加した後 ポッキー は、受け入れられた依存関係を緑色で着色する。

削除することができる deprecated_references.yml より app/packages/mail_builders そして
packwerk update-deprecations をもう一度実行します。すべての
違反が修正された。重要なことは、たとえ依存関係が認められているグラフでなくても

パックワークによるRuby on Railsのモジュール化 依存関係を受け入れることで、アプリケーションは以前と同じように動作する。
決断を下し、リファクタリングするための情報だ。

循環的な依存関係を取り除く

以前のグラフでは、多くの循環依存関係があり、それを何とか解決する必要があった。それを解決するためのさまざまな戦略がある：

- 何もしない、

- 依存関係を受け入れる、パッケージをマージする、

- 移動 コード パッケージ間

- 機能を複製する、 

- 依存性注入または型付けを伴う依存性注入を実行する。

ここでひとつ問題になるのは、適切なリファクタリングを行うためには、コードベースを知る必要があるということだ。私はこのプロジェクトのコードベースを例として取り上げたので、あまり詳しくはないが、現実的な理由から、最初の戦略である「何もしない」で行くことにする。リファクタリングの大部分を回避するとしても、依存関係については ルート パッケージで提供される。

ルートパッケージには Railsフレームワークrailsは、私たちが継承しているすべてのクラスが一緒に動作するようにします。そこで、循環依存関係を解決するために、以下の手順でrailsという新しいパッケージを作成する：

1. アプリのすべてのファイルとフォルダを app/packages/rails.
2. を作成する。package.yml を、以前のパッケージと同じコンフィギュレーションで使用する。
3. 新しいファイルパスをすべて packwerk.yml.
4. 追加 app/packages/rails を、他のパッケージからの依存として使用する。

パッケージを作成すると、再構築可能なファイルがたくさんあることに気づくだろう。すべてを対応するパッケージに移動して
依存関係は新しい構造になり、グラフはすっきりする。

ルートパッケージから依存関係を削除する

これでグラフの見栄えはかなり良くなった。ルートパッケージの依存関係をすべて削除できれば最高だ。ルートパッケージのdeprecated_references.ymlをチェックしてみると、そのほとんどが テスト , lib/tasks , デブ そして コンフィグ
フォルダを作成する。これらの依存関係を解決するために、各パッケージの中にtestフォルダを作成する。以下のようなものを用意する。 app/packages/users/test.次に、以下を除外する。 lib/tasks , デブ そして コンフィグの他のフォルダの中にある。 パックワーク というのも、これらの依存関係は我々の分析ではあまり重要ではなく、簡単に解決する方法がないからだ。私たちの packwerk.yml.

を除外する：
- "{bin,node_modules,script,tmp,vendor,lib,db,config,perf_scripts}/**/*"
- "lib/tasks/**/*.rake"

ルートパッケージからすべてのテストを移動し、分析からフォルダを除外すると、ルート依存関係のない新しいグラフができあがる。

見ての通り、まだユーザー , レポ そして 諸注意 .解決には至らなかったが、私たちは今、重要な情報を持っている。我々はすべての チーム そのようなパッケージの1つに変更を加える場合、おそらく循環依存のパッケージにも変更を加えなければならないだろう。一方、あるチームが github_fetchers どのようなパッケージがあるのかを知ること。
一瞬一瞬の変化に影響される。

プロジェクトの最終結果はこちら これ.

次のステップ

次のステップとして、すべてのパッケージで一定のプライバシーを強制し、他のパッケージからアクセス可能なパブリックAPIのみを公開することもできる。APIをどこに配置するかは package.yml.

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

結論

パックワーク その情報をもとに、チームのワークフローを改善するための決断を下すことができます。このプロセスは長く、多くのコンフィギュレーションが必要なように思えるが、常にそうである必要はない。アプリケーションに追加された新しいコードに対してのみパッケージを作成し始め、徐々にモジュール化していけばいいのだ。これで、漸進的モジュール化について話し始めることができる。 「これにより、より良いアプリケーション構造に向けて、徐々に拡大するサポートシステムを構築することができる」。

情報源

1. Ruby on Railsの漸進的モジュール化 - ステファン・ハーゲマン
2. PackwerkでRailsアプリにモジュール性を持たせる
3. Packwerk Github
4. 記事のソースコード

続きを読む

GraphQL Ruby。パフォーマンスについては？

レールおよびその他の輸送手段

TMUX、Vim、Fzf + RipgrepによるRails開発