彼らが悪いコードを書いていると誰かにどのように伝えますか？[閉まっている]

私は楽しみのために、コーディングプロジェクトの小さなグループと協力してきました。それは組織化された、かなりまとまりのあるグループです。私と一緒に働く人々はプログラミングに関連するさまざまなスキルセットを持っていますが、中には、古いグローバル変数や不適切な命名規則など、古いまたはまったく間違ったメソッドを使用している人もいます。物事は機能しますが、実装は貧弱です。彼らの経験や教育を質問（または侮辱）することなく、より良い方法論を使用するように丁寧に依頼または紹介する良い方法は何ですか？

質問を導入して、彼らがしていることが間違っていることを理解させる。たとえば、次のような質問をします。

なぜそれをグローバル変数にすることにしたのですか？

なぜその名前を付けたのですか？

それは面白い。私は通常、この方法で採掘します。

そのように機能しますか？私は通常、あなたが彼らをばかげて見えるようにする方法を挿入します]

私はこれを行う理想的な方法は、なぜ彼らが特定の方法をコーディングするのかを微妙に尋ねることだと思います。他の方法には利点があると彼らが信じていることに気付くかもしれません。彼らのコーディングスタイルの理由が誤った情報によるものであることがわかっていなかった場合を除き、正当な理由なしに自分のやり方をより良く判断することは決してありません。これについて最善の方法は、なぜ彼らがそのように選択したのかを彼らに尋ねることです。彼らの能力ではなく、攻撃する必要があるからです。

コーディング標準は間違いなく役立ちますが、それがすべてのソフトウェアプロジェクトへの答えである場合、私たちは皆、楽園のプライベートアイランドでカクテルを飲みます。実際には、私たち全員が問題を起こしやすく、ソフトウェアプロジェクトの成功率はまだ低くなっています。問題は主に慣習の問題ではなく個人の能力に起因すると思います。そのため、問題が醜い頭を抱えている場合は、グループとして問題に取り組むことをお勧めします。

最も重要なのは、あなたのやり方が良いとすぐに思い込まないことです。現実にはそうかもしれませんが、私たちは別の人の意見を扱っており、彼らには1つの解決策しかありません。あなたが独り善がりの敗者としてあなたを見てほしいと思わない限り、あなたのやり方がそれを行うためのより良い方法であると決して言わないでください。

コードレビューまたはペアプログラミングを開始します。

チームがそれらを受け入れない場合は、毎週のデザインレビューを試してください。毎週、1時間会議を行い、コードの一部について話します。人々が防御的であると思われる場合は、少なくとも最初は、誰も感情的に愛着がなくなった古いコードを選択してください。

@JesperE：が言ったように、コーダーではなくコードに集中してください。

あなたが違うと思う何かを見つけたが、他の人はそれを同じように見ない場合、欠陥を指摘するのではなく、欠陥につながる質問をすることから始めます。例えば：

グローバル：これらを1つ以上持つ必要があると思いますか？これへのアクセスを制御したいと思いますか？

可変状態：別のスレッドからこれを操作したいと思いますか？

自分の限界に集中することも役に立ちます。これは人々がリラックスするのに役立ちます。例えば：

長機能：私の脳は、これらすべてを一度に保持するのに十分な大きさではありません。どうすれば、私が扱える小さな断片を作ることができますか？

悪い名前：私は明確なコードを読むときに十分に混乱します。名前が誤解を招くとき、私には希望がありません。

結局のところ、目標はあなたがチームにもっと上手にコーディングする方法を教えることではありません。それはあなたのチームに学習の文化を確立することです。一人一人がより良いプログラマーになるための助けを求めて他の人に目を向けるところ。

コード標準のアイデアを紹介します。コード標準について最も重要なことは、コードベースの一貫性のアイデアを提案することです（理想的には、すべてのコードは、1人が1人で書いたように見える必要があります）。

あなたはあなたの方法がより良い理由を説明しなければなりません。

関数が切り取りと貼り付けよりも優れている理由を説明してください。

配列が$ foo1、$ foo2、$ foo3よりも優れている理由を説明します。

グローバル変数が危険である理由と、ローカル変数によって生活が楽になることを説明します。

それがなぜ良いことであるかをプログラマーに説明しないので、単にコーディング標準を書き出して「これを行う」と言っても意味がありません。

まず、私はあまりにも早く判断しないように注意します。正当な理由がある場合（たとえば、奇妙な規則でレガシーコードを処理する場合）は、一部のコードを悪いものとして却下するのは簡単です。しかし、今のところは本当に悪いと仮定しましょう。

