時代遅れの同僚を扱う

私はかなり若いプログラマーであり、中規模の会社のIT部門で働いています。同僚がいますが、彼は本当に優れたVisual Basic 6プログラマです。そして、私は本当に良いことを意味します。正直に。彼は、最初のコーヒーを手に入れてマシンを起動する必要があるときに、バグをほとんど含まない実用的なアプリケーションを提供できます。彼はちょうどいいです。

事は、私達はチームと協力しており、彼の働き方は完全に時代遅れです。彼はソフトウェアのバージョン管理を信じていません（コードが正しいことを確認するだけであれば、そのナンセンスは必要ありません）。展開を信じていません（実行可能な実行可能ファイルを配信できます。展開方法は、システム管理者が判断するためです）。抽象化を信じていません。（「サブルーチンを作成したい場合は、先に進みますが、そのサブルーチンからサブルーチンを呼び出さないでください。そのように面倒になり、コードを追跡するのが難しくなります。 'または'はい、そのライブラリを使用してそれを行うことができますが、その方法では何が起こっているのか本当に理解していません）」と確かにOOPを信じていません。（VB.netで作業しています）

彼は自分の仕事がとても上手で、私よりも早くアプリケーションを配信できます。しかし、チームでは機能しません。私たちの他のチームメンバーは静かで、発言するのは好きではありませんが、彼は同意する傾向があります。私たちのマネージャーは、私が正当な点を挙げていると思いますが、プログラマーではありません。

私は彼が書いたプログラムを維持するのに本当に苦労しており、それは良いチームの雰囲気にはなりません。私にとって何が一番いいと思いますか？

これは、「彼はいい人だけど…」のように聞こえます。そして、真実は彼が本当にエンジニアとしてそれほど良くないように聞こえます。優れたソフトウェアとは、作業と開発の速度だけではありません。また、あなたが言及した他のもの-保守性、互換性、抽象化（将来の効率のため）などについてもです。

そうは言っても、問題のある開発者が手元にいるようです。あなたにとって悪いことは、彼が立証され、おそらく彼のやり方で設定されていることです。だからあなたは何ができますか？

• 彼の周りに働きます。
• 彼と同じように厳しいスケジュールでプロジェクトを作成するよう努めてください。
• できない場合は、より良い結果を生み出します。
• 時間が経つにつれて、彼が却下したこれらの実証済みの概念は、あなたのために報われ始めます。

その一方で、あなたが彼の方法で働くことを余儀なくされている場合は、去ります。

同僚を変えようとしないでください。あなたは彼を、機能するソフトウェアを提供できる人として説明しています。それをチームに統合するにはおそらく遅すぎます。

したがって、2つの選択肢があります。

• 自分を適応させます。たぶん、時間の経過とともに、ソース管理システムの有用性を彼に納得させることができるでしょうか？影響力の輪を増やす必要があります。彼の変化に対する抵抗力が強いほど、より多くの時間が必要になります。

• から自分自身を削除しますteam。これを正当化する多くのポイントがあります。独自のアプリケーションをそのまま維持し、新しいものに専念する必要があるかもしれません。

• から自分自身を削除しますcompany。時々、これが唯一の解決策です。

もし私があなただったら、今すぐ自分のソース管理システムをセットアップするでしょう。あなたがコーディングするすべてにそれを使い始め、他のチームメンバーがアカウントを持ってアクセスできるように管理してください。あなたの他の同僚はおそらくそれを使うことに熱心になるでしょう。

そのような慣行を信じていない同僚は、説得するのが容易ではないかもしれません。ただし、彼が作成したコードを使用することを余儀なくされた場合は、バージョン管理を使用して作業できるようにする必要があります。彼があなたの変更にアクセスする必要があるとき、リポジトリからあなたのコードを引き出す方法についての簡単なステップバイステップの命令セットを彼に送ってください。

