チーム内のさまざまなプログラミングスタイルに対処する方法

小規模な開発チーム（開発者3人のみ）があり、最近、新しいチームメンバーを獲得しました。彼は賢いコーダーですが、彼のコーディングスタイルは私たちのものとはまったく異なります。既存のコードベースには、ほとんどが読み取り可能で、クリーンで保守可能なコードが含まれていますが、新しいチームメンバーは多くのファイルをすばやく変更し、,いハックとショートカットを導入し、あらゆる場所で定義を使用し、間違った場所に関数を追加します。

私の質問は、他の人が以前にそのような状況を経験したことがあるかどうか、そして誰かが彼と話す方法に関するヒントを持っているかどうかです。

私は1年以内に2人の開発者から10人に成長したチームと協力しています。私は3番で、コーディング標準の問題を最初に提起しました。元の2人の開発者は数年間一緒に働いていましたが、彼らは私には馴染みのない共通の標準を採用していました。あなたが説明している問題とまったく同じ問題がありました。

私たちがしたことは：

研究コーディング標準

私たちは確立されたオープンソースプロジェクトをチェックアウトするのに数日費やしました。チームが急速に拡大することはわかっていたため、一般的なガイドラインではなく、実際のプロジェクトに基づいた実際のソリューションを探していました。また、最適なコーディング標準は気にしませんでしたが、すべてのコードベースのリファクタリングを必要とせず、理にかなっている一連のルールとガイドラインを気にしました。コーディング標準のハックを探していました。

私たち3人は、確立されたPHPプロジェクトに最適なコーディング標準はZend Frameworkが従うものであると判断しました。幸いなことに、Zend Frameworkの人々は非常に包括的なコーディング標準ドキュメントを提供しています。

独自のコーディング標準の作成

もちろん、私たちのプロジェクトに別のプロジェクトのコーディング標準をそのまま適用しても意味がありませんでした。Zend Frameworkドキュメントをテンプレートとして使用します。

• まず、プロジェクトに当てはまらないものをすべて削除しました
• それから、スタイルの問題として認識したすべてのものをスタイルに変更しました
• そして最後にすべてを書き留めました

だから私たちの手元にはかなり大きな文書があり、ファンシーウィキに保存されていました。それはすてきな読み物であり、私たち全員が同意しました。そして、それだけではまったく役に立ちません。

約束を守る

当時のコードベースは約1 * 10 ^ 6 slocでした。正式なコーディング標準を採用したため、コードのリファクタリングを開始する必要がありましたが、その時点で他の問題に追われていました。そのため、コアライブラリ、つまりわずか5 * 10 ^ 3 slocをリファクタリングすることにしました。

私たちのうちの1人をコーディング基準のマスター（マスターの代わりに冒とく的な表現を使用）に割り当て、標準を確認して実施する責任を負いました。数回のスプリントごとに役割をリサイクルします。私は最初であり、ほとんどすべてのコミットを監視する必要があったため、多くの作業でした。

私は在職中に元の文書にいくつかの新しい議論と小さな補遺があり、最終的にはある程度安定した文書ができました。時々変更しますが、これらの変更のほとんどは、PHP 5.3が名前以外のメジャーリリースであるため、言語の新機能に反映されます。

新しい男に対処する

次の新しい男が到着したとき、私たちのコーディング標準をテストする時が来ました。私たちのコードベースを少し紹介した後、私たちは彼にコーディング標準ドキュメントを評価するように頼みました。彼はほとんど泣いた。彼はすべてを違ったやり方でしたように見えた。

私は当時コーディング標準のマスターでしたので、彼の入力を評価し、それに応じてドキュメントを修正するのは私次第でした。彼の提案は：

• 個人的なスタイルの事項（すぐに却下）
• 彼のJavaの背景には意味があるが、PHPにはあまり意味のない標準（却下）
• PHPでの短い経験から持ち込んだ規則（一部は却下されましたが、多くの場合、最初の研究では考えも見つけもされなかった人気のある規則であることが判明しました）

次の数週間、彼は単純なタスクを割り当てられました。コードベースのいくつかの部分を標準に合わせて最新のものにします。いくつかのルールに基づいて、これらのパーツを慎重に選択する必要がありました。

