背景

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

Package名の規則

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

<repository_name>-[category_name]-<package_name>-[application_name]-[version]

• <>は必須の要素、[]はオプショナルな要素を表す
• つまりrepository_nameとpackage_nameは必須、category_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ケースで記する。

要素名の単数形 vs 複数形

• パッケージ名の各要素を単数にするか複数にするかは、言語やライブラリでも統一されておらず自由
• Java: java.util（複数）、java.lang（単数）、java.util.function（単数）のように、標準ライブラリ内でも混在
• JS: Node.jsの標準モジュールもutil・path・streamなど単数が大半だが、eventsのように複数のものもある
• どちらのケースも厳格な慣習はなく、チームやプロジェクト内で一貫していれば単数/複数どちらを選んでも問題ない

パッケージ名の理由

• 前述のように名前空間を切っている理由は、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
 9
10

xxx-lib
  .git
  README.md
  xxx-lib-common-base-util-v1
  xxx-lib-preprocessing-image-train-v1
  xxx-lib-preprocessing-image-model-v1
  xxx-lib-preprocessing-image-server-v1
  xxx-lib-server-client-app-v1
  xxx-lib-server-client-app-v2
  xxx-lib-server-proxy-docker-v1

• xxx-libはrepository_name
• ここだけケバブケースで、それ以外の要素はsnakeケース

まとめ

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