チームの入力に基づいて、コーディング標準の確立を提案できます。しかし、あなたは本当に彼らの意見を考慮に入れる必要があり、良いコードがどうあるべきかというあなたのビジョンを押し付けるだけではありません。

もう1つのオプションは、技術書をオフィスに持ち込み（コードコンプリート、Effective C ++、プラグマティックプログラマー...）、他の人に貸し出すことを提案することです（「これで終わりです。誰か借りたいですか？」 ）

可能であれば、個人的にではなく、コードを批評していることを理解してもらいます。

非対立的な方法でより良い代替案を提案します。

「ねえ、私はこの方法もうまくいくと思います。皆さんはどう思いますか？」[画面上の明らかにより良いコードへのジェスチャー]

コードレビューをしており、見直すことから始めYOURコードを。

あなたは彼らの代わりにあなた自身のコードをレビューすることからプロセスを始めているので、それは人々がコードレビュープロセス全体を安心させるでしょう。あなたのコードから始めることは、彼らに物事を行う方法の良い例を与えるでしょう。

彼らはあなたのスタイルも悪臭を放つと思うかもしれません。チームに集まり、一貫したコーディングスタイルガイドラインのセットについて話し合います。何かに同意します。それがあなたのスタイルに合うかどうかは問題ではありません、それが一貫している限り、どのスタイルでも妥協することが重要です。

例として。それらを正しい方法で示します。

ゆっくりしていく。小さなミスをすぐに犯すのではなく、本当に重要なことから始めましょう。

コード標準の考え方は良いものです。

しかし、何も言わないことを検討してください。特に、あなたが友人であると思われる人々との楽しみのためです。それはただのコードです...

Gerry Weinbergの本「The Computer Psychology of Computer Programming」には、本当に良いアドバイスがいくつかあります。彼の「自我のないプログラミング」という概念は、人々が自分のコードの批評とは別に自分のコードの批評を受け入れるのを助ける方法についてのすべてです。

悪い命名規則：常に言い訳はできません。

そして、はい、いつもあなたのやり方が良いと思い込まないでください...難しいかもしれませんが、客観性を維持する必要があります。

私は、このような恐ろしい関数の名前が付けられたコーダーを使った経験があります。コードは判読不能よりも悪かったです。関数は彼らがしたことについて嘘をつき、コードは無意味でした。そして、彼らは他の誰かにコードを変更させることに対して保護的/抵抗的でした。彼らは非常に丁寧に対面したとき、名前が不十分であると認めましたが、コードの所有権を保持したいと考え、戻って「後日」修正しました。これは過去のものですが、エラーが確認されたが保護された場合の対処方法を教えてください。これは長い間続きました、そして私はその障壁を突破する方法を知りませんでした。

グローバル変数：私自身はグローバル変数が好きではありませんが、私はそれらを好きな他の優れたプログラマーを知っています。はっきりしているので、わかりやすくデバッグしやすいので、実際には多くの状況でそれほど問題ではないと思います。（私を非難/反対票を投じないでください:)）結局のところ、私はグローバル変数を使用した非常に優れた、効果的な、バグのないコード（私が入れていない！）細心の注意を払って適切なパターンを使用したコードの読み取り/保守/修正は不可能です。たぶんそこISグローバル変数の（おそらく縮小が）場所は？証拠に基づいて自分の立場を再考することを検討しています。

いくつかのwikiソフトウェアを使用して、ネットワーク上でwikiを開始します。

「ベストプラクティス」または「コーディング標準」などと呼ばれるサイトのカテゴリを開始します。

それにすべての人を指す。フィードバックを許可します。

ソフトウェアのリリースを行うときは、ビルドにコードを入れるのが仕事の担当者に開発者にプッシュバックし、開発者にソフトウェアのWikiページを指示してもらいます。

私はこれを私の組織で行っており、人々が実際にWikiを使用するコツに入るのに数か月かかりましたが、今ではこの不可欠なリソースになっています。

コーディングの標準が緩い場合でも、それを指すことができるか、正しい形式ではないためにコードを実行できないことを示すことは価値があるかもしれません。

あなたがコーディングフォーマットを持っていないなら、今それを整えるのに良い時でしょう。この質問への回答のようなものが役に立つかもしれません：https : //stackoverflow.com/questions/4121/team-coding-styles

