悪いコードを書いていることを誰かにどのように伝えますか？
私は、楽しみのためにコーディングプロジェクトに少人数のグループで取り組んできました。それは組織化された結束力のあるグループです。私が働くすべての人は、プログラミングに関連するさまざまなスキルセットを持っていますが、一部の人は、過度のグローバル変数、貧弱な命名規則など、古いまたはまったく間違った方法を使用しています。物事は機能しますが、実装は貧弱です。経験や教育に疑問を投げかける（またはin辱する）ことなく、より良い方法論を使用するよう丁寧に依頼または紹介する良い方法は何ですか？
質問を導入して、彼らがしていることが間違っていることを認識させます。たとえば、次の種類の質問をします。
なぜそれをグローバル変数にすることにしたのですか？
なぜその名前を付けたのですか？
それは面白い。私は通常、この方法を使います。[あなたが優れている理由を挿入]
その方法は機能しますか？私は通常[愚かに見えるようにする方法を挿入]
これを行う理想的な方法は、彼らが特定の方法をコーディングする理由を微妙に尋ねることだと思います。他の方法には利点があると彼らは信じていることに気付くかもしれません。コーディングスタイルの理由が誤った情報によるものであることがわかっていなければ、正当な理由がなければ自分のやり方をより良いと判断することはありません。これを実行する最善の方法は、彼らにその方法を選択した理由を尋ねることです。それは彼らの能力ではなく攻撃する必要があるからです。
コーディング標準は間違いなく役立ちますが、もしそれがすべてのソフトウェアプロジェクトの答えであれば、楽園の私有の島でカクテルをすすります。現実には、私たち全員が問題を起こしやすく、ソフトウェアプロジェクトの成功率はまだ低いです。問題のほとんどは慣習に関する問題ではなく、個々の能力に起因するものだと思います。そのため、問題がheadい頭を抱えているときにグループとして問題を解決することをお勧めします。
最も重要なのは、あなたのやり方がより良いとすぐに仮定しないでください。実際にはそうかもしれませんが、私たちは他の人の意見を扱っているので、彼らには1つの解決策しかありません。あなたが独善的な敗者であると彼らに見てほしくない限り、あなたのやり方がそれをするより良い方法であると決して言ってはいけません。
コードレビューまたはペアプログラミングを開始します。
チームがそれらに向かない場合は、毎週のデザインレビューをお試しください。毎週、1時間会って、コードについて話します。人々が防御的であると思われる場合は、少なくとも最初は誰も感情的にならないという古いコードを選んでください。
@ JesperE：言ったように、コーダーではなくコードに注目してください。
違っているべきだと思うものを見ても、他の人は同じように見えない場合は、指摘するのではなく、欠陥につながる質問をすることから始めます。例えば：
Globals：これらのうち複数のものが必要になると思いますか？これへのアクセスを制御したいと思いますか？
Mutable state：別のスレッドからこれを操作したいと思いますか？
また、myの制限に焦点を当てることは有用だと思います。これは人々がリラックスするのに役立ちます。例えば：
long functions：私の脳はこのすべてを一度に保持するのに十分な大きさではありません。どうすれば私が扱える小さなピースを作ることができますか？
悪い名前：明確なコードを読むとき、私は十分に簡単に混乱します。名前が誤解を招く場合、私には希望がありません。
最終的に、目標はあなたがあなたのチームにより良いコーディング方法を教えることではありません。それはあなたのチームに学習の文化を確立することです。より優れたプログラマーになるために、各人が他の人に助けを求める場所。
コード標準のアイデアを紹介します。コード標準に関する最も重要なことは、コードベースの一貫性のアイデアを提案することです（理想的に、すべてのコードは1人で1人で座っているように見えるはずです）より理解しやすく保守しやすいコードへ。
あなたは説明する必要がありますなぜあなたの方法が良い。
機能がカットアンドペーストよりも優れている理由を説明します。
配列が$ foo1、$ foo2、$ foo3よりも優れている理由を説明します。
グローバル変数が危険である理由と、ローカル変数によって生活が楽になることを説明します。
単にコーディング標準を打ち出し、「これを行う」と言うのは、プログラマーになぜそれが良いことなのかを説明しないので、価値がありません。
まず、私はあまりにも迅速に判断しないように注意します。それがそうである理由が十分ある場合、いくつかのコードを悪いものとして簡単に却下することは簡単です（例：奇妙な規約でレガシーコードを操作する）。しかし、今のところ、それらが本当に悪いと仮定しましょう。
チームの入力に基づいて、コーディング標準を確立することを提案できます。しかし、良いコードがどうあるべきかというビジョンを課すだけでなく、彼らの意見を考慮に入れる必要があります。
別のオプションは、技術書をオフィスに持ち込んで（Code Complete、Effective C++、Pragmatic Programmer ...）、他の人に貸し出すことを提案することです（「ねえ、これで終わりです。誰でも借りたいですか？」 ）
可能であれば、あなたが彼らを批判していることを彼らが理解していることを確認してください コード、個人的にではありません。
コードレビューを行い、[〜＃〜] your [〜＃〜]コードをレビューすることから始めます。
コードレビュープロセス全体を簡単に行えるようになります。なぜなら、プロセスを開始するのは自分のコードではなく自分のコードをレビューするからです。コードから始めると、物事を行う方法の良い例も得られます。
非対立的な方法でより良い代替案を提案します。
「ねえ、私はこの方法もうまくいくと思います。皆さんはどう思いますか？」 [画面上の明らかに優れたコードへのジェスチャー]
彼らはあなたのスタイルも悪臭を放つと考えるかもしれません。チームをまとめて、一貫したコーディングスタイルガイドラインのセットについて話し合います。何かに同意します。それがあなたのスタイルに合っているかどうかは問題ではありません。一貫性がある限り、どのスタイルにも落ち着くことが重要です。
例によって。それらを正しい方法で見せてください。
ゆっくりしていく。すぐにすべての小さな間違いのためにそれらをスラッシュしないで、本当に重要なことから始めてください。
コード標準のアイデアは良いものです。
しかしnot何でも言うことを検討してください。特に、おそらくあなたが友達である人々との楽しみのためです。それはただのコードです...
Gerry Weinbergの著書「The Psychology of Computer Programming」にはいくつかの本当に良いアドバイスがあります。「エゴレスプログラミング」という彼の概念はすべて、人々が自分のコードの批判を自分自身の批判とは異なるものとして受け入れるのを助ける方法に関するものです。
悪い命名法：常に言い訳はできません。
そして、はい、常にあなたの方法がより良いと仮定しないでください...それは難しい場合がありますが、客観性を維持する必要があります。
私は、このような恐ろしい関数の命名法を持つコーダーの経験があり、コードは読めないよりも悪かった。関数は何をするかについて嘘をつき、コードは無意味でした。そして、彼らは他の誰かにコードを変更させることに対して保護/抵抗力がありました。非常に丁寧に直面したとき、彼らはそれが貧弱な名前であると認めましたが、コードの所有権を保持したいと思い、「後日」に戻って修正します。これは今では過去ですが、エラーが確認された後、保護されている状況にどのように対処しますか？これは長い間続いており、私はその障壁を突破する方法がわかりませんでした。
グローバル変数：私自身はグローバル変数が好きではありませんが、それ以外の優秀なプログラマーがたくさんいることを知っています。あまりにも多くのことで、多くの状況で実際にそれほど悪くないことを信じるようになりました。明快でデバッグしやすいからです。 （私に火をつけて/投票しないでください:)）結局のところ、グローバル変数を使用する非常に優れた、効果的な、バグのないコードを見たことがあります（私によって入れられない！）適切なパターンを細心の注意を払って使用したコードの読み取り/保守/修正が不可能です。多分そこに[〜＃〜] is [〜＃〜]グローバル変数のための場所（おそらく縮小しますが）？証拠に基づいて自分の立場を再考することを検討しています。
いくつかのウィキソフトウェアを使用して、ネットワーク上でウィキを開始します。
サイトで「ベストプラクティス」または「コーディング標準」などと呼ばれるカテゴリを開始します。
みんなにそれを指してください。フィードバックを許可します。
ソフトウェアのリリースを行うときは、ビルドにコードを配置することを担当する人に依頼して、開発者を押し戻して、Wikiページを指すようにします。
私はこれを自分の組織で行っており、Wikiの使用に慣れるまでに数か月かかりましたが、今ではこの不可欠なリソースです。
コーディングの基準が緩い場合でも、それを指すことができる場合、または正しい形式ではないためにコードを追跡できないことを示す場合は価値があります。
コーディング形式がない場合は、今すぐ適切な形式を使用するのがよいでしょう。この質問に対する答えのようなものが役立つかもしれません： https://stackoverflow.com/questions/4121/team-coding-styles
私はいつも「これは私がやることだ」というラインで行きます。私は彼らに講義したり、コードがゴミだと言ったりするのではなく、明らかにちょっとすてきな何かを見せることができる代替の視点を与えます。
問題の人に、自分が書いた代表的なモジュールのコードに関するグループの他のメンバーへのプレゼンテーションを準備してもらい、Q＆Aにそれを任せてください（私を信じて、それが良いグループであれば、見苦しくもないはずです。
忍耐力を十分に強調することはできません。誰かが今すぐ変更を行うことを望んでいたため、このようなことは完全に裏目に出ました。 ごく少数の環境では、革命ではなく進化の利点が必要です。そして、今日の変更を強制することで、すべての人にとって非常に不幸な環境を作ることができます。
バイインが重要です。そして、あなたのアプローチはあなたがいる環境を考慮に入れる必要があります。
あなたはそれに対して多くの「個性」を持つ環境にいるように聞こえます。だから...一連のコーディング標準を提案するつもりはありません。この「楽しい」プロジェクトを採用して、高度に構造化された作業プロジェクトにしたいということがわかります（すごい、次は...機能的なドキュメントですか？）。代わりに、他の誰かが言ったように、ある程度それを処理する必要があります。
忍耐強く、他の人をあなたの方向に向ける努力をしますエッジ（コードが他のユーザーとやり取りするポイント）から始めて、コードとやり取りするときに、作成したインターフェイスについて話し合い、変更された場合に問題ないかどうかを尋ねる機会としてそれを試してくださいあなたまたは彼ら）。そして、なぜ変更が必要なのかを完全に説明してください（「サブシステムの属性の変更によりうまく対処できる」など）。誤った選択をして、間違っていると思われるものすべてを変更しようとしないでください。 Edgeで他の人とやり取りしたら、彼らはコードの中核でどのように彼らに利益をもたらすかを見始めるはずです（そして、十分な勢いが得られたら、深くなって、真に現代の技術とコーディング標準の利点について議論し始めてください）。それでも表示されない場合は、おそらく自分で処理する必要があります（特に「楽しい」プロジェクトで）。
忍耐。革命ではなく進化。
がんばろう。
私はトーガを着て、ソクラテスの方法の缶を開きます。
ソクラテス法 古典的なギリシャの哲学者ソクラテスにちなんで名付けられた、哲学的探求の一形式であり、質問者は他者の立場の意味を探り、合理的な思考を刺激し、アイデアを照らします。この弁証法はしばしば反対の議論を伴います。反対の議論では、ある観点の防衛が別の観点と対抗します。ある参加者が別の参加者を何らかの方法で自分自身に矛盾させ、照会者自身のポイントを強化する可能性があります。
私はコードが大好きで、情報学に関連することについてライブで講座を受講したことはありませんでした。非常に悪いことから始めて、例から学び始めました。しかし、 Of Four " 本は：
"誰でも機械が理解できるコードを作成できますが、すべてが人間が理解できるコードを作成できるわけではありません"
これを念頭に置いて、コードで行うべきことがたくさんあります;）
私は自分のプロジェクトの主任開発者ではないため、コーディング標準を課すことはできませんが、通常、悪いコードは後で発生するのではなく、より早く問題を引き起こすことがわかりました。
その時に介入せず、より自然なアプローチをとることにより、リードとの信頼関係が高まりました。彼はしばしばアイデアを求め、プロジェクトに使用されるアーキテクチャ設計と展開戦略について私に話します。
悪いコードを書いている人は、無知の兆候にすぎません（これは愚かなこととは異なります）。これらの人々に対処するためのいくつかのヒントがあります。
- 人々の経験は、あなたが言うことよりも強い印象を残します。
- 一部の人々は、自分が作成したコードに情熱を傾けておらず、あなたが言うことを聞かないでしょう
- ペアプログラミングはアイデアを共有するのに役立ちますが、運転している人を切り替えるか、電話でメールをチェックするだけです
- あまりにもwithれさせないでください。継続的な統合でさえ、いくつかの古い開発者に数回説明する必要があることがわかりました。
- 彼らを再び興奮させて、彼らは学びたいと思うでしょう。ロボットを1日プログラミングするのと同じくらい簡単かもしれません
- あなたのチームを信頼し、ビルド時にそれらをチェックするコーディング標準とツールは、しばしば読まれたり、迷惑になりません。
- コードの所有権を削除します。一部のプロジェクトでは、コードサイロまたはアリの丘が表示されます。人々は私のコードであると言い、それを変更することはできません。これは非常に悪いことです。
自分の仕事が悪いと言う人の話を聞くのは好きではありませんが、健全な人なら誰でもメンタリングや不要な仕事を避ける方法を歓迎します。
ある教育大学では、間違いを指摘するのではなく、正しいことに集中するべきだとさえ言っています。たとえば、理解できないコードを不良と指摘する代わりに、コードが特に読みやすい箇所を指摘する必要があります。最初のケースでは、あなたは他の人に下品なプログラマーのように考えて行動するように呼びかけています。後者の場合、あなたは熟練した専門家のように考えるための準備をしています。
ここでの回答の多くは、ほとんどのIDEが選択したスタイルでコードを再フォーマットするため、最近では特に関係のないコードのフォーマットに関するものです。実際に重要なのは、コードの仕組みです。ポスターは、グローバル変数を見て、コードをコピー＆ペーストし、私の命名規則に忠実です。悪いコードなどがあり、フォーマットとはほとんど関係ありません。
良い部分は、そのほとんどが非常に正当な理由で悪いことであり、これらの理由は一般的に定量化可能で説明可能です。だから、非対立的な方法で、理由を説明してください。多くの場合、問題が明らかになるようなシナリオを作成者に提供することさえできます。
彼らにコードを書かせる代わりに、彼らに彼らのコードを維持させます。
蒸し暑いスパゲッティの山を維持しなければならない限り、彼らはコーディングがどれほど悪いのか理解できません。
私は一緒に働いている人たちと同様のシナリオを持っています。彼らは私と同じくらいコーディングに触れることはありませんが、彼らはまだコーディングに役立ちます。
私に彼らがやりたいことをさせて、戻って全体を編集するのではなく。私は通常、彼らを座らせ、物事を行う2つの方法を見せます。この方法から、各方法の長所と短所について議論するため、プログラミングをどのように進めるべきかについて、より良い理解とより良い結論に到達します。
これが本当に驚くべき部分です。時々彼らは私にさえ答えられない質問を思いつきます、そして、研究の後、我々は皆方法論と構造のより良い概念を得ます。
- 話し合います。
- 理由を示す
- あなたが常に正しいとさえ考えないでください。
それが私があなただったらどうするか：D
それはあなたが書いている文化に完全に依存します。フリーソフトウェアプロジェクトでは、彼らは彼らに前向きな提案、それを改善する方法とフィードバックで悪いコードを書いていると伝えます。コードへのパッチを送信することもできます。
フレンドリーなメールも決して痛いことはありません。
プログラマーに依存します。一部の人は、コードが臭いがするのは知っていたが、理由がわからなかったので、実際に「それはうんざりする」と聞きたがっています。
他のプログラマーはもう少し悩まされる必要があります。私は彼らに何か悪いことを言うのは良いことだと思う。 「これはコードを書く良い方法ではありません」に続いて、「ここで、これを行うかどうかを確認してください。読みやすい/警告が少ない/何でも」。建設的な批判が助けになります。自分の口のある場所にお金を入れられず、実際にそれを上手くできない場合は、たとえそれが悪いとわかっていてもコメントしない方がいいでしょう。
両方のアプローチが失敗した唯一の人物は、VBscriptで巨大なマクロを記述し、すべてを逆方向に進めていたスタッボン管理アシスタントでした。彼女は実際、私がコンピュータープログラミングについて何も知らなかったこと、そして私が彼女の1337 sk1l50rzから学ぶことを我慢できることを私に言う勇気を持っていました。
良いスタイルか悪いスタイルかという主観的な意見として却下されるかもしれないものではなく、おそらく悪いコードのimpactに焦点を合わせたいと思うでしょう。
実際に合理的コードである可能性、（あなたがどんな素因を持っているかに関係なく）、または恐らく厄介な状況がある可能性に注目して、いくつかの「悪い」コードセグメントについて個人的に問い合わせてください。コードが単純に悪いだけであり、ソースが実際にこの人であると確信している場合は、そのままにしてください。 1）人が気づき、是正措置を講じる、2）何もしない（気づかない、またはあなたと同じくらい気にしない）。
＃2が発生した場合、または＃1があなたの観点から十分な改善をもたらさず、プロジェクトを傷つけ、および/またはあなたに十分な影響を与えている場合、次の期間内に基準を確立/実施するキャンペーンを開始する時がありますチーム。これには経営陣の賛同が必要ですが、草の根からの刺激が最も効果的です。
それで頑張ってください。あなたの痛みの兄弟を感じます。
私はこれに本当に多くを追加しているわけではありませんが、これへのアプローチで考慮するべき2つの最も重要なことはあなたの推論を説明することであり、問題のコーダーが彼らの推論を説明できるようにすることです。悪いコードはどこからでも来ません（そして、「はい、確かに「悪いコード」は議論のための用語です-この状況では、良いコードと悪いコードを構成するものを定義する立場にあると思います）。
私は、質問をする教育的なアプローチが私のチームでうまくいくことを発見しました。理由についての議論や説明なしに、「このようにしてください」と決して言わないようにしています。
そして、あなたはそれについていくらか敏感であるべきですが、問題をシュガーコートすることはできません。理想は、チームが書いているコードを、コードが何をしているのかという点だけでなく、どのように書かれているのかという点で考えていることです。
最後に、このトピックについて探求する価値のある本が多数あることを付け加えます。この時点で私のお気に入りは、Microsoftの.NET BCLチームのBrad AbramsとKrystof Kwalina（他）による「Framework Design Guidelines」です。行われた決定について議論し、説明するという驚くべき仕事をし、ガイドラインが内部的に守られなかった場所と結果として生じた結果を示します。
私の経験では、WindowsアプリケーションをWebアプリケーションに変更して、それを更新および保守しやすいため、Webアプリケーションを最適化する必要がありました。しかし、私の友人はWindowsアプリケーションの主要な貢献者であったため、彼は変更を許可せず、残りは歴史です。
モラル：コードの最適化とメンテナンスの改善のために、組織の目標を自分の目標よりも重視することは、あらゆるプログラミング環境で重要な役割を果たします。
彼の前でコードをリファクタリングし、2つのバージョンの違いを示します。間違いなく彼はそれを好きになるでしょう。
この問題に対して前向きなアプローチを取ることをお勧めします。同僚に悪いスタイルを使用していると非難する代わりに、スタイルについて提案し、チーム全体が従うことができるコメントのガイドラインを作成します。
たとえば、皆さんが主に.NETショップである場合は、MicrosoftのC＃スタイルとコメントガイドラインを遵守することをお勧めします。これにより、そのコミュニティの標準的な慣行にさらに沿ったものになります。
また、いくつかの例を挙げて、統一されたコードスタイルを順守することもできます。たとえば、コードベースに精通していない人がそれを調べた場合、複数のスタイルを解読する必要はありません。このように考えてください。本を読んでいて、各章が別の人によって書かれたと簡単にわかる場合、いくつかの章を読んで混乱することがありますか？
重要なことは、同僚を否定的に批判しないことだと思います。誰かに変更のメリットを売り込み、くだらないコードを書くことを説得するよりもはるかに簡単にするのが最善です。
率直に言って、誰かのコードは、変更、デバッグ、ナビゲート、理解、構成、テスト、および公開が簡単な方が優れていると思います（ただし）。
つまり、自分のコードが悪いことを、それが何をするのか、または後でそれをどのように強化するのかを説明してもらうことなく、誰かにコードが悪いと伝えることは不可能だと思います（新しい機能の作成やデバッグなど）。
そうして初めて彼らの心はスナップし、誰でもそれを見ることができるようになります：
- グローバル変数値の変更はほとんど常に追跡不可能です
- 巨大な機能は読みにくく、理解しにくい
- パターンを使用すると、コードの拡張が容易になります（ルールに従う限り）
- （など...）
おそらく、ペアプログラミングのセッションがこのトリックを行うはずです。コーディング標準の実施に関しては、それは役立ちますが、良いコードとは何かを本当に定義することからはかけ離れています。
EnderMB's answer が本当に好きだったが、それに追加したかった：
機密性やタブーと見なされるのではなく、コード品質の議論が奨励される環境を育成します。例えば、私はオープンソースプロジェクト（Pythonライブラリ）で作業しました。そこでは、新しいコードとバグ修正がグループと頻繁に議論されます。この方法で行う方が良い」とはいえ、実際にはencouragedであり、高品質のコードを維持するために使用するプロセスの一部です。
すべての環境がこの種のプロセスを助長するわけではないことを理解していますが、それは私たちにとって本当にうまく機能しています。すべてのコードコミットは委員会の会議である必要はありませんが、疑わしいコードや最適でないコードについて話し合い、改善を検討することが完全に受け入れられることを願っています。結局のところ、より良いコードはチームの全員にとってより良いものであり、チームワークの主要な概念は個人のゆるやかなグループとしてではなく、一緒に働くことです。
効果の後、おそらく少し遅れますが、それは合意されたコーディング標準が良いことです。
誰かが明らかに間違いを犯したとしても、人々をやる気にさせ、指導し、敬意を示すことが重要です。しかし、コーチするだけでなく、間違いは間違いであると述べる方法もあるべきです。不正なコードは改善する必要があります。オプションではありません。また、従業員は、監督者の観点から、どのコードが適切であり、どのコードが適切でないかを認識する必要があります。敬意を持って行われるべきであり、改善する責任がある人をやる気にさせます。