チームにコーディング標準をどのように導入すればよいですか？

まず少し背景：私の現在の開発マネージャーは今週の終わりに別の機会を得て、4人のフルタイムの開発者、非常勤のインターン、およびWebデザイナー（技術的にはAppDevではなくマーケティングの一部です）を残します。現時点では、新しいマネージャーの昇進や採用は行っていません。

以前のマネージャーは、順守するための一連のコーディング標準を思いつくために時間を費やすことは決してありませんでした（これを全体的に見ると、この仕事での1周年は2週間で、標準について彼と話していました始めた）。このため、4人の開発者全員が独自の方法でコードを記述しています。一部の人は.NETのMicrosoft命名規則に従い、一部はハンガリー語の表記法を使用し、一部は混合（例：混合PascalCaseとcamelCaseパラメーター名）を使用しています。あなたはそれが従うであろう標準に従ってコードファイルを開きます-一貫した唯一のものについては、中括弧が別々の行にあるということです。

私の3人の同僚のうち2人が私にアプローチして、私たちが使用し、前進させることができる標準のコーディングドキュメントを作成するように依頼しました（私は技術的には最も上級の開発者ではありませんが、4人目の開発者はここ数年ここにいる、2人の同僚そして、インターンは私にアドバイス/ガイダンスを求めますが、チームリードはありません）。私はこれをしばらくの間行うつもりでしたが、今や出発するマネージャーは常にそれをバックバーナーに置いていました。彼の出発は、今私たちが現在持っている急いでいるホッジポッジではなく、適切なソフトウェア環境を促進するために少し時間をかけて物事を正しく設定する機会を私たちに与えます。

これを行い、摩擦を起こさずにこの標準をチームに導入するにはどうすればよいですか？私が「引き継ぐ」ように見せたくないのですが、マネージャーの役​​職を申し出たとしても受け入れます。他の3人の開発者のうちの2人が私と一緒に1人を作成していますが、4人目（時間の真の「先輩」）はそれを受け入れる場合と受け入れない場合があります。私はMicrosoftの.Net規則（ハンガリー語表記を使用しないなど）から始めて、個人的な設定（_camelcaseフィールドなど）を追加し、ここで使用しない特定の奇妙な慣行を使用しないように呼びかけます（たとえば、開始時にアンダースコア）が、他に何を含める必要がありますか？私はそのような建築ガイドラインに入るためにしたくない意志 摩擦を引き起こし、それに準拠しない非常に大きくて臭い既存のコードベースがあり、リファクタリング戦略を立てる段階に近づいていません。

まとめると、基本的な命名規則を超えて、コーディング標準ドキュメントに何を含めればよいのか（例はすばらしいでしょう-そのようなドキュメントがどのようなものになるかの具体的な例を見つけることができませんでした）、そしてどのようにすべきですか新しい独裁者のように聞こえることなくそれを私のチームに提示します。

これを行い、摩擦を起こさずにこの標準をチームに導入するにはどうすればよいですか？

あなたも言う：

私の3人の同僚のうち2人が私にアプローチして、標準のコーディングドキュメントを作成し、それを使用して、前進させることができます。

ほとんどのチームからすでに賛同を得ているようです。ドキュメントの作成は、すべて（可能な場合は4つすべて）がすべて行うものにします。これに時間がかかりすぎる場合は、ドキュメントを作成し、下書きとして同僚に見せてください。全員が同意してバージョンを確定したら、準備完了です。

最初に、さまざまなスタイルコップルールを確認することをお勧めします。すべてのルールに準拠する必要はありませんが、これにより、ドキュメントに何を含める必要があるかがわかります。追加ボーナスとして、ソリューションにstylecopを簡単に実装し、自動ビルドに統合することもできます（違反がある場合はビルドに失敗します）。

要約する：

既存のツールと標準を調べて、自分に何を求めるかを決定します。

独裁者のように見えないようにするには、変更を協調的なものにします。

基本的な命名規則を超えて、コーディング標準ドキュメントに何を含めるべきか

何もない。

ゆっくりしてください。ゆっくり行きます。書く時間を無駄にしないでください。コーディング規約は、それらが共通の文化の一部である場合にのみ機能します。

それらが文化の一部でない場合、それらは単に無視されます。

これを行い、この標準をチームに導入するにはどうすればよいですか

コードレビュー。これは、コーディング規約によって解決される問題を紹介するのに最適な場所です。

ほとんどの場合、規則は単に時間の無駄です。コーディング規約を通じて解決できる実際の問題（つまり、読み取り不可能なプログラム）がある場合、100％のコンプライアンスにすばやく到達できます。

単に個人的な好みであるコーディング規約は問題を解決しません。そして実際、コードのレビュー中に、あなたはより良い何かを見つけ、実際にあなたの個人的な好みを変えるかもしれません。

コーディング規約のドキュメントでは、正規化しすぎないでください。協力して、共通の理解にたどり着きます。

アーキテクチャのガイドラインには触れたくありません。摩擦が発生し、それに準拠していない非常に大きくて臭い、既存のコードベースがあるためです。

悪い方針。

建築規格は、100％厳守されたものでは決してありません。それはできません。それは常に「前向きな」記述であり、開発はそれに向かって進化します。

優れた建築アイデアはすべて、新しい建築の方向性につながります。そしてそれがイノベーションの見え方であり、目標ではなく道です。

そして、リファクタリング戦略を思いついた時点で、私たちはどこにも近づいていません。