私はいつも「これが私がやろうとしていること」という言葉で行きます。私はそれらを試して講義したり、コードがゴミだと言ったりはしませんが、明らかに少しすっきりしたものをうまく表示できる別の視点を与えます。

問題の人に、彼らが書いた代表的なモジュールのコードについて、グループの残りのメンバーへのプレゼンテーションを準備してもらい、Q＆Aがそれを処理するようにします（私を信頼してください、それが良いグループであれば、醜くならないはずです）。

私は愛のコードを実行する、と私は読んで以来、私は非常に悪い開始および例から学ぶために始めたが、私はいつも覚えているし、私の心に留めておくインフォマティクスに関することなら何でも私のライブで任意のコースを持っていなかった「ギャング4分の」された本を：

「誰もが機械が理解できるコードを書くことができるが、すべてが人間が理解できるコードを書くことができるわけではない」

これを念頭に置いて、コードで行うべきことがたくさんあります;）

私は忍耐力を十分に強調することができません。主に誰かが今すぐ変更を加えたいと思っていたので、このようなことは完全に裏目に出ました。かなりの数の環境で、革命ではなく進化のメリットが必要です。そして、今日の変化を強いることによって、それはすべての人にとって非常に不幸な環境を作り出すことができます。

バイインが鍵です。そして、あなたのアプローチはあなたがいる環境を考慮に入れる必要があります。

まるで「個性」の多い環境にいるようですね。だから...私は一連のコーディング標準を提案しません。この「楽しい」プロジェクトを採用して、高度に構造化された作業プロジェクトに変換したいということに遭遇します（すばらしい、次は何を...機能文書ですか？）。代わりに、他の誰かが言ったように、ある程度はそれに対処する必要があります。

忍耐強く滞在し、あなたの方向で他の人を教育するように努めます。エッジ（コードが他のユーザーと相互作用するポイント）から始めて、そのコードと相互作用するときに、作成したインターフェイスについて話し合う機会として、変更されていても問題ないかどうか尋ねます。あなたまたは彼ら）。そして、なぜ変更が必要なのかを十分に説明します（「サブシステム属性の変更をより適切に処理するのに役立ちます」など）。何も考えずに、間違っていると思われるものすべてを変更しようとしないでください。エッジで他の人とやり取りすると、彼らは彼らのコードのコアで彼らがどのように彼らに利益をもたらすかを見始めるべきです（そしてあなたが十分な勢いを得たなら、より深く行き、真に現代の技術とコーディング標準の利点について話し始めてください）。それでも見えない場合は…

忍耐。革命ではなく進化。

幸運を。

私はトーガを食べて、ソクラテス的な方法の缶を開けます。

ソクラテス式問答法古典ギリシャの哲学者ソクラテスの名にちなんで名付けは、質問者が合理的な思考とを照らしアイデアを刺激するために、他人の位置の影響を探るする哲学的探究の形です。この弁証法はしばしば、ある見方の擁護が別の見方に対抗する対立的議論を伴います。ある参加者が別の参加者を何らかの方法で自分自身と矛盾するように導き、質問者自身の主張を強化することができます。

ほとんどのIDEは選択したスタイルでコードを再フォーマットするため、ここでの回答の多くはコードのフォーマットに関するもので、最近は特に関係ありません。本当に重要なのはコードがどのように機能するかであり、ポスターはグローバル変数、コードのコピーと貼り付け、私の慣習、命名規則を見るのに適しています。悪いコードのようなものがあり、それはフォーマットとはほとんど関係がありません。

良い点は、そのほとんどが非常に正当な理由で悪いことであり、これらの理由は一般に数量化可能で説明可能です。だから、非対立的な方法で、理由を説明してください。多くの場合、問題が明らかになるシナリオをライターに与えることもできます。

私はプロジェクトの主任開発者ではないため、コーディング標準を課すことはできませんが、悪いコードは通常、後ではなく早く問題を引き起こすことがわかりました。

当時は介入せず、より自然なアプローチをとることで、私は主導権をより信頼できるようになり、彼はアイデアを求めて私に頼り、プロジェクトに使用されるアーキテクチャの設計と展開戦略に私を含めています。

悪いコードを書いている人は、無知の症状にすぎません（これはばかげたこととは異なります）。これらの人々に対処するためのヒントをいくつか紹介します。

