背景

• AI時代にはコードをたくさん作るのは簡単になった
• しかし管理やCheckが大変になった
• また作れるものが多すぎて複雑怪奇になった
• そこで統一したパッケージ名の管理をすることにした
• ここでいうパッケージとは、NodeでいうPackageやJavaでいうModule、PythonでいうLibに違う概念
• つまり、一つの独立したコードのrepositoryということ
• いわゆるモノリポの管理をする時の管理法になる
• そのイメージとしてはJavaのMavenのマルチモジュールを参考にしている

Package名の規則

パッケージ名のフォーマットは以下にしている:

{repository_name}-{category_name}-{package_name}-{application_name}-{version}

つまり、5段階に分けて名前空間を区切っている。

Package名の5つの要素

要素にはそれぞれ次の意味がある。

• {repository_name}
  • パッケージ名のprefixとなっている
  • これは必ず共通して同じのをつける
• category_name
  • そのパッケージの目的を表すとグループ名として使う
  • I/Fを合わせるのが目的
• package_name
  • モノリポでいうリポジトリ名
• application_name
  • 例えば、trainingやapi_serverやdata_viewerなど
  • 実際のアプリケーション単位に落とし込んだ名前になる
• version
  • いわゆるバージョンv1、v2などをつける

それぞれsnakeケースで記する。

パッケージ名の理由

• 前述のように名前空間を切っている理由は、repository_nameで前方一致が効くので検索しやすくなるため
• また、このように粗結合にすると、いらない時に入れ替えたり、削除したりすることも容易になる
• 特に、何が性能がいいかは前提や実験方法にもよるので、比較するためには複数の手段が必要になる

Package CategoryのCommonパターン

• パッケージ全体の依存としてImportしたり結合する場合は、共通で使われる依存のVersion合わせが必要になる
• その場合は、Mavenで言うところの、BOM（Bill of Materials）パターンがいい
• つまり、共通して必要な依存はcommonカテゴリのパッケージをImportして使う事で衝突を避ける

Package CategoryのProtocolのパターン

• http serverなどのように粗結合につなげる場合はBOMは不要になる
• IPCの場合は相互の依存関係になるので、adapter系のpackageがあると便利
• その場合は、カテゴリーのI/Fに従ったコードになる

Package名の例

例としては以下のようなフォルダ構成になる。

1
2
3
4
5
6
7
8

xxx-lib
  xxx-lib-common-app-v1
  xxx-lib-preprocessing-image-v1
  xxx-lib-preprocessing-image-v2
  xxx-lib-preprocessing-image_train-v1
  xxx-lib-app-main_server-v1
  xxx-lib-app-main_server-v2
  xxx-lib-app-reverse_proxy-v1

まとめ

• 複数のシステムを混ぜない
• システムはマルチパッケージのモノリポにする
• 依存はあっても、Mixはしない
• 粗結合かつ1タスクでパッケージを切る