時代遅れの同僚を扱う
私はかなり若いプログラマーで、中規模の会社のIT部門で働いています。私には同僚がいて、彼は本当に優れたVisual Basic 6プログラマーです。そして私は本当に良いことを意味します。正直なところ。彼は、最初のコーヒーを手に入れてマシンを起動する必要があるときに、バグがほとんどない実用的なアプリケーションを提供できます。彼はそんなに上手です。
事は、私達はチームで働いており、彼の働き方は完全に時代遅れです。彼はソフトウェアのバージョン管理を信じていません（コードが正しいことを確認するだけで、それほどナンセンスなことは必要ありません）。展開を信じていません（実行可能な実行可能ファイルを提供できます。展開方法は、システム管理者が理解するためのものです）。抽象化を信じていません。 （サブルーチンを作成したい場合は、先に進んでください。ただし、そのサブルーチンからサブルーチンを呼び出さないでください。そのようにすると、コードが複雑になり、コードを追跡するのが難しくなります。このようにして、すべてのステップを実行できます。 'または'ええ、確かにそのライブラリを使用してそれを行うことができますが、その方法では何が起こっているのか本当に理解できません '）、そしてOOPを信じていません。 （私たちはVB.netで働いています）
彼は自分の仕事がとても上手で、私よりもはるかに速くアプリケーションを提供できます。しかし、それはチームでは機能しません。私たちの他のチームメンバーは静かで、意見を述べるのは好きではありませんが、彼は同意する傾向があります。私たちのマネージャーは私が正当なポイントを作ると思っていますが、プログラマーではありません。
私は彼が書いたプログラムを維持するのに本当に苦労しており、それは良いチームの雰囲気にはなりません。私にとって何が最善だと思いますか？
これは、真実の到来を知っている "彼は立派な男ですが..."の1つに聞こえます。そして、真実は彼が本当にエンジニアのそれ程上手ではないように聞こえます。優れたソフトウェアとは、作業と開発の速度だけではありません。それはまた、あなたが言及した他のことについてです-保守性、互換性、抽象化（将来の効率のため）など。
つまり、言われているように、問題のある開発者がいるようです。あなたにとってさらに悪いことは、彼が証明されており、おそらく彼のやり方に固執していることです。それで、あなたは何ができますか？
- 彼の周りに働きなさい。
- 彼と同じくらい厳しいスケジュールでプロジェクトを作成するよう努めます。
- そして、それができない場合は、betterの結果を生成します。
- やがて、彼が却下したこれらの実績のある概念は、あなたのために報われ始めます。
一方、あなたが彼のやり方で働くことを余儀なくされた場合は、離れてください。
同僚を変えようとしないでください。あなたは彼を実用的なソフトウェアを提供できる人物として説明しています。チームに統合するのも遅すぎるでしょう。
したがって、2つの選択肢があります。
Adapt自分で。たぶん、時間の経過とともに、ソース管理システムの有用性を彼に納得させることができるでしょうか？ 影響範囲 を増やす必要があります。彼の変化に対する抵抗力が強いほど、必要な時間が長くなります。
teamから自分を削除します。これを正当化する多くのポイントがあります。おそらく、独自のアプリケーションをそのままにして、新しいものに専念する必要があります。companyから自分を削除します。時々、これが唯一の解決策です。
私があなただったら、今すぐ自分のソース管理システムをセットアップします。コードを作成するすべての目的で使用を開始し、他のチームメンバーがアカウントを持ち、アクセスできるように管理します。あなたの他の同僚はおそらくそれを使うことに熱心です。
そのような慣行を信じないあなたの同僚は、説得するのが容易ではないかもしれません。ただし、彼によって作成された、強制的に使用するコードはすべて、バージョン管理に移行して、作業できるようにする必要があります。彼があなたの変更にアクセスする必要があるときは、リポジトリからコードをプルする方法についての簡単な手順のセットを彼に送ってください。
彼をより現代的なプロセスに関与させるために、あなたは戦闘的である必要はなく、彼の上に立つ必要もありません。時には、自分のやり方で行動し、リーダーとして行動する方が、言葉で誰かを説得しようとするよりも効果的です。赤ちゃんのステップ。バージョン管理への応答性が高まった場合は、サブルーチンのリファクタリングとユニットテストの追加を開始して、変更から保護します。テストを自動化し、チェックインしたらすぐに結果にアクセスする方法を示します。
多くの場合、人々は変化を好まないため、ただ抵抗力があります。しかし、変更が段階的に、そして簡単に理解できる方法で彼らに提示されると、多くの場合、そのメリットがすぐにわかります。
何よりも、できるだけシンプルにしてください（Keep It Simple Stupid）。彼が彼自身の条件でこれらの実践に従うことを始めるのを許してください。しかし、あなたを引きずらせないでください。
これは以前に見たことがあります、
そして、私はほぼ賭けをするつもりです。このタイプの男のみ出現「速い」彼は頭の中に試行錯誤した「パターン」のセットを持っているためです。 99％基幹業務アプリの[〜＃〜] crud [〜＃〜]、基本的なものです。
おそらく、彼は自分の既存のコードから大量のコピーと貼り付けを使用しています（何も問題はありません）。
しかし..
彼が遠隔地で複雑な何かに遭遇した瞬間、それは落ちます、なぜですか？それはもはや基本的な「パターン」のいずれにも適合しないからです。
少しチャレンジ...
私は側面でプロジェクトを作成します。これは、OOPおよびコードの再利用から本当に恩恵を受ける複雑なプロジェクトです。
次に、そのプロジェクトを見せて、機能ごとに実装するように依頼します。
それから彼が自分のやり方でコードを実装した場合、彼のコードはほぼ確実に10x倍＆10x uglierになると思います。
私は正直に言って、あなたは彼の良い絵を描いていません。古風な方法、メンテナンスが難しいソフトウェア、新しい作業方法に頑固に、抽象化に反対など
あなたが言ったことから、彼が再利用可能なライブラリと迅速なアプリケーション開発を目的とした設計パターンを使用せずに、主にバグのないソフトウェアをあなたよりも速く生産しているなら、彼よりもあなた自身についてもっと言う...
..彼について..ええ、彼と一緒に仕事をせず、彼の仕事に関連付けられない方法を見つけてください。彼は仕事に対して典型的な利己的な態度を持っているようです。あなたはそのような人と一緒に働くことはできません、あなたは彼らが働いていることを観察し、彼らの後に片付けることができます（現在のように）。
これをビジネス側から見てください。
バグの多いコードを生成するには、より多くの時間がかかります。あなたはより少ない収入を生み出します、それゆえあなたは吸います。
時間の経過とともにこれを元に戻すことができる場合は、これを元に戻すことができます。
しかし、たぶん、たぶん、おそらく、この時代遅れのプログラマーは、実際にバグのないコードの迅速な作成に関するいくつかのことを教えることができますか？多分彼のテクニックはあなたが思っているほど古い学校ではありませんか？
私は、誰かがいくつかの非常に良い実践なしにそのような素晴らしいコードを生成できると疑っています。あなたはそれらの実践を学び、あなたが理解している「ベストプラクティス」と流行のものにそれらを適用することができるかもしれません。
あなたのマネージャーがプログラマーでないなら、彼が理解できる言葉でそれを試してみてください。
そうしないと回復に大きな問題が発生する可能性があるため、私たちはsourecontrolを使用する必要があります
xかなり基本的なプロセスに従うことを拒否するため、時間がかかります。
一方で、完璧に夢中になりすぎないようにしてください。これは、私たちが従わなければならないベストプラクティスです。同僚が追加する必要がある可能性が高いので、ゆっくりと正しい方向に微調整する必要があるかもしれません。
同僚がチームで開発したことがないようです。そのようなソロの第一人者のようなパートナーは、良いグループのダイナミックさを許しません。上司にそれを伝えて、それを行うパートナーの好意と賛否両論について話し合うようにしてください。あなたがそれをより良い方法で素晴らしい方法で行うことができたが、彼が辞任した場合、指揮の悪党に上ってください
そうでないことを証明するために（良い方法で）彼に挑戦し、ツールと実践のクールな側面を彼に見せてください。ひいきにしないでください。
たとえば、多分彼はバージョニングを援助として信じていませんが、ファイルの肥大化を必要とせずに分岐/マージの方法と、いくつかの実験的機能に取り組む方法を彼に示しています。
OOPについては、コマンドパターン、タスクパターン、貴重な時間を節約する方法、チーム全体など、クールで複雑なデザインパターンをいくつか示します。
彼に少しでも興味を持たせないでください...彼は負けたケースかもしれませんが、それでも、あなたにはチームのためのツールがあり、あなたは彼よりも優れています。マネージャーが見ることができるコミットメッセージを表示/メールで送信するリポジトリソフトウェアを使用してみてください。これにより、マネージャーに透明性がもたらされ、同僚が見えなくなります（Mercurialを使用している場合、bitbucket.orgには無制限のスペースを持つ無料のプライベートリポジトリがあります）。
結局、言葉で説得しようとせず、反駁できない行動でそれが頑固な人たちに対処するための最良の方法です私見（逆心理学も時々、笑）。
まあ、あなたが言及したテクニックは明らかに良いですが、あなたはそれらをイデオロギーとして推進しているのかどうかを自問する必要もあります。若いプログラマーは、大学で学んだことについて少し伝道的である傾向があります。 結果のため、これらの手法は優れていることに注意してください。バージョン管理により、同時開発、設計の明確な追跡、開発、テスト、バグ修正の段階が可能になります。プロジェクトが本当に短期的である場合、その多くは単に不適切であり、結果的に俊敏性が低下します。ベストプラクティスがすべての可能なベストプラクティスを使用することを意味するわけではありません。たとえば、少なくとも場合によっては、抽象化は援助よりも明らかに責任を負う可能性があります。バージョン管理は、開発のタイムラインが長く、複雑なコードがあり、複数のプログラマーがいるときに最も理にかなっています。
開始する場所は、再利用の可能性に注意を払うことだと思います。プロジェクトが進むにつれて、共通点、またはより一般的なフレームワークについて考えます。プロジェクトの前に出ようとすることは強力な動きであり、もっとテクニックを働かせてくれるかもしれません...
ここでやったように、上司に話しかけてください。ここには成長の可能性があります-あなたが言うようにあなたの同僚が優れている場合、適切なOOの概念を使用してソース管理と。 。
私は他の人と話し合って、あなたがどこにいるか物事がどのように見えるかについてより広い視野を得ます。多分そこにいくつかの分離があるので、彼のコードは他のものとあまり混合する必要がないので、これを処理できる方法のために彼を自分の領域に分離する可能性があるので、これは開発者ではなく、ディレクターまたはCIOが作成します。
スパゲッティコードが「ああ、それが理由です= OOP can be good！ "ですが、これは、これが自分のツールボックスにどのように役立つかを確認することが非常に役立つことが判明する場合もあります。
アパシーは、私がコードをどのように設計する傾向があるかという点で基本に近いと私が考えるいくつかのことを彼が拒否する理由であるかどうかを確認する別の容疑者かもしれませんが、多分私はクールエイドが多すぎたかもしれません。
「バージョン管理」ソフトウェアが優れている理由について[〜＃〜] everyone [〜＃〜]のプレゼンテーションを監督者に依頼する必要があります。同僚を選抜しないでください。
私は自分がソース管理ソフトウェアに懐疑的です。なぜなら、作業を回避する方法として、人々が常にそれを誤用しているからです。
私の同僚は絶えず合併しており、常にお互いのつま先を踏んでいます。しかし、その利点についての親しみやすい講義は素晴らしいことであり、議論を促進します。