• 人々の経験はあなたが言うことよりも強い印象を残します。
• 一部の人々は、自分が作成したコードに情熱を傾けておらず、あなたが言うことを何も聞きません。
• ペアプログラミングはアイデアを共有するのに役立ちますが、運転している人を切り替えるか、電話でメールをチェックするだけです
• 過度に溺れてはいけません。継続的インテグレーションでさえ、古い開発者に数回説明する必要があることがわかりました。
• 彼らを再び興奮させれば、彼らは学びたくなるでしょう。1日のロボットのプログラミングと同じくらい簡単かもしれません
• チームを信頼し、コーディング標準とビルド時にそれらをチェックするツールは、多くの場合、決して読んだり、煩わしいものではありません。
• コード所有権を削除します。一部のプロジェクトでは、コードサイロや蟻の丘が表示され、私のコードは変更できないと言われます。これは非常に悪く、ペアプログラミングを使用してこれを削除できます。

彼らにコードを書かせる代わりに、彼らに彼らのコードを維持させる。

蒸し暑いスパゲッティの山を維持する必要があるまで、彼らはコーディングがどれほどひどいのか理解できません。

誰かが自分の仕事が悪いと言うのを聞くのは好きではありませんが、正気な人なら誰でも、メンタリングや不要な仕事を避ける方法を歓迎します。

ある学校では、間違いを指摘するのではなく、正しく行われることに焦点を当てるべきだとさえ言っています。たとえば、理解できないコードを悪いと指摘する代わりに、コードが特に読みやすい場所を指摘する必要があります。最初のケースでは、あなたは他人を準備して、くだらないプログラマのように考え行動するようにします。後者の場合、あなたは熟練した専門家のように考えるための準備をしています。

私と一緒に仕事をしている人たちにも似たようなシナリオがあります。彼らは私ほどコーディングに触れていないのですが、彼らはまだコーディングに役立ちます。

彼らがやりたいことをやらせて、戻ってすべてを編集させるのではなく。私は通常、それらを座って、物事を行う2つの方法を示します。ティアーウェイとマイウェイ、これから、各メソッドの長所と短所について説明します。したがって、プログラミングについてどのようにすればよいかについて、より良い理解と結論が得られます。

これは本当に驚くべき部分です。時々彼らは私にも答えられない質問を思い付くでしょう、そして研究の後に私達は皆方法論と構造のより良い概念を手に入れます。

1. 話し合います。
2. それらをなぜ表示する
3. あなたがいつも正しいとは思わないでください。時には、彼らはあなたに何か新しいことを教えるでしょう。

それが私があなただったら私は何をするだろう：D

おそらく影響が少し遅れるでしょうが、それは合意されたコーディング標準が良いことです。

私は率直に言って、変更、デバッグ、ナビゲート、理解、構成、テスト、公開（whew）が簡単であるほど、誰かのコードのほうが優れていると思います。

とは言っても、コードの機能や、後で機能を拡張するために誰かがどのように機能するか（最初に、新しい機能を作成したり、デバッグしたり）を説明してもらうことなく、コードが悪いことを誰かに伝えることは不可能だと思います。

その後、彼らの心は鳴り、誰でもそれを見ることができます：

• グローバル変数の値の変化はほとんど常に追跡不可能です
• 巨大な機能は読みにくく、理解しにくい
• パターンを使用すると、コードを拡張しやすくなります（ルールに違反しない限り）。
• （など...）

おそらく、ペアプログラミングのセッションでうまくいくはずです。コーディング標準を適用することに関しては-それは役立ちますが、何が良いコードであるかを本当に定義することから遠すぎます。

良いスタイルか悪いスタイルかについての主観的な意見として単に却下される可能性があるものではなく、おそらく悪いコードの影響に焦点を当てたいと思うでしょう。

実際に妥当である可能性に目を向けて、いくつかの「悪い」コードセグメントについて非公開で問い合わせますコードで（どのようにあなたがどんなに気分を害していても）である可能性、または恐ろしい状況ます。それでもコードがひどく悪いこと、そしてソースが実際にこの人物であると確信している場合は、そのままにしてください。いくつかのことの1つが発生する可能性があります。1）人が気づき、何らかの修正措置を講じる、2）人が何もしない（気づかない、またはあなたほど気にしない）。

＃2が発生した場合、または＃1があなたの観点から十分な改善をもたらさず、プロジェクトを傷つけている、および/またはあなたに十分な影響を与えている場合、基準を確立/実施するためのキャンペーンを開始するときかもしれませんチーム。それには経営者の賛同が必要ですが、草の根から推進されたときに最も効果的です。

頑張ってください。私はあなたの痛みの兄弟を感じます。