各コンポーネントの命名についての指摘と提案

[zazaboon]

コンポーネントの命名に関して提案があり、issueを作成させていただきました。
issueの作成は初めてなので、何か不備があればご指摘いただけると幸いです。

現在のコンポーネントの命名は、機能に関連しない固有名詞が非常に多く、プロジェクトに精通していない人間には非常にわかりにくいです。
これは、このプロジェクトの発展に大きく影響すると思います。

命名が分かりにくいことによる具体的な問題として、環境構築やエラーが起こった際の対応などで、どの名前がどの機能に対応するか、都度都度確認しなければならず、その対処にかかる時間が余計に増えてしまうことが挙げられます。
また、機能に関する議論をしようと思ったときにも、これは妨げになります。
現状の命名では、このプロジェクトが実用を意識していないように見え、実際に実用に耐えられるものかどうかに関して、少なからず心証を損ねます。

私自身、国産の技術を心から応援したいと思っていますが、現在の命名方法では全面的な支持が難しいと感じています。
プロジェクトのさらなる普及や成長を考えると、命名方法の見直しは欠かせないと考えます。

もちろん、すぐにすべてを変更するのは難しいかと思いますが、tsurugi-<機能名>のような命名に段階的に移行することを検討していただけると幸いです。

[okachimachiorz]

まずはIssueの書き込みありがとうございます。

えっと、コンポーネントの命名の件ですが、基本的には機能と名前を関連付けるというのは、「現在は」わかりやすいというメリットよりも以下のデメリットの方が大きいと思っています。

・機能とコンポーネントの関係は今後もいろいろ調整が入る
現状の機能構成がベストだと思っていませんし、今後様々な機能が追加・実装・変更されると思います。同じ機能ですが、実装が異なるコンポーネントが複数出てくることも想定しています。また、特定の機能の肥大化から特定コンポーネントから切り出し、または併合も出てくると思います。実際のTsurugiの開発途中では、ままありました。
　この場合、機能とコンポーネント名を関連付けた場合、機能を変更するたびにコンポーネントの名前を変更せざるえない可能性もあり、命名を変更するコンポーネント以外にも影響がでます。これはちょっとコストがかかります。
　結局、機能とコンポーネント名を独立にさせるメリットの方が、今後の変更可能性を考えると現状では大きい気がします。

・書籍との連動
　Tsurugiは、戦略的に書籍化を行っています。要は「紙で印刷」ですね。時代錯誤も甚だしいとは思いますが、これは意図的です。国の金が入っている以上、まずTsurugiの利用対象は国内ユーザが最初のターゲットになります。また、Tsurugiの性格から言って、個人ではなく、企業・組織等々のユーザが対象になるでしょう。この場合、概ね、各組織の意思決定者（具体的には情報システム部部長・ないしは担当取締役/理事とか）に、どれだけTsurugiの情報を届けるか？が一つのカギになると思っています。

　んで、情報システム部部長さんはgithubのコードは読みません。でも、書籍はまだ可能性があります。また、たとえば現場の方がTsurugiを使いたい！と主張しても、上役で「なんだそれは」でお仕舞いです。このとき、書籍は援護射撃の武器になると思っています。ということで書籍とTsurugiは、ある程度連動しています。

書籍はコンポーネントの名前ベースで記述されており、コンポーネント名の変更は、書籍がすでに出版されている現在では、読むことが結構面倒になります。

なので、Tsurugiが結構枯れてきて、書籍も大幅にリバイズする、ような状況になれば、今の固定指示子的な役割をもつコンポーネント名もお役御免になると思います。

[zazaboon]

お忙しい中お返事ありがとうございます。

なるほど、そのような事情があるのですね。
こちらは閉じさせていただきます。
（慣れてないもので、運用的に間違っていればすみません…）