同僚にインスピレーションを与えて、より良いコーディング手法を採用しますか？

で、私の時代遅れの同僚の取り扱い質問を、様々な人々がいる同僚に対処するための戦略を議論したくないチームで自分のワークフローを統合します。

可能であれば、現代の技術やツールに無知で、おそらく少し無関心な同僚を「教える」ためのいくつかの戦略を学びたいです。

会社の別の部分で、最近まで比較的孤立して働いていたプログラマーと仕事を始めました。彼は幅広い分野の知識を持ち、最も重要なことには、多くの候補者が欠けているように見える、優れた問題解決スキルを実証しています。

しかし、私が見た実際の（C＃）コードはVB6時代への先祖返りです。手続き構造、ハンガリー語表記、グローバル変数（の乱用static）、インターフェースなし、テストなし、ジェネリックの不使用、スローSystem.Exception...アイデアが得られます。

このプログラマーは私よりもかなり古く、少なくとも第一印象では積極的な変化を積極的に求めていません。私はそれが主にトピックがどのようにブローチされるのかという問題だと思うので、私は変化に抵抗するとは言いません。

プログラマーは頑固な人である傾向があり、銃を燃やし、コードのレビューと厳格に施行されたポリシーを厳格に施行することは、私が望む最終結果をもたらさない可能性が非常に高いです。これが新しいプログラマーである若手のプログラマーである場合、「メンター」スタンスを取ることについては二度とは思いませんが、経験豊富な従業員を無知な初心者として扱うことには非常に警戒しています（彼はそうではありません-彼はただ分野の特定の進歩に歩調を合わせました）。

穏やかな説得と非物質的なインセンティブを介して、この開発者のコ​​ード品質基準をデールカーネギーの方法で高めるにはどうすればよいでしょうか？敵対的な状況を作り出すことなく、微妙な段階的な変化をもたらすための最良の戦略は何でしょうか？

他の人々、特にリード開発者は以前にこのような状況にあったことがありますか？どの戦略が興味を刺激し、ポジティブなグループダイナミックを生み出したのでしょうか？どの戦略が成功しなかったので、避ける方が良いでしょうか？

明確化：

質問のすべての詳細を実際に読むことなく、個人的な感情に基づいて回答している人が本当にいると感じています。次の点に注意してください。これは暗示されるべきでしたが、現在明示的にしています。

• この同僚は、年齢のおかげで私の「シニア」だけです。彼の肩書き、影響範囲、または組織での年数が私のものを超えるとは言わなかったが、実際には、それらのいずれも真実ではない。彼はLOBプログラマーであり、メイン開発ショップに夢中になっています。それでおしまい。

• 私は新入社員でも、若手プログラマーでも、一晩で会社を変革するという壮大な計画を持った他の未熟なバカでもありません。私は基本的にソフトウェアプロセスを担当していますが、「リーダー」として働いた多くの人が知っているように、責任は必ずしも組織図と正確に相関するとは限りません。

• 私は、どうやって自分の道をたどるのか、地獄に行くのか、満水になるのかを人々に尋ねているのではありません。私が望むなら、それを行うことができ、最終的な結果として、この人はresり、そして/または辞めます。私は変化を促進する社会的で協力的な方法を探していることを理解してみてください。

• 「...グローバル変数...テストなし...投げるSystem.Exception」という言及は、問題が単なる表面的または審美的ではないことを実証することを目的としています。比較的小さなCRUDアプリで機能するプラクティスは、大規模なエンタープライズアプリで必ずしも機能するわけではありません。実際、これまでのコードで実際に統合テストに合格したものはありません。

質問を額面通りに受け止め、私が話していることを実際に知っていることを受け入れ、実際に尋ねた質問に答えるか、先に進んでください。

PS前提に反論するのではなく建設的なアドバイスを提供してくれた人々に心から感謝します。現実世界の体験の方法でもっと多くのことを聞きたいので、私はこれをしばらくオープンにしておきます。

