一貫したコーディングスタイルを持たない同僚を扱いますか？
文体的に悪いコードを書く傾向がある人と一緒に働いているとき、あなたは何をしますか？私が話しているコードは、通常、技術的に正しく、合理的に構造化されており、アルゴリズム的にもエレガントな場合がありますが、醜く見えるです。私たちは持っている：
- 異なる命名規則とタイトルの混合（_
underscore_style_とcamelCaseとUpperCamelとCAPSはすべて、同じ関数内の異なる変数にランダムに適用されます） - 奇妙で一貫性のない間隔。
Functioncall (arg1 ,arg2,arg3 ); - コメントと変数名のスペルミスの多い単語
私たちが働いている優れたコードレビューシステムがあるので、最悪のものを調べて修正することができます。ただし、「ここにスペースを1つ追加してください。「イタレータ」を正しく入力してください。大文字と小文字を変更するなど）」という50行で構成されるコードレビューを送信するのは、本当にささいなことです。
この人にこれらの種類の詳細にもっと注意深く一貫性を持たせるようにどのように勧めますか？
コーディング規約に同意
これが1つのポケットベルであっても。チーム全体が座り、チーム全体が使用できる基本的なコーディング規約に同意することをお勧めします。
私はあなたがしていることをし続けなければならないだけだと思います。明確な一連のコーディングガイドラインを用意し、コードレビュー中にそれらを実施します。開発者が何かをチェックインしようとするたびに「ここにスペースを1つ追加」と「スペルイテレーター」を50行または100行取得し、それらすべてが修正される前にチェックインが実際に許可されない場合、最終的に彼は面倒を避けるためだけに、よりクリーンなコードを書き始める必要があります。
NimChimpskyが提案したように、これらのことを自分で修正すると、この人を永久にクリーンアップすることになると思います。
クラスや変数の命名などの規則は重要であり、上品で効率的なコードも順守する必要があると思いますが、私の回答が何度も反対票を投じられる危険性があるため、一般的に「かなりのコード」というパラダイムは、私見で非常に過大評価されている多くの周りにプッシュされます。
まず、それを書いた開発者はそもそもそれを維持する必要があります。もし彼がバスにぶつかって、他のプログラマーがコードが「きれい」ではないのでどのように機能するのかわからない場合、とにかく、他の開発者はあまり良くありません。そして、そこには多くの自動化されたフォーマッタ/美容機能があるので、誰でも必要に応じてそれらを使用してコードを美化できます。「フロー内」/「ゾーン内」にいる間に時間を無駄にすることはありません。
ここではスパゲッティ/カウボーイスタイルのコーディングを推奨していないことに注意してください。実際には、非常にうまくフォーマットされたスパゲッティコード（4-5画面にわたる関数本体、さまざまなソースコードファイルに散在するグローバル変数、名前の悪いピックなど）
変数名のスペルミスやフォーマットは問題ではないと言ったすべての人にBSを呼び出します。明らかに、彼らは自分のコードを読んだだけです。そして、Wordがすぐそこにあることに注意してください-読んでください。スペルミスが多い本、ミッシュマッシュされたフォーマット、一貫性のない行間隔、および多くのソースコードで蔓延しているその他のさまざまな怠惰な本を読んでいると想像してください。それは退屈です。
構文が100％正確でなければならない職業では、実際の開発者がクリーンで一貫性のあるコードスタイルを持っていないという言い訳はありません。それ以外はだらしと怠惰です。私はいつも実装でだらしなくフォーマットされたコードの正確さに疑問を投げかけます。
私たちが働いている優れたコードレビューシステムがあるので、最悪のものを調べて修正することができます。ただし、「ここにスペースを1つ追加してください。「イタレータ」を正しく入力してください。大文字と小文字を変更するなど）」という50行で構成されるコードレビューを送信するのは、本当にささいなことです。
自分で変更して、コードに丁寧なコメントを追加します。
これは質問が述べたようにすでにスタイルガイドがあることを前提としています：
私たちは良いコードレビューシステムを持っています
したがって、私の提案は最後の手段です。自分で変更してコメントを残すのは、電子メールなどを送信するのと同じくらい簡単です。
同僚の1人が、私の皮膚を這わせるような方法でhtmlを作成しています。 2つのスペースインデントで構成されたhtml Niceを想像してみてください。同じ行または次の行で終わるタグに追加されたタグによってハッキングされ、立ったまま腕をあなたの周りに投げる必要がある酔っ払いのようになっています。新しい行はめったにインデントされていませんが、そうである場合は、銀河の一部に非常に無秩序なブラックホールがあり、その数字が何らかの方法でインデントに使用されているスペースやタブの数を反映するように、不合理な温度値を吐き出しています。この女性によって。運がよければ、「</input>」で閉じられたinputタグが表示されます。あなたが理解できる完全な悪夢。
誰もこれを理解していないようであり、ここで最も上位の組織化されたコードまたは組織化されていないコードがどのようにしてそれらにサンドイッチをかけるかは、私たちがサンドイッチにスイスチーズまたはアメリカンチーズを置くことの違いに似ています。私は別のプロジェクトにストレスを感じたのでスライドさせ始めました、そして彼女は改善する前にそのようなコードを理解することがいかに難しいかを理解し始めたと思います。私のアドバイスは、デモンストレーションを行うことですなぜ単にコードにスタイルを付けるように指示するよりも、スタイルを設定することが望ましいです。
私が話しているコードは通常、技術的に正しく、合理的に構造化されており、アルゴリズム的にもエレガントかもしれません...
あなたがすべてを手に入れたことを幸せにしてください。ほとんどのプログラマーは、おそらくあなたにそのリストの最初のものを与えるでしょう。変数の命名と間隔は、心配する必要のない最も重要なことだと思います。
フォーマットの問題を探すJUnitテストがあります。ビルドの一部として実行されます。 if、while、forと開き括弧の間のスペースを省略して、常にビットを取得します。ただし、コードのフォーマットは一貫しています。
スタイルの規則を設定して同意する必要があるようです。そうでなければ、3つのスペースインデントを持つライブラリ、4つあるライブラリ、Camel Caseを使用するライブラリ、underscore_caseを使用するライブラリがあります。
変更したいのは個人的な好みですか、それとも従うべき実際の基準はありますか？実際の規格がない場合は、これを行わないでください。まず基準を設定します。その後、コードを標準設定にリファクタリングするように設定できるソフトウェアを入手できます（少なくともいくつかの点で）。
標準がある場合は、コードレビューでそれを適用し始めます。コードレビューで標準を適用しない場合、標準がある意味はありません。これは、人々がそれに触れると元々標準に適合しなかった古いコードを修正する必要があるため、メンテナンスで多くの余分な作業が必要になることを意味します。
標準がなくても、変数名のスペルミスを修正するように要求します（コメントについては特に心配しません）。コードに触れるすべての人を永遠に狂わせるためです。
コーディング標準を特定して、誰もがそれが何であるかを理解してから、強制する必要があります。ルールを守らないと結果が出るはずです。
いくつかのインセンティブを提供する必要があるものは次のとおりです。
- コードレビューは面倒で、必要以上に長くなります。
- コードはより頻繁に拒否されます。
- スケジュールが満たされません。
誰もあなたのルールを強制しないのでこの人がこれを心配する必要がないか、彼らが非生産的であるかどうかを気にしない（そしてそれについて誰も何もしない）場合、それについてあなたができることはあまりありません。
私はプライベートチャットをすることを提案し、あなたとあなたの両方が根本的な原因を見つけることができるかどうかを確認したくなるでしょう：
同僚は急いでいますか、そして誰かが昨日コードを望んでいたので、その人は何かをできるだけ速く機能させようとしていますか？これは、仕事のスピードよりも品質に重点を置くようにこの人に通知する機会になる可能性があります。 「時間をかけてください」などのマントラは、これが逆効果にならない場合に役立ちます。
人は自分の作品をどのように見ているか？誇り感があるなら、上達させるために使う角度があるかもしれません。仕事を支払うだけの仕事だとしたら、変化を得るのはかなり難しいかもしれません。彼らは彼らが素晴らしい仕事をしていないことを知っていますが、それにとても近いですか？
この人は慣習に同意せず、抗議してコーディングしようとしていますか？もしそうなら、あなたは大きな問題を抱えているかもしれませんが、これが事実であるか、人が単に怠惰であるかどうかを調べる価値はありますか？ここではどのような動機が役立つでしょうか。欲望、プライド、または他の悪意を訴えて、人を改善させることができますか。これは卑劣ですが、Nice guyルートを試しても何もない場合は効果的です。
友達を獲得して人々に影響を与える方法 は、説得力があるという点で、改善を賞賛し、その人に支持すべき優れた評判を与えるなど、いくつかの提案があります。
これを非公開で行う必要がある理由については、いくつかの理由があります。
誰かが自分の性格が暗殺されていると感じる可能性のある野外で放置されるよりも、ドアの後ろに保管するほうがよい屈辱、批判、またはその他の不快感が生じる可能性があります。
あなたはこの他の人に少し開放するように勧めたいと思います。ここでの課題は、一部の人々は非常に警戒しており、壁を倒すのに長い時間がかかる可能性があることです。
可能であれば、オフィスから少し離れた場所でこれを実行することをお勧めします。昼食に出かけたり、散歩をしたり、周囲を十分に変えて人が少し快適に感じるようにしたりします。これは課題となる可能性があり、人を知る必要がありますが、ここでの考え方は、オフィスでは役立たない可能性が高いワークマスクを着用する人がいるということです。
会話がかなり熱くなったり醜くなったりする準備をしておいてください。ただし、他の人との交流を続け、良い対話ができるのであれば、これは良い兆候になるでしょう。物事を公開しないことを好む人もいれば、物事を成し遂げるより微妙な方法を好む人もいます。重要なのは、他の人に十分に耳を傾け、共感を示し、相手の側面を理解しようとすることです。
スタイルの慣習に従うのはどれほど難しいですか？スペルミスは理解しましたが、残りは雑な考え方とコーディングの指標です。プロダクションコードに関しては、一貫性を保つ必要があることを説明します。一貫性のないスタイルで製品コードを書くことは、単なる失礼で、利己的であり、思いやりのないことです。
Eclipseを使用している場合は、Java Editorsに対してSave Actionsを有効にして、それを使用するようにすべての人に伝えます。これにより、すべての保存時のフォーマットの問題が修正されますが、不適切な大文字の使用は修正されません。でも！
笑。あなたは私のコードを絶対に嫌うでしょう。私は自分の命を救うために綴ることができず、気にしません。
しかし、私は一部の人々が実際にそれらのことを気にしているのを知っています。
その醜いコードを書いている人が変わらない場合は解雇して、物事を本当に美しくする人を見つけて、
通常は技術的に正しく、合理的に構造化されており、アルゴリズム的にもエレガントな場合があります
そして、それができない場合は、少なくとも壊れたきれいなコードを顧客に見せて、その上で販売することができます！
しかし真剣に。まず、実際に重要なことに焦点を当てます。 「繊細な感性を傷つける」以外の理由が見つからない場合は、今は無視してください。それが実際に重要である場合、その人と一緒に座って、その重要性を彼らに納得させます。クラスレベル、メソッドレベル、共有、定数変数の違いを簡単に区別できるようにする標準のようなものは違いを生みます。問題のコーダーが彼/彼女の職業をまったく気にしない場合、彼らは理解して正しいことをしようとします。
フォーマットに関する＆％$＃を提供しないアウトソーシングされたリソース（または簡単に回避できるバグ）を処理するときの私の解決策は、ビルドサーバーに強制することでした。毎晩実行されるCIサーバージョブを作成してコードをチェックアウトし、Jalopyとfindbugsを実行してコードをチェックインしました。標準のコード規則を使用しないと仕事が難しくなることを他のチームが知ると、彼らはIDE標準フォーマットを維持するため。