コピー/貼り付け/スパゲッティプログラマを変換して光を見る方法は？

この質問はこれに触発されました。他の質問はローカライズされていると見なされていましたが、根本的な問題は業界では非常に一般的なものだと思います。私はこれを読んで私がこのものを作り上げていると思う開発者が何人かいることを知っています、そして彼らは誰もが自分の仕事を気にかけ、学びたい方法を返信するかもしれませんが、他のプログラマーSEの投稿を見るだけです（適切な場合）私はそれが普遍的に真実ではないことを知っています。

たとえば、チームに（または大多数）の標準操作手順がコピー/貼り付けであり、十分な関数呼び出しと変数を追加するだけですべてが解決できると考えている人がいるとします。この人はTDD、DRY、SOLIDのことを聞いたことがなく、仕事で忙しい40時間を超えて、一度も1つの方法論/実践/デザインの本を読んだことがありません。

過去に、私（および他の人）は、どのようにOODを教えるのかと尋ねてきました。しかし今、私はそれが正しい質問ではないと考えています。本当の問題は、そのような人/チームにどのようにアプローチし、物事のより良い方法に興味を持たせるかです。どのように彼らに学ぶよう促しますか？それがなければ、彼らの机に戻っていつもやってきたことを完全に満足していれば、すべての教育、会議、講義、議論は役に立たないようです。

私はそのような多くの人々と仕事をしています。彼らは実際には非常に優秀な人物ですが、「コーディングが終わったので、リファクタリングしてDXMを幸せにするために複数のクラスに分割するだけです」と聞いたときは嫌いです。きれいで、読みやすく、保守可能なコードをリファクタリングしませんが、そうしないとonlyられるだけです。私は彼らが学習できることを知っていますが、やる気の一般的な欠如があるように見えます。

私が仕事を提供するとき、それは一般的にずっと少ないバグを持ち、私が所有する仕事は決してクラスの5000行の怪物になりませんでした。他の人は、「あなたのコードは私たちのものよりもずっときれいで読みやすい」というようなコメントをするので、違いがわかります。しかし、同時に、彼らは何をしていても40時間の報酬を受け取ると信じているので、QAに3日間丸ごと入れてはいけないバグを探しても気にしない最初の場所。または、1つのクラスを変更するのに1週間かかるため、非常に多くの依存関係があり、最終的には触れることになります。ただし、「そのクラスは別の方法で記述されている必要があります」と表示されることはありません。

これらの状況で何かできることはありますか？成功した人はいますか？または、そのような考え方をプロジェクトの重要ではない部分に分離し、損害を最小限に抑えることが最善ですか？

注：「モチベーションの欠如」と言うとき。彼らは単に思いやりをやめたので、仕事をしたり、良い仕事をしたりする動機が不足しているとは思いません。私たちのチームのほとんどは、実際はまったく反対です。彼らは間違いなく製品を気にします。夜と週末に働く人がいます。私が乗り越えようとしているのは、習慣とスキルを改善することです。彼らは実際にはそれほど仕事をする必要はありません。「40時間」のことで、この投稿は少しネガティブに聞こえたと思います。

あなたは自分自身に理由を見つけました：「私は彼らが学習できることを知っています、ただ動機付けの一般的な不足があるように思われます。」

自分の仕事に情熱を傾ける人がいます。また、時には十分な能力を持ち、お金のためだけに働いている人もいます。彼らは自分のものを知っていますが、仕事を楽しんでいません。コードを読みやすくするための追加のリファクタリングや、迅速でspendいハックで問題が解決した場合の興味深い問題の解決に余分な時間を費やすことはありません。

この現象はすべての仕事に存在します。一部の仕事はあまりエキサイティングではありません（彼の仕事を愛し、子供の頃にすでに夢を見ていた会計士を見たことがありますか？）、しかし、プログラミングでは、彼らがしていることを本当に愛している人がたくさんいますProgrammers.SEはかなり空です）。これは、他の情熱的な開発者と毎日話をする情熱的な開発者として、お金のためだけにプログラミングをしている人を見ると驚く機会が増えることを意味します。

私たちは何ができる？多すぎない程度に。すべての場合において、それはあなたではなく、本当にやる気のある人を選ぶ人事です¹。そして、そうでない人を解雇します。

自分で同僚をやる気にさせることはできますが、それは非常に難しいことです。本を読んでもらうと、数週間後に未開封で返却されます。あなたが彼らに助言を与えると、彼らは気にしませんので、彼らは耳を傾けません。²

あなたはできる：