出発点は聴衆を知ることです。ジュニアの同僚を指導することとシニアの同僚に影響を与えることの違いを知っているので、あなたはすでにこれを理解しているようです。

この特定の個人を動機付けるものを理解する必要があります。私のような古いギーザーで機能するものは、古いギーザーでは機能しない可能性があります。

彼は/ティーチ他人を指導するのが好きならば、あなたはで問題にアプローチ可能性が質問を尋ねるような「なぜあなたはこのようにそれを行うのですか？」これにより、新しいアプローチを評価して意見を述べるように彼に依頼できるダイアログが表示されます。

それがうまくいかない場合は、あなたが彼に採用してもらいたいプラクティスやスタイルを使用することで回避できるバグを指摘することができます。バグを見つけ、奨励したい動作がどのように役立つかを示す必要があるため、これにはさらに多くの作業が必要です。

彼が他の人を助けてくれるようであれば、初心者を助けたいという彼の願望に訴えることができます。「今日の子供」は彼のコーディングスタイルを見ることに慣れておらず、そのために彼のコードを破る可能性が高いことを説明します。

時々、あなたは彼の顔に乗って問題を強制する必要があるかもしれません。これらの戦いを慎重に選ぶ必要があります。あなたがより良い方法を持っていることを彼に証明できることがわかっているトピックから始めてください。

あなたは正しい態度を持っていると思います。あなたが既に言った素晴らしいことすべてを言うように注意してください-優れた問題解決スキル、ビジネスの把握など、彼にグループの現在の基準を示すために少し時間をとってください使用して、彼にいくつかの質問をする機会を与えます。

一緒にコーヒーや何かを持ってきて、彼があなたの既存のコードをサポートしやすくし、誰かが彼を助けてもらえるようにすることで、彼が標準に取り組むことは彼に利益をもたらすことを彼に知らせる仕事に取り組まれる（単独で働いている人にとっては大きなプラス）など。

彼が従事し、あなたがあなたがすることをする理由について良い説明を得ていることを確認し、彼が彼がしていたことをしてはいけない理由に焦点を当てないでください。あなたが必要なら他の人を連れて来て、あなたにそれを説明させます。質問やフォローアップがあり、標準の例について参照できるいくつかの場所がある場合は、後で自分自身を利用可能にします。

彼がその後興味がなければ、リンクした最初の質問を参照できます。

それは本当にあなたの上司の仕事です

1. 会社にはコーディング標準が必要であることを認識してください。会社の規模に関係なく、ある程度専門的な会社にはすべてこれがあります。
2. みんなで一緒に座り、標準を作り始めます。そうすれば、誰もが発言権を持つことができ、標準に準拠する意欲が高まります。

マネージャーが自分でこれを実現していない場合、彼らは仕事に適格ではありません。もしそうなら、あなたはそれらに上記の2つ以上のいくつかのナッジを与える必要があります。コーディング標準を持つことの利点は非常に多く、実際に持っていることに対する議論はありません。（一部のプログラマーが「アーティスト」であり、プロフェッショナリズムの範囲に制限されるべきではないと感じている場合は、代わりに美術をする仕事に就く必要があります。）

コーディング標準自体は、何よりもまず、危険な慣行と危険なライブラリー関数の禁止に焦点を合わせるべきです。使用している言語のより安全で純粋なサブセットを目指して作業します。コーディングスタイルは同意するのがはるかに難しく、それほど重要ではないため、コーディング標準を「コーディングスタイル」から解放してください。会社がコーディング標準を作成することを決定し、すぐに{}ブレースを配置する場所についての白熱した議論で立ち往生するのはかなり古典的です。

参考のために、MISRA-C / C ++およびCERT C / C ++ / Java標準の作成方法を確認してください。

まず、この人の働き方を変えたい理由を明確にする必要があります。審美的な理由だけである場合、この人は彼の働き方が実際に機能することを実証しているので、再考すべきだと思います。

ただし、技術的な理由がある場合は、次のような方法でその人物にアプローチすることを検討する必要があります。