• コードベース（およびPHP全般）に不慣れな人にとっては、コードは比較的簡単でなければなりません。
• コードは、彼がするために雇われたものの上にあるべきです

私は彼のプロセスを監視し、彼は素晴らしい仕事をしました。ドキュメントに適合させることが不可能なコードのいくつかの部分を特定し、それに応じて修正しました（コードおよび/または標準、どちらか適切な方）

そして、別の新しい男が到着しました。このプロセスを繰り返し（今回は別のマスター）、再び機能しました。そしてまた。

結論として

1. コーディング標準ドキュメントを作成しますが、自分の標準があなただけのものではなく、プラットフォームのより広いコミュニティの一般的な標準を反映していることを確認してください。
2. コーディング標準マスターに同様の役割を割り当てます。少なくとも新しいコード、特に新しいメンバーからの新しいコードを監視する人。非常に退屈なので、役割をリサイクルします。
3. 常に新しいメンバーからの入力を評価してください。理にかなっている場合は、常に基準を改訂してください。コーディング標準文書は進化しているはずですが、ゆっくりと進化しています。反復ごとにコードベースをリファクタリングする必要はありません。
4. 各新会員があなたの基準と慣習を学び、順応するのにしばらく時間を取ります。これらの状況で最高の仕事をして学んでください。
5. Wikiは、そのようなドキュメントに対して驚くほど機能します。
6. コードレビューはどんな状況でも驚くほど機能します！

プロセスのある時点で、標準のチェックを自動化するために事前コミットフックを使用することが提案されました。さまざまな理由でこれに反対しました。この問題に関するStackOverflowに関する興味深い議論がいくつかあります。

• チェックイン時のSVN自動コードフォーマット？
• バージョン管理とコーディングのフォーマット
• PHPコードスニファー（phpcs）-SVNプリコミットフックの一部として使用するときにオーバーライドを許可する方法
• 特定のフォルダーに対してトリガーされるSVN事前コミットフック
• PHPコーディング標準の実装

一部はPHP固有ですが、答えはすべてのプラットフォームに適用されます。

はい、私はそれを前に経験しました。チームで作業する場合、チームメンバーは特定のルールと規則に同意する必要があり、これにはスタイルが含まれます。

チームに一緒に座って、チェックインコードのすべての部分を順守するよう要求する一連のルール、コーディング標準を作成する必要があります。

おそらく、少なくともスタイリングに関しては、ルールセットのベースは既存のコードになります。完了したら、全員が遵守する必要があり、コードレビューの一部として検査する必要があります。標準に準拠していないコードはチェックインできません。

ちなみに、これは民主的な投票である必要はありません。チームリーダーが実際に何らかの権限を行使できることの1つです。しかし、そうは言っても、チームの大部分が拒否する基準を課すことはできないと思います。一人、特に新しい人が拒否する基準を課すことができます。

彼と話す方法について...すべての経験豊富なプログラマーは、各場所とチームが独自の慣習とスタイルを持っていることを知っています。彼は改善を提案することを歓迎しますが、彼はチームが持っているルールを遵守する必要があり、既存のコードのスタイルを変更するのではなく、新しいコードを追加するときに同じスタイルを使用する必要があります。

また、あなたが不適切だと思う特定のこと（定義、順序、ハッキング、ショートカットなどについて言及したこと）を行わないように、その人に伝えることができます（あなたが上司である場合、または上司に相談する場合）。

1. 誰かが担当しています-彼らはそのように行動する必要があります。
2. コーディングスタイルが非常に重要な場合は、なぜこの人に説明されなかったのか、ルールを学習するまでコードにアクセスできないことを伝えます。
3. コードレビュー-明らかにあなたは何も持っていないか、非常に弱いです。＃1を参照してください。

採用プロセスでは、受け入れられているコーディングスタイルに従うことが雇用の要件であることをメモしてください。今、あなたはルールに従わない人たちに何をしますか？プログラムを使用するまで、ライブコードへのアクセスを削除することから始めます。

。

できることは次のとおりです。

