職場でのコーディング標準の取り扱い（私はボスではありません）

私は約10人の開発者の小さなチームで働いています。コーディング標準はまったくありません。標準になった特定の事柄がありますが、物事を行ういくつかの方法は完全に異なっています。私の大きなものはインデントです。一部のユーザーはタブを使用し、一部のユーザーはスペースを使用し、一部のユーザーは異なる数のスペースを使用するため、大きな問題が発生します。誰かがIDEを使用して自動フォーマットを行い、彼らが私とは異なる文字をインデントするので、マージするとしばしば競合が発生します。どちらを使用するかは気にせず、全員に同じものを使用するようにしたいだけです。

または、ファイルを開いて、条件と同じ行に中括弧がある行と、次の行にある中括弧がある行があります。繰り返しますが、それらがすべて同じである限り、どれでもかまいません。

私は直接のマネージャーに1対1およびグループ会議で標準の問題を提起しましたが、彼はそれについて過度に心配していません（私と同じ意見を共有する他の人がいます）。インデント文字に関する特定の懸念を持ち出し、彼はより良い解決策は「レポからプッシュ/プルするときにすべてを変換できるようなスクリプトを作成する」ことだと考えました。彼は変えたくないと思うし、この解決策は過度に複雑で、将来的にはメンテナンスの問題になりやすいと思われる（また、これはより大きな問題の一つの現れにしか対応していない）。

職場で同様の状況に陥った人はいますか？もしそうなら、どのようにそれを処理しましたか？標準で上司を売るのに役立つ良い点は何ですか？草の根運動を始めて、興味のある私たちの中でコーディング標準を作成することは良い考えでしょうか？私はあまりにも細心すぎて、手放すだけですか？

お時間をありがとうございました。

注：これまでにすばらしいフィードバックをありがとう！明確にするために、1つのスタイルですべてを支配するのは望ましくありません。私は、誰にとっても最も適していることを支持して、何かをする私の好ましい方法を喜んで認めます。一貫性が欲しいし、これが民主主義になりたい。私はそれが誰もが同意するグループ決定であることを望んでいます。確かに、誰もが自分の道を歩むわけではありませんが、グループの改善のために妥協するのに十分な成熟を期待しています。

注2：上記の2つの例に巻き込まれている人もいます。私は問題の核心をより重視しています。それは多くの例で現れます：命名規則、分割されるべき巨大な機能、何かがユーティリティまたはサービスに行くべきである、何かが定数または注入されるべきである、私たちはすべて異なるバージョンの依存関係を使用するか同じこの場合はインターフェースを使用し、ユニットテストをどのように設定するか、ユニットテストを行う必要があるか、（Java固有）アノテーションまたは外部設定を使用する必要があります。続けられた。

同僚と私は、私たちが最初に参加したとき、私たちのチームで同様の問題を抱えていました（私は最初にチームに参加し、彼は約1年後に参加しました）。実際のコード標準はありませんでした。私たちはMSショップであり、MSコーディング標準さえ使用されませんでした。例でリードすることにしました。私たちは一緒に座って、IDE標準、命名標準、考えられるすべての標準をすべて備えたドキュメントを作成しました。その後、彼と私は、この標準に明示的に従うことに同意しました。チームにメールを送り（私たちの両方から）、不足を発見したことを通知し、その不足をドキュメントで解決するつもりでした。批評、アイデア、コメント、意見を募集しました。私たちはフィードバックの形でほとんど受け取っておらず、ほんの少しだけ押し返しました。彼と私はすぐに標準を使い始め、そして、私たちがプロジェクトにジュニア開発者を連れてきたとき、彼らに標準を紹介し、彼らはそれを使い始めました。最初は気が進まなかったが、非常に多くのことで標準を徐々に使い始めたリードがいくつかあります。