面倒な時間と会社のお金を節約する方法を提案します。興味ありますか？

彼らは常に余分な努力を必要とする既存の習慣を変更する必要がある可能性が高いため、これはぶら下がっている果物でなければならないことに注意してください。

あなたが提案のgazillionsを持っている場合でも、1つか2つを選択し、実証した方が良いに変更になること。

これは機能し、さらに提案があるかどうかを尋ねられます。そうでない場合は、損傷は1つまたは2つの提案に限定されます。

成功することが非常に重要であり、それを迅速に行うことに注意してください。

また、注意する必要があります。物事が行われた方法で物事を行う非常に良い理由があるかもしれませんが、あなたはその理由を見るには余りにも新しいです。したがって、あなたの長老に敬意を払い、あなたの提案がより良いと思う前に尋ねてください。あなたは1つか2つを学ぶかもしれません。

状況が非常に急速に悪化するので、彼の顔にならないように強くお勧めします。私はそれが最後の手段として提起されたことを知っていますが、私の経験では、この時点で、開発者は機能的に参加をやめました。

問題を強制すると、個人が敵になり、あらゆるアクションで戦闘を行う可能性があります。それは本当にチームに負の影響を与え、誰かが辞めるか解雇されるまで終わらないでしょう。

この個人が本当にあなたが必要とする/望むドメイン知識を持っているなら、彼らにその知識を文書化してもらいます。

そっと彼にそれを壊すことから始めます：私はあなたがフィードバックを与えることにどれほど経験があり、どれほど精通しているかわかりません。次のことを既に知っている、採用している、または拒否している場合もありますが、とにかくここに進みます。誰かの行動を変えたいときにフィードバックを与えるためのガイドラインがあります。私が考えてきた会話の構造は、（機能しているため）フィードバックを送りたい状況で採用しようとしています。

1. 表示される動作を説明してください。これは具体的な動作でなければなりません。例：「コードで多くの静的変数を使用していることがわかります」
2. それがあなた/あなたのチームに与える影響を説明してください。例：「このようなコードは保守が難しいと思う」
3. 合理的なソリューションを提供します。（可能性のある解決策は他の回答で言及されていますが、この回答のいくつかについては後で触れます。）
4. 彼に解決策を議論する機会を与えてください。彼が解決策についてどう思うか尋ねてください。額面で彼の応答を取ります。あなたは彼にあなたの意見を与えました、そして彼はそれを受け入れるかどうか自由です。*

フィードバックに関する簡単なリソースは、たとえばhttp://managementhelp.org/communicationsskills/feedback.htmで見つけることができます（ただし、Webにはこの種のものが大量にあります）

今、ソリューションの部分では、あなたの答えで読んでいるものから、彼は十分に頭が良く、正しい考え方を持っていますが、彼は現代の優れた実践に遅れをとっています。それらは、そもそも実際にそれらについて学ぶこととは別に、習得するのに時間と労力を必要とするので、彼にそうする機会を提供する必要があります。それはおそらく、学習リソース（ウェブ、雑誌、書籍など）を出発点として収集し、それらを学習する自由時間を彼に提供することを意味します。毎週金曜日の午後、彼がプログラミングスタイルの視野を広げるために彼に与えることを想像できました。人々は相変わらず自分自身を改善したいと考えています。材料と時間を提供してください。彼らはそれをうまく利用します。

おそらく最も重要なことは、一晩で変化を期待しないでください。彼は長い間自分のやり方で仕事をしてきましたが、おそらくかなり上手になったでしょう。物事の新しい方法で同じように良くなるには時間がかかります。そして、しばらくの間、彼はおそらく新しい方法で多くの価値を見ないでしょう。彼の古い方法は、おそらくしばらくの間より効果的でしょう。

*注：会話の面白いところは、モデル化が非常に難しいことです。彼らは自分の人生を持っているので、紙の上ではいいように見えますが、少し濁ってしまう傾向があります。