• 上司に会社でいくつかの厳格なルールを設定するように説得してください：スタイルガイドラインなど。これにより、それらの人々はより良​​い仕事をするように動機付けられませんが、少なくとも要件に一致しないソースコードをコミットすることはできません。

• 要件、特に非機能要件に取り組みます。特定のプロジェクトに含まれるILコードの行数が 5000 行未満でなければならないという要件についてはどうですか（いいえ、意味のないLOCについては話していません）³？循環的複雑度またはクラス結合で特定の結果を取得する必要はどうですか？

• 会社でコードレビューを行う時間を増やします。レビュー対象を指定します。チェックリストがある場合は、リファクタリング、読みやすさ、クリーンで有用なコメントなどに関連するポイントを追加します。チェックリストがない場合は、必ず行う必要があります。

• [more] ペアプログラミングを使用します。コードの品質を改善し、意欲の低い同僚をやる気にさせることができます。

• フォグクリークで使用されているものと同様の補償システムを使用します。

^{¹それはインタビューの目的です。あなたを雇用する前に、人的資源はあなたの技術レベルだけでなく、あなたのモチベーションも高める必要があります。悲しいことに、一部の企業はインタビューのこの2番目の部分を忘れており、プログラミングをあまり楽しんでいない人を雇っています。幸いなことに、ほとんどの場合、これらの企業での仕事は決して楽しいものではなく、ジョエルのテストが2を超えることはめったにありません。}

^{² 収入が少なくても、彼らは本当に気にしません。彼の仕事は彼自身の顧客のためのウェブサイトを開発することであると信じている顧客の一人（私はフリーランサーです）にかなり近いです。彼にはデザイナーもいます。生産性を2倍以上高める方法について何度も話しました。有能な人を雇っただけで、収入が少なくとも3増加します。しかし、十分なお金があり、生産性のある人と比較して、品質や無知な顧客への費用を気にしません。}

^{³私が言いたいのは、Visual StudioのCode Metricsに表示されるILコードの行数、つまり実際に何かを意味するメトリックです。本当の LOCは関係ありません、あなたはそれを測定する必要はありません。これは、これまでで最も愚かな指標の1つです。ILのコード行を強制することは、開発者がコードをリファクタリングすることを強制されることを意味します。1行の読み取り不能な行で10行のコードを折りたたむだけではありません。}

「コーディングは完了しました。リファクタリングして複数のクラスに分割するだけで、DXMが幸せになります」。

その考え方は、どのチームにもがんがあり、すぐに面倒を見なければチーム全体のモチベーションを殺してしまいます。もちろん、年功序列および/または功績により、あなたはたまたま技術的権威の地位にあり、あなたのチームに影響を与え、良い実践をもたらす力を与えているという事実に言及しています。

これはすべてうまくいきますが、あなたのチームがこれらのプロセスで明確に販売されていれば、プロセスに対する敬意の欠如とあなたへの敬意の欠如を明確に示すこのような声明であなたを選び出すことはありません。彼らは、これらのベストプラクティスを、チームが独自のメリットを擁護するチームが所有するプロセスではなく、あなたによって引き起こされる障害とみなしています。

前のコメントで、他のチームメンバーは実際にこれらのプラクティスと標準を順守しており、それらを正しく適用していると述べています。最初に彼らからのサポートを強化することに注意を集中し、何がうまくいくか、何がうまくいかないか、彼らが好きなもの、彼らが変えたいと思うものを尋ねてください。あなたがこれを行い、彼らの意見を真剣に受けとめた場合、彼らは上司から受け継がれた手順ではなく、コミュニティの決定であるかのように基準について非常に異なって感じるでしょう。

ソフトウェア開発プロセスまたはソフトウェアの品質をどのように改善したかをチームに指摘することにより、ベストプラクティスと標準のサポートを強化します。

議論のために問題に投票し、結果を文書化します。理想的には、すべての決定は正当性のために全会一致である必要がありますが、強硬な妨害者に対処している場合、これは不可能であり、すべての問題を失速させる可能性があります。この状況では多数決を使用します。大多数が提案された基準と慣行に反している場合、あなたはすでに部屋を失い、その時点でそれをあきらめます。

それらはそれらの標準と手順を所有し、あなたがする必要がないようにそれらを強制します。技術指導者として、あなたは布告と布告を宣言する必要はないはずです。それはリーダーになるための貧弱な方法です。

チームが手順を所有しているように感じたら、特定の手順とベストプラクティスのラベル付けを開始するチームのメンバーは、そのように考えるのは不正です。あなたのチームは、他の人のこの態度を修正するのに役立ちます。