ジュニア開発者の多くが同じ問題を認識していたが、誰かがステップアップして決定を下すのを待っていたことがわかりました。従う計画があると、多くの人がそれを採用することに熱心でした。クラックするのが難しいのは、他の方法でコーディングすることを拒否する人たちであり、通常は長期的には自分自身をコーディングします。

標準が必要な場合は、道を切り開きます。チームにメリットがあると思われる標準の推奨リストを作成します。同僚やリードに送信してフィードバックを求めます。あなたのチームの他の人々も同様のアイデアを持っていると思いますが、おそらく彼らはそれについて何かをする意欲に欠けています。ガンジーが言ったように、「あなたは世界で見たいと思う変化でなければなりません。」

標準は、管理者によって定義および実施されるものであってはなりません。チームは全体として標準に同意する必要があります。共通の標準セットに同意できない場合、管理者に標準を強制させることは失敗します。

あなたとあなたに同意する他の人は、模範を示すべきです。同じコーディング標準の使用を開始し、それらを公開し、チームの他のメンバーにそれらを促進し、それらを改善する方法についてフィードバックを求めます。

標準を推進しようとするときの重要な点は次のとおりです。焦点は、物事を行うための最良の方法を見つけることではなく、物事を一貫して行う方法を見つけることです。一部の人々が意見を異にするかもしれないが、真の括弧スタイル、真のコメントスタイルなどは存在しない。コードが読みやすくなる（したがって、維持しやすい）のは、それが何であれ一貫したスタイルだ。

これが引き起こしている問題のために無駄にした時間のいくつかの証拠を示すことができますか？

これらの問題の処理にかなりの時間を費やしている場合、または修正に時間がかかるバグが発生している場合、これはコーディング標準を採用することで大幅に削減できるコストです。

そのため、発生した問題と、それらを解決するのにかかった時間のログを保存してください-あなたと（あなたが問題を認識している）同僚の両方に。

その後、同僚に提示するのに妥当な量のデータが得られたら。彼らは標準を採用することの利点を見るべきです。上司と上司にデータを表示しない場合。コーディング標準を作成することで、会社の費用を節約でき、採用を支援する必要があることを示します。

あなたの特定の状況では、あなたの上司の解決策は良いものだと思います。キャリア全体でこれまで行ってきたことを誰も変更する必要はありません。コンパイラが無視するコードスタイルの一部は、コードが読み取り可能な限り重要ではないため、大丈夫です。チェックアウト時に全員が自分のスタイルに自動フォーマットし、チェックイン時に標準スタイルに自動フォーマットした場合、すべてうまくいきます。（残念ながら、私はどこで作業するかを提案しましたが、継続的インテグレーションサーバーが見るのと同じ正確なコードをコーダーが記述しなくなるという理由で反対しました。）

コーディング基準は、コードの品質に大きな違いをもたらす場所に適用すると良いと思います。たとえば、小さなメソッド、明確に責任を明確に述べたクラス、より難しい部分に対する有用で正確なコメントなどです。自動的に確認することは困難ですが、それはソフトウェア開発の基本です。本当にできることは、他の人に良い習慣を教え、間違った行に括弧を付けてコードを読むように自分自身に教えることです。

コーディング標準について：コーディング標準は「標準」ではなく「良いこと」であると言って、ほぼ全員と一緒に登ります。

しかし、夢中にならないでください。私は特定のインデントスタイルを文字数まで指定するプロジェクトに取り組んできました（そして、プロジェクトがそこまで行くと、必然的に8スペースインデントのような愚かなものを選択します）。小さなものに汗をかかないでください。

シンプルなソリューション：開発者にブレースとインデントの選択肢を制限しますが、ブレースのスタイルとインデントはモジュール全体で一貫している必要があります。（foo.hとfoo.cppを同じスタイルにしたいですか？）メンテナーは既存のスタイルに適応する必要があります。気まぐれなスタイルに合わせてモジュールを書き換えることはできません。モジュール内の複数のスタイルは紛らわしいだけで、ずさんな兆候です。そのナンセンスを見ると、他に何が間違っているのだろうと思います。

