language-agnostic - プログラムの語彙をどのように維持していますか?

Question

それほど小さくないプログラムでは、エンティティがそれほど多くない場合、コードの読みやすさ、共通の用語を維持し、そうでなければチーム メンバー間の相互理解を向上させるために、プログラムの語彙を定義して維持する必要があります。

あなた (またはあなたの会社) は、このタスクにどのように対処していますか? どのような規律を持っていますか?

Answer 1

妥当な規模のほとんどのプロジェクトには、従うべき共通の規則と命名ガイドラインを指示するプログラミング/コーディング標準ドキュメントが必要です。

これを支援するもう 1 つの方法は、コード レビューです。明らかに、レビュアー間の調整が必要です (このドキュメントはそのためにも役立ちます)。コード レビューは、より環境に配慮した開発者と上級開発者を同じように軌道に乗せ、コーディング標準を実施する手段として機能するのに役立ちます。

Answer 2

@Ilya Ryzhenkov、

ほとんどの企業にはそのような慣習がないのではないかと思います:)私は数百万のLOCコードベースを持つそれほど小さな会社で働いたことがあり、（一般的なコーディングガイドライン以外に）ドキュメントがまったくありません。

私のプロジェクトの1つでは、アプリケーションドメインで使用される一般的な用語のシソーラスを維持し、コードレビュー中に使用しました。シソーラスに追加するエンティティ\用語を決定するために、.NETXMLドキュメントの差分を時々分析しました。シソーラスへの準拠を強制する唯一の手段は、コーディングガイドラインでした。

Wikiのアプローチは、誰も定期的に更新する必要がないため、適用できないことが判明しました:)

JetBrainsではどのような方法を使用しているのでしょうか。私はReflectorでReSharperのコードを調べましたが、エンティティの数と名前に驚いていました:)

Answer 3

私のチームは、この種の情報（コンベンション/語彙など）をウィキに保管しています。これにより、最新の状態に保ち、共有することが容易になります。

Answer 4

パッケージ/モジュールを論理グループに分割し、説明的で簡潔な名前を使用します。実際にカウンターなどである場合を除いて、一般的な名前は避けてください。関数または機能のグループの規則を作成し、それらに固執します。

Answer 5

ドメイン駆動設計は、プログラマーがドメイン語彙を受け入れることを奨励するため、ここで興味深いものです。その上、サービス、リポジトリ、ファクトリなどのよく知られた用語を使用してアプリケーションの一部を参照できるようにする設計規則がいくつかあります。

ドメイン語彙を組み合わせて、その上で技術的な慣例を使用することは、良い解決策になる可能性があります。