良い質問！答えは、人々がスキルを向上させたくない理由に依存すると思います。可能な答えは次のとおりです。

• 彼らは忙しすぎて何か新しいことを学ぶことができないか、新しいやり方（すべてのテストを書くなど）に時間がかかり、そのための時間がないと思います。明らかな答えは、彼らにもっと時間を与えることでしょう。いつも違うやり方でやっているときに何かを学んだり、TDDのようなことをしようとすると、最初の数回はもっと時間がかかります。あなたのプログラマーがその時間を持っていないなら、あなたは彼らがしようとしていないことを責めることはできません。
• 彼らは自分のスキルについて異なる認識を持っています。つまり、彼らは高品質のコードを作成する非常に優れたプログラマーだと考えています。その信念を粉砕することは非常にやる気を起こさせることができるので、これは難しい心理的な地形です。何らかの種類の非公式の競争が役立つかもしれません（誰が最も少ない欠陥/機能を生み出しますか？最短のコードを生成しますか？コードレビューで最小のWTF /分を生成しますか？）。
• 実際の動機付けの問題があるかもしれません（つまり、彼らは時間を閉じるまで「時間をかけて放っておきたい」）。幸いなことに、これはあまりにも一般的であり、プログラミング関連ではありません。それに対する答えが本当にないからです。
• 彼らは初心者であり、彼らはよく知りません。その場合、トレーニング、コードレビュー、またはチームメンバーが毎月新しい技術書について議論する必要がある「ブッククラブ」が役立ちます。
• 彼らは以前に銀の弾丸を見たことがあり（そして非常にがっかりしました）、彼らはあなたがそれらを売ろうとしているものは何でも理論的には良さそうで実際にはほとんど使われない新しい流行語だと思います。その場合、コードレビューおよびペアプログラミングセッション中に利点を実証することは有効です。あなたがそれをするとき、完全な知識を持たないようにしてください。

最良の解決策は根本的な問題に本当に依存します。たとえば、正式なコーディングガイドライン、評価指標、レビューは初心者には効果的ですが、「自分のスキルに対する認識が間違っている」人々は、彼らは仕事を終わらせるための逆効果的な官僚的な障害として。

本当の問題は、そのような人/チームにどのようにアプローチし、彼らに物事のより良い方法に興味を持たせるかです。どのように彼らに学ぶよう促しますか？それがなければ、彼らの机に戻っていつもやってきたことを完全に満足していれば、すべての教育、会議、講義、議論は役に立たないようです。

それでおしまい！これは確かに本当の質問です。

多少のバックグラウンドを与えるために、私たちは単に多くの正式なトレーニングを行う時間がない-しかし、もしそうなれば、それでもまだ光が見えない。私はしばしば目撃者なので、彼らは彼らに考える方法をほとんど教えません。

質問だから私は彼らにもたらすということではありませんそれらを教える方法が、 - それらを学ぶようにする方法？違いはわずかですが、それがすべての違いを生むものです。

私が正しいかどうかわかりません。しかし、私は映画のマトリックスの対話を信じています-「それは私たちを駆り立てる質問です！」最も重要なことは、彼らに考えさせ、理由を尋ねさせることです！そしてもちろん、大学のコースで良い成績をとったため、すでにいくつかのデザインパターンについてすべてを知っていると考える人のほとんどは、そこで最も困難です。

どのようにして彼らにそのような質問をさせますか？私の一般的なアプローチは、「泳ぐことを学ばせたいなら、池に投げ入れる」ことです。私は人々が同意しないかもしれないことに同意します。そして、私は喜んでそれらに同意しないことに同意します。池に投げると、実際には自動的に泳ぐことを学びません。しかし、それは彼らに考えさせるサバイバル本能を引き起こします-それが起こると、彼らは自然にHOWとWHYを考えるでしょう。

私が人々に与える実用的な例は、彼らがそれを手に入れたいと思っているよりも非常に複雑なプロジェクトに彼らを入れて、彼らに彼ら自身の戦いと戦わせることです。彼らがコードを解き始めて、それを追跡するのが難しいと思うと、あなたは彼らが良い質問をし始めていることに気付きます。

これは少し過激に聞こえるかもしれませんが、リソースの無駄遣いに聞こえるかもしれません。そして、私はこれをしないようにアドバイスしてくれる人が他にもたくさんいると確信しています。しかし、これは私のために働いています！

どの有料パッケージやHRタグを割り当てても、基本的な動機付けの問題は解決しません。その唯一の道は、彼らが挑戦されることです。この基本的な人間の精神に火をつけると、他のすべてが機能します。それができないなら、それはゆるいゆるいゲームです。

