小さめのチームのコーディング設定に関して、どのようにして同じページに全員を集めますか？
コードベースのエンジニアが10人から50人いるとします。これらの種類のものについては、誰もが異なるpreferencesを持っています。
- フォルダ構造
- 命名規則（CSSクラス名、関数名、変数名など）
- テスト規約
- 式の場所（ファイル内で変数が定義される場所など）
- カプセル化（これはユーティリティ、クラスなどに入れる必要があります）
- 特定の式タイプを記述する方法
- 等.
誰もがやりたいことをすべてさせてしまうと、多くの対立が起こり、人々は怒ります。特定のスタイルガイドを適用すると、特定のユースケースを予測できなくなり、定型文が多くなります。 「リーダーシップ」が方向を選ぶなら、人々は取り残されたと感じます。
一般的に言えば、特定の設定セットをどのように決定しますか（つまり、フォルダー構造のディスカッションであるか、CSSの命名規則であるかは関係ありません）？
Mattの回答 は良いアドバイスを提供します（そして、質問に対するRobert Harveyのコメントも同様です）が、50人までのメンバーを乗せる方法についての質問に関してはどちらもIMHOが不完全です。 5人に同じ標準で作業してもらうための組織的な問題は、50人の管理者がいるときに直面する問題とはかなり異なります。
約20年前、私は新しいプロジェクトのために合計でおおよそ同じサイズのチームをいくつか持っていて、約6か月（！ ）。これは完全な障害ではありませんでしたが、コスト効率が悪いことは間違いありませんでした。これらの標準をさらに改善することは、後で実現するのが実際には困難でした。今日から振り返ると、そこではもっとうまくできたはずのことがいくつかわかります。
最大5〜6人の経験豊富な開発者の小さなチームから始めて、エコシステム、アーキテクチャ、およびシステムのコーディング標準のプロトタイプを作成するための反復のための時間を与えます。次に、スケールアップします。後でチームに参加する人は、すでに与えられた標準を採用する必要があります。彼らは改善のためのさらなる提案をもたらすかもしれませんが、「地面から」の完全な変更はありません-少なくとも、経営陣から賛同を得ることなしに。
50名のチームは大きすぎてすべてを「同じコードベースで」機能させることができません。通常、製品のさまざまな部品/コンポーネントのサブチームがあります。すべてのサブチームがまったく同じ基準に従っていると主張しないでください。自分で改善の余地を与えます。通信オーバーヘッドは通常それだけの価値はありません。開発者をあるサブチームから別のサブチームに移動する必要がある場合、開発者は通常、個々のサブチームの「標準のバリアント」にすぐに採用できます。このような状況では、すべてのコンポーネントを同じように内部で100％構造化するよりも、コンポーネント間に堅固なインターフェースを持つことが重要です。
標準化のために標準化しないでください。すべてに有効な「グローバル基準」を必要最小限に留めます。構築する必要がある実際に1つの一貫したシステムである場合、標準化する必要があるのは通常、フレームワーク/プログラミング言語/オペレーティングシステムの「エコシステム」、関連するグローバルフォルダー構造、関連するサーバーテクノロジー（データベース、Web、SCCS）です。 ）。しかし、 "変数はファイル内で定義される"、またはサブフォルダー構造の下位レベルから小さなサブチームへと、細部までこだわった詳細にしましょう。巨大なチームのためにそのようなことを標準化しようとすることは、通常、面倒の価値はありません。
ディスカッションの開始点として、1つ以上の公開されたコーディング標準ドキュメントを使用します。多くの大規模組織では、考えられるほとんどすべての言語とフレームワークについて、標準ドキュメントをWeb上で自由に利用できるようにしています。これらのドキュメントの一部をダウンロードして配布し、チームがレビューおよび検討できるようにします。これは、ドキュメントが単にディスカッションを容易にするためのものであり、チームの意見が求められていることを明確にします。次に、これらの標準文書を検討し、人々に特定のルールに対する賛成または反対の意見を述べ、どの標準を採用する価値があるかを決定する機会を与えるために、チームとして対面の会議をいくつか開催します。その過程で、開発者は必然的に、開始した公開済みの標準ドキュメントに含まれていないいくつかのルールを提案しますが、これも問題ありません。
ディスカッションを行い、コンセンサスの形成を目指し、特定のルールが論争のある場合は投票を行います（ルールを採用するかどうか、または特定の問題を個別の裁量に任せるかどうか、およびルールを採用する場合はそのルールで何をすべきかについての投票be）など。議論と意思決定プロセスが公正かつ公平な方法で行われる場合、全員が基準のすべてのルールに満足していなくても、尊重する十分な理由があるため、コンセンサスと賛同が達成されるべきです。標準を作成したプロセス。
紛争は人々の赦しが衝突するときに起こります。規則を適用する自動システムを使用することで、これを回避できます。ポリシードキュメントとコーディングガイドは解釈の対象となるため、ほとんど役に立ちません。コミットフックチェックのフォーマットルール、命名規則などは、よりクリーンなソリューションであり、誰もが同様の扱いを受けることを保証します。