あなたが物事をどのようにしたいかを説明し、彼があなたが彼に取り組んでもらうプロジェクトの開始時にあなたがプロジェクトのために行ったデザインとアーキテクチャの選択でどのように機能するかを彼に示します。1対1で（プライベートに）座って、彼の以前のコーディングで見た問題と、なぜこのプロジェクトの問題なのかを説明してください。良くするために必要なものを尋ねますが、良くならないことは選択肢ではないことを明確にします。

次に、コードレビューをツールとして使用して、作業方法を調整させます。最初の時間を長く計画し、それよりもなぜこれを好むのかを実際に話し、彼にその理由を説明させます。必ず彼の声を聞いてください。懸念が解決されたと感じるとき、人々はより変化しやすくなります。最初のタスクをやり直し、チームの基準を満たすまでそれを受け入れないように、計画に期待します（ただし、そのことを彼に伝えないでください）。彼があなたが何を期待し、時間の利益のためにそれを滑らせないことを知ったら、彼はおそらくあなたの働き方に回ります。ただし、コードレビューをいくつかの反復の教育ツールとして使用する必要がある場合があります。基準を満たすまで作業を受け入れないことを気にする必要はありませんが、それについてしっかりと一貫性を保つ必要があります。ドン'

64,000ドルの質問は、彼がプロジェクトを予定通りに提供し、機能要件を満たしているかどうかです。もしそうなら、彼はそれを正しくやっている。ソフトウェア開発には客観的な正しい方法も間違った方法もありません。最終的には問題の解決についてです。そして、クライアント/顧客が満足するように問題が解決した場合、定義により、ソフトウェア開発は正しく行われています。

彼のプロジェクトがあれば、それは当然の全く異なる問題になるアレント完成されています。その時点で、スーパーバイザーが変更を加える必要があります。おそらくあなたの意見を反映したものです。しかし、彼があなたのコード感覚の感覚や今日の慣習的な知恵に違反しているからといって、彼がやっていることは「間違っている」という意味ではありません。あなたは「良いコード」の定義の調停者ではありません。結局のところ、彼はあなたのコードについて低い意見を持っているかもしれません。

だから... 実際に彼の仕事に問題がない限り（あなたがそれを示していない）、何もしないでください。開発者として成功するためには、コードを他の開発者のスタイルと統合することを学ぶ必要があります。

結局のところ、彼はここに来て、プロジェクトを仕上げるよりも流行に追いつくことに関心がある、経験の浅い開発者に対処することについて同様の質問を投稿することができました。その視点についてのすべて。

シニア開発者と話をするジュニア開発者として、自分よりも優れたアイデアで彼にアプローチしようとするのは危険です。

これに対処するための最良の方法は、上司がより良い実践をするように説得し、すべてのコードが特定の標準に従う必要があり、ピアコードレビューを通じてそれらの標準に適用されることを彼が決定するかどうかを確認することです。

かなりの部分の人々は（潜在意識レベルであっても）意欲的で、利己的で、防御的です。とにかく。

彼は上司の話を聞く必要があり、彼を好きにする必要もないため、指揮系統は最も安全な方法です。上司を悪者にしましょう、それが彼の目的です。

あなたが上司を売ることができない場合、または彼が上司である場合は、単に彼のバグに対処しますが、あなたのコードの例によってリードします。

できません。

ソフトウェア開発において、人々が気付いていないことをするように促すことはできません。私は経験からこれを頻繁にやろうとしたので、私は経験から話をします。そして、最終的な結果が出るたびに、会社の目には自分の地位が低下します。私の周りの開発文化を現代の慣行に改善しようとするだけで、何も起こらなかった後、私は解雇されたり欲求不満で辞めたりさえしました。

あなたの同僚が無知でなければ、あなたはそれらを見せることができます。しかし、彼らは、より良いコーディング慣行を採用しようと努力するためのソフトウェアとしてのソフトウェアに十分な能力がないか、十分に配慮していないため、あなたができることは何もありません。試してみると、それを無視するか、実際に理解せずにいじくり回してしまう可能性があります。その音から、それはすでにやっていることです。