彼をより現代的なプロセスに巻き込むために、戦闘的であったり、彼の上に行く必要はありません。言葉を使って誰かを説得しようとするよりも、自分の道を進んで行動を起こすリーダーになる方が効果的な場合もあります。赤ちゃんのステップ。彼がバージョン管理に対してより敏感になり始めたら、サブルーチンのリファクタリングを開始し、変更から保護するために単体テストを追加します。テストを自動化し、チェックインを行ったらすぐに結果にアクセスする方法を示します。

多くの場合、人々は変化を好まないため、抵抗するだけです。しかし、変更が段階的に、そして従うことを容​​易にする方法でそれらに提示される場合、多くの場合、彼らは非常に迅速に利益を見るでしょう。

何よりも、彼にとってそれを可能な限りシンプルにしてください（Keep It Simple Stupid）。彼が自分の条件でこれらの慣行に従うことを許可します。しかし、あなたを引きずり込まないでください。

正直なところ、あなたは彼の良い絵を描いていない。古風な方法、保守が困難なソフトウェア、新しい作業方法に頑固、抽象化などに反対

あなたが言ったことから、彼があなたが急速なアプリケーション開発を目的とした再利用可能なライブラリとデザインパターンを使用せずにバグのないソフトウェアを大幅に生産しているなら、それは彼よりあなた自身についてもっと言います...

..彼について..ええ、彼と仕事をせず、彼の仕事に関係しない方法を見つけてください。彼は彼の仕事に対して典型的な利己的な態度を持っているようです。あなたはそのような人と一緒に仕事をすることはできません。あなたは彼らの仕事を観察し、彼らの後を片付けることができます（現在のように）。

これは前に見たことがありますが、

そして、私はほとんど喜んで賭けています。このタイプの男は、頭の中に試行錯誤された「パターン」のセットがあるため、「速い」ようにしか見えません。基幹業務アプリの99％は基本的なCRUDです。

彼はおそらく自分の既存のコードから大量のコピー＆ペーストを使用しています（それは何も問題はありません）。

しかし..

彼がリモートで複雑な何かに出会った瞬間、それは落ちます、なぜですか？基本的な「パターン」のいずれにも適合しないためです。

ちょっとした挑戦...

私は、OOPとコードの再利用から本当に恩恵を受ける複雑なプロジェクトをサイドで作成します。

次に、そのプロジェクトを見せて、機能のために機能を実装するように依頼します。

彼のコードを自分の方法で実装した場合、彼のコードはほぼ確実に10倍大きく、10倍くなると思います。

これをビジネス側から見てください。

よりバグの多いコードを作成するのに時間がかかります。あなたはより少ない収入を生み出すので、あなたは吸う。

時間の経過とともにこれを元に戻すことができる場合は、これを元に戻すことができます。

しかし、多分、たぶん、この時代遅れのプログラマーは、コードの迅速な作成に関するいくつかのことを実際に教えることができます。たぶん彼のテクニックはあなたが思うほど古い学校ではないでしょうか？

誰かがいくつかの非常に良い慣行なしにそのような素晴らしいコードを生成できると疑っています。あなたはそれらの実践を学び、あなたが理解する「ベストプラクティス」と流行の事柄にそれらを適用することができるかもしれません。

あなたのマネージャーがプログラマーでない場合は、彼が理解できる用語でそれを試してみてください。

• sourecontrolを使用する必要があります。そうしないと、回復に大きな問題が生じる可能性があるからです。

• 彼はいくつかのかなり基本的なプロセスに従うことを拒否しているため、x時間もかかります。

一方、完璧に追い込まれないようにしてください。これは、従わなければならないベストプラクティスです。同僚には追加することがたくさんある可能性がありますが、ゆっくりと正しい方向に彼を微調整する必要があります。

同僚はチームで開発したことがないようです。そのようなソロの第一人者のようなパートナーは、優れたグループダイナミクスを許可しません。ですから、それについて上司に伝え、それを行うパートナーの熱意と賛否両論について話し合うようにしてください。あなたがもっと素晴らしい方法でそれを行うことができたが、彼が辞退した場合、指揮官のカインに上がる