1. 必要なコーディングスタイルを説明するドキュメントを作成し、チームの全員に学習させる。すべてのチームメンバーから情報を収集します。
2. すべてのチームメンバーが自分の部分に責任を持ち、コードのその部分の規則を決定できるようにタスクを分割します。問題が見つかった場合、それを書いた人が問題を修正します。
3. コードがバージョン管理にコミットされるたびにインデントなどを修正する自動ツールをバージョン管理に追加する
4. 異なるプログラマーは常に異なるプログラミングスタイルを持ち、後で変更することは困難です。それを処理する最善の方法は、チームメンバー間で情報を共有し、誰もがどのスタイルを使用したかを知ることです。異なるコードを記述するチームメンバーがいる場合、既存のチームメンバーが新しいスタイルを学ぶチャンスです。
5. 1つの良い方法は、既存のコードを変更しないことです。コードを変更する代わりに、空の行を新しいコードに置き換えて新しいコードを作成します。そして、コードの準備ができたら、既存のシステムに最小限の変更を加えて、新しいコードを使用します。これにより、既存のコードを微調整する必要がなくなり、すでに正常に機能していたコードが破損する可能性があります。

避けるべきことは次のとおりです。

1. 他のチームメンバーよりも誰かのコードが優れているか悪いかを判断する。それはちょうどそのように機能しません-誰もがコードでそれを使用するのに十分十分に言語の特定のサブセットを知っています。すべてのプログラマーが学習するために異なるサブセットを選択しており、一緒に学習しない限り、異なるように見えます。
2. 誰かがコードを書く方法を変える。人々になじみのないスタイルを書かせることで得られるのは、コードに大量のバグが発生することだけです。人々は、初めて使用するものの十分な詳細を知らないだけです。プログラマは常に言語のサブセットを選択し、それだけを使用します。プログラマーがgotoで満たされた数千行のコードを記述している場合、gotoはバグの少ないコードを提供します。
3. また、既存のコードベースがすてきで、クリーンで、保守可能なものであると考えるべきではありません。常に改善すべきことがあります。しかし、すべての変更は、それに書かれた元の設計思想を曖昧にします。後で完璧なコードを書くことを目指してください。そうすれば、後で変更が必要になることはありません。（新しい人が最初に正しく行われていれば、完璧なコードを「壊す」必要はありません）

既存のコードベースには、ほとんどが読みやすく、クリーンで保守可能なコードが含まれています

私が長年にわたって学んだことの1つは、読みやすさは見る人の目にあるということです。私は、誰かのニワトリのコーディングスタイルが「読み取り可能」であると正当化される多くのケースを見てきました。どのコーディングスタイルが最も「読み取り可能」であるかについて、完全に合理的な人々が議論しているのを見てきました。たぶん、この男はあなたのスタイルを読みやすいものとして見ていませんか？

そうは言っても、新しい人はあなたの標準に従うべきであり、その逆ではありません。

リポジトリへの新しいコードのプルリクエストの使用を検討してください。これにより、コードレビューを行うのに便利な場所が提供されます。コードレビューに失敗したコードは、整形されるまでリポジトリにマージされません。

プルリクエストが大きくなりすぎないように注意してください。私の経験では、それらは半日から最大2日間を超えてはなりません。さもないと、マージの競合が多すぎます。

bitbucketやgithubなどのオンラインvcsシステムは、この機能をサポートしています。オンプレミスのアプローチを好むなら、スタッシュは現在最善の策のようです。

従うことができる簡単なルールがあります。コードでファイルを変更する場合、そのファイルで使用されているコーディング標準を使用します。新しいファイルを作成する場合、適切なコーディング標準を使用します。（プラス：コンパイラーが警告を出すことができる場合は、すべての妥当な警告を有効にし、可能であればwarnings = errorをオンにし、警告のあるコードを許可しません。プラス：変更などのファイルで大規模な変更を行うツールを使用する場合スペースなどのタブを使用しないでください）。

コーディング標準に関して大きな議論がある理由は、ある標準が他の標準よりも良くも悪くもない（通常）だけでなく、単に異なるからです。唯一の本当に悪いのは、コーディングスタイルを混在させることです。

明らかに、まともなプログラマーは、特定の標準を好むかどうかにかかわらず、コーディング標準に従ってコードを書くことができると期待しています。

一方、品質基準があります。品質基準を満たさないコードは絶対に受け入れないでください。