PS：ついでにhttps://softwareengineering.stackexchange.com/questions/127021/how-do-you-train-freshers/127034に答えを投稿しました。主にほとんどの人は、どういうわけか企業はリソースを無駄にする余裕がないと信じています！きっと、この答えはここでも同様の扱いになるでしょう。しかし、真実は、人々に仕事をさせ、良い仕事をすることを信じさせることは、コースのシラバスをどのように作成するかについての人間心理学の主題です。

とにかく、あなたがここで説明している仕事は、大きな変化を起こすための内なる情熱に火をつけることになります。そして、システムが大きくなるほど難しくなります。私はまだやる気のない精神で組み込まれている若いフェローから始めて、現状に挑戦してください。

あなたが指摘するように、その動機。彼らが知らないのを気にしないと間違えないでください。彼らは何をすべきかを明確に知っています。 彼らはただ気にしない。もしそうなら、ここでの本当の質問は...あなたの経営者が彼らをそんなにやる気にさせないように間違っているのは何ですか？チームの最新メンバーですか？おそらく彼らはこれまでにこれをすべて経験したことがあり、経営陣からの問題につながるだけでした。したがって、彼らは、仕事を続けるために必要な最小限の仕事に専念しているだけです。

これは管理とリーダーシップの問題だと思われます-そのチームがあなたのチームのコア属性である（個人的およびコードの）改善に取り組むことができるなら、問題はあなたの管理によってサポートされるでしょう-時間がかかるものをやりたいと思うでしょう（新しい技術的負債を減らすべきであり、既存の技術的負債を返済するので、彼らは純利益を得るでしょう）。

だから、あなたはチームに改善を望んでいると主張し、これが良いことであるという合意を得て（チームは全体として、コードの品質を改善するために働く）、あなたはそれを作るためにプログラムを開始する起こる-それはとても簡単に聞こえます...私はそうではないことに気づいています！

これには、教育と労働慣行という2つの部分があると思います。

• 教育は週に1回ランチタイムに開始できます。全員が一緒に食事をし、Q＆Aで20〜30分のプレゼンテーションを行います。あなたが望む基本から始めます-SOLIDは最初の2〜4週間を占めることができます-時間が経つにつれて、あなたはチームに交代で話すようになり、あなたはあなたの間で誰が何を話すかを決める方法を考え出すことができます。スピーカーに仕事の準備時間を与えます。それを超えて、ローカルユーザーグループの参加を奨励します（可能な場合は、少なくとも部分的にソーシャルなものにすることによって）
• 作業慣行...まあ、それはあなたが今していることとあなたが持っているツールに依存しますが、あなたはコーディング標準の同意、ピアコードレビューの導入（堅実ですか）、ユニットテスト（必ずしも最初にテストする必要はありません）を見たいかもしれません、継続的インテグレーションサーバーを実行し、（単体テストに加えて）より自動化されたテストを検討します。ただし、これらは実質的に同意/同意で導入する必要があり（ビルド/ CIサーバーではありません！）、チームとして品質を向上させる必要があります。改善できるものは常にあります（Kaizen）

また、かんばんを見る価値があります（変更/改善の推進力と見なされています）。

最後に考えたのは、私は職業プログラマーであり、私のチームは同じにしたいのです が、週に40時間以上働くことは実際には良いことではないので、目標を達成するチームを作ることです。効果的かつ十分に正常な作業週間以内に、これの点で作業慣行を改善するための引数が、それは可能性が高いなどということである：バグ修正はあなたに自信を与えます（前に）それは時にユニットテストを追加することができない場合を実証することです一定; ビルドサーバーがあると、ソリューションをクリーンにビルドする能力に自信があります。そのビルドが展開パッケージも生成する場合、展開が劇的に簡素化されます。定義上、SOLIDコードは変更が簡単です。全面的に技術的な負債が少なく、返済額が少ないほど...

30年前に偶然プログラミングに陥りました。私は、他の人のコードを維持/サポートするために割り当てられることにより、基本的なソフトウェアエンジニアリングの原則を学ぶ意欲がありました。これらの課題では、コードリーダーがコードをどのように経験するか、コードリーダーに共感する方法を学びました。貧弱に書かれたコードの苦痛を他の人に与えたくありませんでした！

他の人のコードを維持/サポートするために新しいプログラマーを割り当てるこの慣行は魔法の弾丸ではなく、固体コードを頻繁に生成する方法を学ぶ動機を提供するようです。