ファイルの保存されたコンテンツのインデントのタブを禁止することも考えたいかもしれません。ほとんどのIDE /エディターは、ユーザー入力タブをスペースに変換する合理的なジョブを実行し、ほとんどの場合、その変換を自動化するオプションがあります。多くの場合、ファイルにタブ、特にタブとスペースが混在するバッグが既に含まれている場合、くだらない仕事をします。

とはいえ、プロジェクトにもっと深い問題があるかもしれません。あなたはマージの問題に言及しました。多くのマージを行う必要がある場合は、プロジェクトの不適切なパーティション分割の兆候である可能性があります。料理人が多すぎるとブロスが台無しになるのと同じように、同じファイルを操作するプログラマが多すぎるとプロジェクトが台無しになります。ジョー、スージー、そしてそれぞれがfoo.cppに触れているのはなぜですか？

これは、いくつかの研究が行われている分野の1つです。基本的に、主な質問は、コードレビューを行っているかどうかです。コードレビューは、間違いなくコード品質を改善する最も効率的な手段です。（出典：Software Engineering Institute、CMU）。確かに、追加のテスターよりも効率的です。

現在、コードレビューは、他の人のコードを読みやすくするため、共通のコーディング標準の恩恵を受けています。これにより、コーディング標準を導入するための2段階の引数が提供されます。最終的に、優れたコードを作成するためのコストが安くなります。

これに関してあなたと一緒にいる「いくつかの他の人」がすでにいるので、私は即席の会議を提案するでしょう。すべての開発者を招待し、少し時間をとって、自分や同僚が日々悩んでいることを把握します。最初は特定の解決策を見つけようとせず、現在のコードを書いている方法で何が変わる必要があるかを考えてください。

次に、いくつかの基本概念について全員が同意できるかどうかを確認します。@David Hammenが提起した各モジュール内で同じスタイルを使用するという提案は良い出発点であり、ほとんどの開発者がすぐに同意できると思います。

ダウンパットができたら、新しいコードを書くときの基本的なスタイルにすべて同意できると思うなら、それは良い追加です。実際に保守性に影響を与えるものに焦点を当てます。命名の問題は私の個人的なリストで高くなります。1つの製品に6つの異なる命名スタイルがある場合、それは非常にすぐに頭痛の種になりますが、再び、あなたとあなたのチームが重要だと感じることに集中します。少なくとも全員が従うことに同意できる短いドキュメントを作成し（たとえ自分たちが異なるペットスタイルを持っている場合でも）、チームの全員に郵送します。それを「生きた」ドキュメントにし、時間とともに更新することを忘れないでください。しかし、あまりにも厳格で具体的なものにしないでください。

上司がコードの記述に関与していない限り、どの正確なスタイルが採用されるかについてあまり心配するべきではありません（読みやすさと保守性に焦点を当てている場合）。しかし、彼はチームの全員の利益を共通のスタイルに従って見ることができるはずですコードを書くとき。

痛いことがいくつかあります。最も痛いのは、コードを自動的に再フォーマットするIDEと、さまざまな方法でIDEをセットアップする開発者の組み合わせです。コードを比較するたびに、異なる設定を持つユーザーがコードを編集した後、100の変更があります。それは受け入れられない。ここでは、全員の頭を合わせ、設定セットに同意し、異なる設定を使用している人によるチェックインを拒否する必要があります。1行のコードを変更すると、差分には数百行ではなく、1行のコードが表示されます。

他のすべては無害であるか、他の人が確信できることを行うより良い方法があります。ここでのルールは次のとおりです。本当に改善しない限り、他の人のコードをいじらないでください。また、スタイルAとスタイルBの混合は、スタイルAまたはスタイルBの両方よりも常に劣ります。

必ずベストプラクティスに従ってください。これは言語ごとに異なります。しかし、そこには標準は必要ありません（それは善意のある人によって書かれているかもしれませんが、実際にはその知識はありません）が、誰もが良い例を挙げようとするべきです。