良い。開発しないでください。つまり、「最善のアプローチかもしれないし、そうでないかもしれない多くのことを書き留めて、イノベーションを抑制しないでください」という意味です。

コーディング規約のようなもので、特定の規約は100％全会一致であるか、それを100％全会一致にする中間的な根拠を見つけるべきだと私は言うでしょう。

• ドキュメントの完了期限を設定します。これにより、他の人がドキュメントを真剣に受け止めるようになります。

• ドキュメントをコンパイルする作業を行うと、だれもあなたを助ける気がしなくなりますが、あなたがその作業を所有している場合、誰もあなたとそれで戦うことはありません。

• 現在コードベースに存在するさまざまなスタイルに基づいて、さまざまなコーディング規約の提案を送信します。フィードバックを収集し、投票できる会議を設定します。

• 各大会が全会一致で合意するまで、誰も会議を辞めません

• チームの新しいメンバーは、ドキュメントを遵守する必要があり、発言権はありません。当時の憲法のようなものです。

ああ、ハンガリー語の表記はありません。真剣に、私はハンガリーの表記法でコードを見る必要があるよりもむしろ私の目をペーパーカットしたいです。

コーディング標準は受け入れられるための課題になるでしょう。一部の人々はサンドボックスでコードを作成し、それが壊れると問題が発生する可能性があるにもかかわらず、他の人がそれを修正しようとしているにもかかわらず、自分のことを行うのが好きです。

.NETでVisual Studioを使用している場合は、StyleCopをご覧ください。事前定義されたルールセットを使用するか、独自のルールセットを作成できます。次に、コードレビュー（ある場合）の前に、設定を順守する必要があることについて全員に同意してもらいます。

技術的な観点から：

チームにとって本当に問題である不整合を指摘し、これらの問題を解決するためのコーディング規則を定義します。

関係の観点から：

先輩を巻き込みたいなら、彼自身のコーディング規約からインスピレーションを得てください。

あなたがあなたのチームの新しいマネージャーでない限り、コーディング標準を持つことについてのコンセンサスが必要です（そしてあなたがマネージャーである場合、上からそのような決定をする前にチームでコンセンサスを得るために本当に一生懸命努力する必要があります"）。簡単に聞こえるかもしれませんが、話すこと、特に4人目の開発者と話すことで解決できます。

会社のウィキはありますか？または、それが失敗した場合、サーバーをドロップできるサーバーですか？

もしそうなら、単にページを作成します。それを生きた文書と呼んでください。いくつかの議論の余地のない基準を定め、他の誰もが協力することを奨励します。数週間ごとにアイテムを追加し続け、ディスカッションを奨励しますが、「誰もが同意しない場合は、これに従うことを期待する必要があります」と述べています。可能であれば、標準のドキュメントを購読するように全員を説得して、同僚が行った変更を確認できます。

また、チームにコードレビューを開始してもらいます。すべての仕事は2人の開発者を経由します。これにより、議論と標準の施行が促進され、ルールを指示する1人の開発者ではなく、全員が平等になるようになります。

コメントに応じて編集：

開発者＃4が知恵を広める方法として、コードレビューを販売できます。彼のコードがレビューされているときでさえ、それは人々が彼の魔法のコードを見てそれを畏敬の念を抱く機会です。本当に、それは議論を促進する方法です。コーダーとレビュアーが同意できない場合は、チームに移動する必要があります。チームが同意できない場合は、調査を行う必要があります。

研究と言えば、コードレビューについていくつか行います。意見を大いに重視している人は、彼らが悪い考えだとは考えていません。リンクの多いメールで、CIOを含むチームに送信します。邪魔な馬鹿のように見えずに彼らに反対するのは難しい。

ここにあなたが始めるためのいくつかがあります：

• http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html
• http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-do-code-review/
• http://blogs.sas.com/sasdummy/index.php?/archives/264-Are-you-too-good-for-code-reviews.html

Wikiに関しては、時間をかけて設定することをお勧めします（Wikiは、実際にそこにない場合でも、コラボレーションのような錯覚を与えます）。しかし、それができない場合は、共有ドライブ上のWord文書で問題を解決できます。

コメントと空白の標準は、さまざまなスタイル間を移行するためのツールとともに優れています。私は自分のpythonコードでタブを使用していますが、これはスタイルが悪いと考えられています。ただし、単純なVIM関数は、必要に応じて2つの間で変換します。

また、コード理解レベルについても検討してください。スタイルの目的は、コードを読んでいるプログラマに情報を伝えることです。は理解できるreduce(lambda x, y: x+y, map(lambda x: x + 1, theList))が、同僚は次のように表示したい場合：

for pos,item in enumerate(theList):
    theList[pos] = item + 1
tmp = 0
for item in theList:
    tmp = tmp + item

次に、これをハッシュすることが重要です。空白と同じです。誰もが使いやすいコード圧縮のレベルを把握する必要があります。

最後に、新しいプロジェクトと現在のプロジェクトはどのように切り詰められますか？ファイルごとに1つのクラス、ユーティリティ関数は命名スキームに従い、グローバル変数やスコープリークはありません。ランダムなプロジェクトファイルは直交しており、疎結合です。これは、すべての人に重要な理解の基盤を提供します。すべてのプロジェクトが非常に絡み合っているため、コードベース全体を調べて、いじる前にプロジェクトを実際に調べなければならない場合は、コーディング標準が何であるかは問題ではありませんfoo()。