ここでやったように、シンプルでシンプルなマネージャーに話してください。ここに成長の可能性があります-あなたが言っているようにあなたの同僚が良いなら、適切なオブジェクト指向の概念でソース管理と.Netの使用に変換し始めるように彼をあまり説得してはいけません。

私は他の人と話をして、あなたがどこにいるのかをより広く理解してもらいたいと思います。おそらくそこにいくつかの分離があるので、彼のコードが他のコードとあまり混ざり合う必要はありません。これは、彼が自分の領域に分離する可能性があるからです。開発者ではなく作成するディレクターまたはCIO。

スパゲッティコードが「Oh、だからOOPの理由」になりうる多くのビルディングブロックがある傾向があるいくつかの大企業システムがあるため、彼とどのような大きなシステムを構築したかを見ることができます。いいかも！」ただし、これがツールボックスでどのように役立つかを確認するのに非常に役立つ場合があります。

アパシーは、それが彼が私がコードをどのように設計する傾向があるかという点で基本に近いと思ういくつかのことを拒否する理由であるかどうかを確認する別の容疑者かもしれませんが、多分私はあまりにも多くのKool-aidがありました。

彼に（良い方法で）挑戦して、そうでないことを証明し、ツールと実践のクールな側面を見せてください。ひいきにしないでください。

たとえば、バージョニングを支援として信じていないかもしれませんが、ファイルの肥大化を必要とせずに、どのように分岐/マージし、いくつかの実験的な機能に取り組むことができるかを示します。

OOPに関しては、コマンドパターン、タスクパターン、貴重な時間の節約方法、チーム全員など、クールで複雑なデザインパターンを彼に見せてください。

あなたが彼に少しでも興味を持っていないなら...彼は失われたケースかもしれませんが、それでもあなたはあなたのチームのためのツールを持っていて、あなたは彼を凌ぐことができます。マネージャーが見ることができるコミットメッセージを表示/電子メールで送信するリポジトリソフトウェアを使用してみてください。これにより、マネージャーに透明性がもたらされ、同僚が写真から外れるようになります（mercurialを使用する場合、bitbucket.orgには無制限のスペースを持つ無料のプライベートリポジトリがあります）。

最後に、言葉ではなく反論できない行動で説得しようとしないでください、それは頑固な人IMHOに対処するための最良の方法です（逆心理学も時々動作します、笑）。

さて、あなたが言及するテクニックは明らかに優れていますが、イデオロギーとしてそれらを推進しているのかどうかも自問する必要があります。若いプログラマーは、大学で学んだことについて少し福音主義的な傾向があると思います。これらのテクニックは結果のために良いことを覚えておいてください：バージョン管理により、同時開発、設計、開発、テスト、バグ修正段階の明確な追跡が可能になります。あなたのプロジェクトが本当に短期的なものである場合、その多くは単に不適切であり、俊敏性を低下させることになります。ベストプラクティスとは、考えられるすべてのベストプラクティスを使用することを意味するわけではありません。例えば、抽象化は、少なくともいくつかの場合、間違いなく援助よりも大きな責任となります。バージョン管理は、開発のタイムライン、複雑なコード、複数のプログラマーを拡張したときに最も意味があります。ある種の相乗効果があります。

開始点は、再利用の可能性に注意を払うことだと思います-プロジェクトが進むにつれて、共通性、またはより一般的なフレームワークについて考えます。プロジェクトの前に出ようとすることは強力な動きであり、より多くのテクニックで作業できるようになるかもしれません...

ソフトウェアを「バージョン管理」するのが良い理由について、全員にプレゼンテーションを行うようスーパーバイザーに依頼する必要があります。同僚を独り占めしないでください。

私はソース管理ソフトウェアに懐疑的です。なぜなら、仕事を避ける方法として、人々がいつもそれを誤用しているからです。

私の同僚は絶えず融合し、常にお互いのつま先を踏んでいます。しかし、その利点に関する親しみやすい講義は良いことであり、議論を促すでしょう。