権力闘争を絶対に避けてください。あなたのチームには、すべての人を彼の意志に追い込もうとする小さなヒトラーほど悪いものはありません。そして、それは残念ながらあなたのコーディング標準を書くことを志願する人です:-(

あなたが与えたすべての例は、基本的に空白とフォーマットに関するものです。それが最大の問題である場合、私はあなたのマネージャーに同意します。それはそれほど大きな問題ではありません。

標準が本当に非常に役立つのは、名前を付けて複雑さを減らすことです。識別子、クラス、それらを置く場所などに名前を付ける方法。名前の一貫性を保つことは、特に大規模なプロジェクトでは非常に重要です。複雑さを軽減するためのルールには、関数を特定の行数に収める（小さな関数に分割する）か、パラメーターリストを特定の数の引数よりも少なくする（おそらくオブジェクトにまとめて渡す必要があります）ことが含まれます。

チームの特定の開発者が、1文字の変数名を持つ長いコードチャンクが多く含まれているために理解/デバッグが困難なコードを記述する場合、それは修正可能なものではなく、いくつかの標準を採用する正当な理由ですスクリプト。これは、標準が改善できるものとして（巧妙に）指摘するのは良いことです。

マネージャーが問題としてそれを見ていないかもしれないもう一つの理由は、あなたが実際にお互いのコードをあまり頻繁に読まないということです。これは、誰もがコードの独自の領域を持ち、それ以外の場所にあまり進まない場合に発生する可能性があります。誰かが組織を離れるまで、それは非常にうまくいきます。それはさまざまな理由で起こります。読みやすくするための標準は、新しい開発者がコードのメンテナンスを引き継ぐことを容易にします。

誰かが自分のIDEを使用して自動フォーマットを行い、私とは異なる文字をインデントするため、マージすると競合します

これはあなたの問題であり、フォーマットではなく、再フォーマットのようです。これはSCMにとって大きな問題であり、アドバイスは簡単です：しないでください。そのため、誰かがすべてのスペースをタブに再フォーマットしたり、中括弧を好みのスタイルにリファクタリングしたりするときは、それらを平手打ちする必要があります。代わりにマージを実行させます。彼らの不注意が引き起こした時間の無駄を認めないように彼らの上に立ってください。

別の方法は、チェックインの前にすべてのコードを常に標準スタイルに再フォーマットする事前コミットフォーマッターを配置することです。当然のことながら再フォーマットする開発者のチームがある場合、これは良いオプションです-SCMは常に同じフォーマットを見るので、デルタは小さくてマージに適しています。

誰かが私が働いている新しいコーディング標準を提案したら、それに投票します。多数決を得た場合は受け入れられ、そうでなければ拒否されます。これを行わないと、規格に賛同できず、文書化されていても使用されません。

あなたの特定の問題に関して、あなたの最善の策は、おそらくジョエルの提案から始まり、例によってリードするでしょう。これに関心のあるプログラマーを1人か2人集めて、合意に達すると、怠onesなプログラマーに課す力がいくらかあります。

さて、一般的な問題については、単に変調するのが最善だと思います。ファイルごとに異なるファイルを取得します。ファイルに保守性を与える必要がある場合は、たとえ他のファイルと異なっていても、コーディング標準をそのまま保持します。同じファイルに書き込む必要がありますか？サブセットファイルを作成し、代わりに組み込みます。

これを試さないでください！

カウンターバイリードの例。コードのフォーマットをできる限り恐ろしいものにし、他の人のきれいなコードに恐ろしくフォーマットされた多くの変更をチェックインしてください。（避けられない）反応が発生したら、コーディング標準がないため、あなたがしていることは問題ないと言います。

同僚にリンチされない場合（!!）、コーディング標準になる可能性があります。

明らかに、これはハイリスク戦略です... :-)