彼のことを真剣に知っている同僚がいます。彼は私が今まで一緒に働いた中で最も明るい人の一人ですが、彼は：
たぶん、これは「これを知っているのは私だけだと、私を追い払うことはできない」と思っている人の一人かもしれません。
何をすべきかについての提案はありますか？
ところで、経営陣は状況を知っており、物事を変えようとしています。
私の意見では、あなたが上で説明したような愚かなことをしている人は、スター開発者になることはできません! 私には、彼は自分以外の誰もコードを保守できないように、意図的に物事をより複雑にしているように見えます。これにより、彼自身が実際よりも重要になります。彼に話しかける。彼はそれを変更する必要があります ！そうでない場合は、彼を本物のスター開発者に置き換えてください!
半年も経たないうちに、彼は自分のコードがどのように機能するのかわからなくなるでしょう! 彼を解雇すれば、多くの時間とお金を節約できます。
CVS の部分は簡単です。「偶発的な」ハード ドライブの故障は、彼に一生の教訓を教えてくれます (ただし、実際にコードを失うことのないように、必ずバックアップを取っておく必要があります)。
厳しい状況のようですね。
個人的には、私は彼を手放します。彼はスター開発者かもしれませんが、チーム プレーヤーではありません。また、優れた製品を作りたいのであれば、協力できる団結力のあるチームが必要です。
文書化に失敗することは、仕事の安全を確保するための（非常に悪い）方法です。
これに対抗するためにいくつかのことができます。
映画で見た悪い警官/良い警官のスケッチを再生します。経営陣を悪い警官にして、あなたは良い警官にしましょう。管理者に、過剰なドキュメントと、彼の作業の 1 分ごとの ZIP バックアップを要求してもらいます。しかし、あなたは彼に適度なドキュメント (例えば doxygen によるもの) と通常のソース管理チェックインを提供します...
彼に話しかける？
彼が本当に「スター開発者」である場合、彼はあなたの言うことに注意します。
一夜にして彼を変えることはないかもしれませんが、他の人が彼のようにそれを手に入れていないことに完全に気づいていないのかもしれません。
編集：
今すぐ変更するのはおそらく少し遅いですが、解決策を見つけるにはより多くの情報が必要です。ここにいる誰もが、これらの点だけに基づいて男を手放すことを実際に提案することは不可能です。昨年、彼が変わる必要がある、または彼がここから出ていると毎日その男に言っていたなら、あなたは彼を手放すことができます。しかし、その証拠は見当たりません。
優秀な開発者は、ソース管理、コメント、およびドキュメントの使用方法を教えることができます。ここで努力すれば、本当にスター開発者ができます。
あなたはここで間違った領域に焦点を合わせているかもしれません、あなたはあなたのプロセスのいくつかの弱点を見る機会を与えられています。
- 共通のCVSリポジトリではなく、ホームディレクトリの自分の小さな領域で動作します
ここでは簡単なチャットでおそらく十分です。バージョン管理の利点はそれ自体を物語っています。「明るい」人なら誰でも、これらの利点に熱心に取り組むでしょう。ただし、使いやすさと柔軟性を高める代替バージョン管理システムを検討する良い機会かもしれません（bzrとgitを見てください）。さらに良いことに、彼を選択プロセスに参加させてください。彼が本当に「スター」である場合、彼はおそらく良いインプットを持っており、その使用により多くの権利があります。
- 彼のコードを文書化していない
ドキュメントがプロセスの一部であるようには思えません。人々は余分な仕事をしなければならないことに抵抗するでしょう、そして定義されたプロセスがなければ、あなたはたくさんの余分な仕事について話しているのです。ドキュメントは本当に必要ですか？もしそうなら、それを作成するために定義されたプロセスはありますか？あなたはそれに完全に専念する誰かを持っているべきですか？少なくともそれを容易にするツール（おそらくmediawikiのような単純なもの）が必要ですか？
- 彼のコードにコメントしていません。たとえば、Cの3,500 SLOCには、コメントも空白行もありません。
3つの言葉：ピアコードレビュー。明らかなエラーキャッチの利点のほかに、これはまた、強い力であり、良いことである可能性がある、ある程度の仲間からの圧力を提供する可能性があります。あなたの仲間によく認識されたいと思うことは、所有権と品質を自己生成します。
- 多くの場合、物事を複雑にしすぎます。たとえば、1つの単純なシェルスクリプトで実行できる作業を実行するために相互に呼び出す3つのシェルスクリプトを使用します。
繰り返しますが、ピアコードレビュー。あなたは、経営陣がこのプログラマーの欠陥について知っていると言います。彼はいますか？自分のやり方の問題を認識していなければ、人々が変化し、改善することはかなり困難です。
そして、おそらく何よりも、開発プロセスを改善する計画を考え出すことで（これにより、「スター」だけでなく、チームの他の全員も改善される可能性があります）、管理者からゴールドスターを獲得できる可能性があります。
私にはスタープログラマーとは思えません。優れたプログラマーは皆、コードのフォーマットとソース管理の使用が重要であることを知っています。彼は一人で順調に進んでいるように思えますが、他のチーム メンバーの進行を妨げており、それが仕事の遂行に悪影響を及ぼす可能性があります。彼と話し、もし彼が自分の習慣を変えることを拒否するなら、彼を行かせてください。
彼が本当に優秀で、彼のやり方を変えることはできず、彼を失いたくないが、それでもコードを文書化してコメントを付けたい場合は、経験の浅い開発者に文書化とコメントを任せることをお勧めします。個人的には、もし私がスター開発者だったら、他の誰かが私のコードにコメントするようにさせられたら、私はかなりばかげていると思うでしょう。それまでの間、経験の浅い開発者は何かを学ぶかもしれません。
スター開発者になることには、優れたプログラマーであるだけではありません。彼がチームスキルを持っておらず、チームの基準を意図的に無視している場合は、彼にそれを提示する必要があります。彼が経営陣と話し合った後、彼らに固執することを拒否した場合、おそらく彼はあなたの会社にふさわしくありません。
この質問は私を緊張させます。なぜなら、あなたが描写している人物はひどいように聞こえますが、私は彼の中に自分自身が少し見えるからです。
私はかなり良いチーム プレーヤーだと思いますし、とても良いチームに所属できて幸運です。ただし、説明するのにかなり苦労しましたが、同僚が理解できない方法を使用しています。かなり大きな経験のギャップがありますが、それは私たちの誰にも反映されていません.
ドキュメンテーションは広範でトリッキーなテーマです。私は DRY (同じことを繰り返さないでください) の格言に従うようにしています。コードとは別のドキュメントは、同じことを繰り返すことになる可能性があるため、時間をかけて最新の状態に保たない限り、時代遅れになる可能性があります。私の通常のアプローチは、後で修正することです。
多くの場合、私が取り組んでいる問題は非常にトリッキーであるため、計画を進めて必要なすべてを文書化することができますが、コードに関しては、自分が間違っていたことに気づき、再考しなければならないことがよくあります。したがって、事前に文書化して、それに従うだけでよいという考えは、非常に単純な問題に対してのみ機能するように思えます。
とにかく、これは素晴らしい質問だと思います。答えは簡単ではありません。
その男は本当にロックスターですか？真剣に？ちょっと考えてみてください。彼は頭がいいのに物事を成し遂げられないのですか、それとも頭が良くて物事を成し遂げることができるのですか?
本当に一生懸命考えてください。
彼が本当にロックスターなら、彼をいじるべきではないかもしれません。彼は独自のプロセスを使用して信じられないほど素晴らしいものを生み出しています。自分に最適な別の方法があるからといって、それが彼の最高の作品を生み出すことを可能にするわけではありません. あなたのプロセスに彼を屈服させようとするのではなく、彼の素晴らしさをすべて台無しにしてしまう可能性があります。
彼があなたの言う通りに本当に優秀なら、それをしてもかまわないはずです。その努力に見合う価値がないのなら、彼は本当に上手ではありません。その場合、ロックスターではなく、ルールに従うのが嫌いな平凡なプログラマーがいるだけです。それらの人、あなたはただ追い払うべきです。ただし、気まぐれなロックスターは、彼または彼女が生み出すことができるものの質のために、通常は苦労する価値があります. それらの人々は、維持するために多大な努力をする必要があります。
仕事に飽きて物事を複雑にしすぎてやりがいのあるスター プログラマーのように聞こえます。彼はすぐにもっと良いものを見つけるでしょう。
物事を変えようとしていますか？不十分に文書化された動作中のソフトウェアと、十分に文書化されたがらくたのどちらが好みですか? コメントをほとんどまたはまったく必要としないソフトウェアを作成できる人もいますが、これは品質の信頼できる指標ではありません。
良い開発者を失うのではないかと心配しています。
「スター開発者さん、こんにちは。
来週から、コードの文書化とコード内の有益なコメントが必要になることをお伝えするためのちょっとした非公式な注意事項です - これは会社のポリシーになる予定であり、例外はありません。」
それ以降は、時間通りに出社できなかった場合や、仕事中にふざけるのをやめなかった場合などと同じように、その失敗に対処するだけです。あなたの仕事を適切に行っていません。
彼がこのように作業している場合、彼はスター開発者ではありません。優れたソフトウェア開発者は、保守性が非常に重要であることを理解しています。長い目で見れば、あなたはおそらくこれに対して多額の費用を支払うことになるでしょう。私は彼にこれがどれほど深刻であるかについて非常に直接伝え、彼が順応し始めることができない場合は彼を手放します. 私はこれを何度も見てきましたが、時限爆弾です。
正直なところ、私はこのような開発者をたくさん見てきましたが、学校を卒業したばかりでない限り、彼らは変わりません。私は今あなたのロスレスをカットすると言います.
コードドキュメントは過大評価されています。CVSトレーニングは簡単です。
優れたクラスは、そのメソッドとプロパティを通じてその目的を明らかにする必要があります。
アプリケーションの外部でモデルを文書化することも、フローと理解が容易です。
私はそれを彼の注意を引くでしょう、もしあなたがそれを解決することができないなら、あなたはスター開発者を失うことになるように見えます。
編集：おっと-多くのインポートにCVSの代わりにCSVを使用し、私はsvnhehを使用します。
チームは彼なしで成功することができますか？その場合は、問題をプッシュし、適切に文書化されていない、または他の基準を満たしていないコードを受け入れることを拒否します。うまくいけば、これはポイントを理解するでしょうが、それは彼を怒らせ、彼をやめさせるかもしれません。チームが彼なしで成功できない場合は、時間と労力の価値がないかもしれない彼のスキルレベルまで交代要員を訓練できるまで、あなたは運が悪いです。
+1 to ocdecio-彼がスター開発者である場合、彼のコードは、それ自体を文書化するような高品質の設計に基づいている必要があります。
そうは言っても、彼は彼にとって興味深い技術的に要求の厳しい分野では優れていますが、機能の提供にこだわっていないという欲求不満かもしれません-これがあなたの組織にとって問題であるかどうかを知るのはあなただけです。
「達人」を利用できるようにすることは、絶対的な命の恩人になる可能性があります-または少なくとも以前はそうでしたか、StackOverflowはその役割を冗長にしましたか？
コードレビューに合格するまでコードをリリースせず、現在の機能/プロジェクト用に彼が作成したコードに十分なコメントやドキュメントがある場合にのみ、コードをリリースさせてください。
編集彼の評価でそれを持ち出します。ドキュメント/コメントコードは、彼の「改善の領域」のために彼に与えることができます。
:-)
また、十分に文書化されるまでコードをチェックインできないようにする自動品質チェックを追加することもできます。
それは、そもそもチェックインするように彼を説得できればです！（これは必須です、imo）
ここには「コメントがないので、何？」という人がたくさんいます。ここのバンドワゴン。コメントのない文芸的なコードは完全に可能ですが、誰かが賢くてコメントしないからといって、文芸的なコードを書いているとは限りません。
それでは、明確にしましょう。あなたはすでに、彼は自分のコードをコメントでも別のドキュメントでもまったく文書化していないと言いました。また、ソース管理も使用していません。どうですか：
これらすべての質問に対する答えが「いいえ」の場合、大きな問題があります。頭が良いだけでは、必ずしも誰かが資産になるわけではありません。彼が明日あなたの会社を辞めたり、バスに轢かれたりしないという保証はありますか? それが起こったら、あなたはどれほどうんざりしますか？リスクを冒す価値はありますか？
彼が本当に優秀なら、経営陣が彼を追い出す可能性は非常に低い.
もちろん、プロジェクト全体が閉じられるかもしれませんが、とにかく、CVS とドキュメンテーションには何の役にも立たないでしょう。
優れたプログラマーを解雇して、悪いプログラマーを雇うような経営者はいません。
彼が望むときはいつでも管理を取り除くのに役立つと彼に伝えてください.
彼が転職したい理由とは？彼は経営陣に次のように伝えることができます。
これは、どの環境でもかなり一般的だと思います。誰かに自分のやりたいことをやってもらうにはどうすればよいですか？これがまさに「友達を獲得し、人々に影響を与える方法」のすべてです。デール・カーネギーは操作ではなく、人々を管理していました。
彼は経験が浅く、経験と指導が必要なように思えます。
座ってこれらの問題について彼と話すことができると思いますか? 誰かに何か間違ったことをしていると言うことは、しばしば間違ったことのように思えます (特に、他の人の感情を傷つけたくない今日の西洋社会では) が、落ち着いて正直に問題を説明し、それらについて話します。その人があなたとあなたの意見を尊重してくれると助かりますが、これはまったく別の問題であり、上記の本で語られています。これらが深刻な問題であることを彼が理解していることを確認してください。また、将来の開発の仕事では、これらのことも行うことが期待されるため、今すぐ実践することをお勧めします.
次のパフォーマンス レビューまで待つのは得策ではないと思います。たくさんの否定的なフィードバックを積み上げて、それを一度に配信するのは悪い考えであり、それが私に行われたとき、私はそれが本当に嫌いでした.
私の意見では、あなたはこの男を落とす必要があります。彼のコードは読めないようで、彼は間違いなくチームでも安全なプレーヤーでもありません。
また、誰かが自分自身を不可欠であると見なすことができるようにすることも非常に悪い習慣です。あなたが彼にこれを続けさせれば、彼の慣習は良くなるのではなく、悪くなるでしょう。彼が去るとき、誰もがそうするように、あなたはもつれたコードの巨大な頭痛を残されるでしょう。彼が形を整えないのであれば、あなたは今あなたの損失を減らす必要があります。
最後に、この開発者を統治せずに維持することは、後輩の開発者からの悪い例を示しています。あなたが彼らを正しく働かせるならば、あなたは「なぜ彼であり、私ではない」群衆からの恨みの危険を冒します。そうしないと、「スター」のように機能するハックがたくさん発生します。
要するに、彼が非常に迅速に形を整えない限り、開発スタッフ全体の健康と正気のために、彼を落とす時が来ました。
私はその男でした。
私の目を開いたのはプロモーションでした。非常に頭の良い上司が私を「チーム リーダー」にしてくれました。彼は私のコーディングの腕前を認め、チームの他のメンバーが私の基準に達するのを手伝って欲しいと言ったのです (彼は話し上手なバーのスチュワードでした)。それから彼は、「文書化」や「コメント」などを明示的に含まない一連の目標を私に与えましたが、それは必然的に私をその方向に押し上げました. チームの他のメンバーに仕事のやり方を伝えるのが私の仕事だったので、自分でそれをしないというのはちょっと不可能でした。
目標は、「新しい開発者が参加したとき、5 日間で完全に生産性を高める必要がある」などでした。「デプロイは 3 日以内に完了する必要があります」、「コードは外部監査チームによる監査に合格する必要があります」、「継続的な統合と単体テストを実装する」必要があります。
あなたの説明から、この仲間は明らかにスター開発者ではありません。プログラミングはチーム スポーツであり、他の人とうまくプレーできない人は、プロジェクトに大きな価値をもたらしません。
個人的には、6 か月以上前に書いたコードを覚えていないかもしれませんが、ある種のソース管理の変更履歴を非常に重視しています。
この男と定期的にコードレビューを行っていれば、彼があなたが思っているほど優れた開発者ではないことがわかると思います。
彼が「彼のものを知っている」理由は、それがまさに「彼のもの」だからです。最良のコードとは、他のプログラマーが理解して自信を持って変更できるコードです。
他の人を指導せず、自分が理解しているだけのコードを書く印象的なコーダーは、私見では責任があります-特に、十分な質問に答えて、コードを書き直す方法を知って、他の人を助けるためにそれらを送ることができるようになった後.
私はこのスレッドのほとんどの人に同意します。彼をホット スポットに置く 1 つの方法は、チーム コード レビューを行うことです。
最初のコード レビュー ミーティングでは、オープンで推奨事項を受け入れるチーム メンバーからコードを選択します。「スター」開発者は、コード レビューがどのように機能するかを確認する機会があり、次に彼のコードをレビューするようにスケジュールできます。彼に次の会議の準備をする時間を与えてください。それまでに、彼は少なくとも自分のコードにコメントしているはずです。
コード レビューの意図は、人々に恥をかかせることではなく、協力して問題や改善点を特定することですが、スター開発者を論争に巻き込むには良い方法です。
そこで提案したことを実行しないために人を殺すことはできません。彼はただ違う。
if(developer.IsHuman())
{
developer.IsUnique = true;
}
私はゴミを書く (そしてそれをコードと呼ぶ) 人々と一緒に仕事をしています。私もそうします。時々。しかし、すでに感じているように、自分の仕事が他の人に影響を与えることを知っているときに、悪い習慣を変えないのは面倒です。彼をもっと説得してみてください。
そして、あなたが「マネージャー」でない限り、この状況でできることはあまりないと思います。
彼に自動化された実行検証ツールを使用してもらいます。（「妨害者に質問する方法は？ 」で私の回答を参照してください）
複雑すぎて SCC を使用しない場合は、優れた開発者とは言えません。これらはソフトウェア エンジニアリングの重要な部分です。
彼がアルゴリズムのような分野でかけがえのない才能を持っているという非常にまれなケースでは、アルゴリズムの定義など、その分野での作業を彼に割り当て、本物のプログラマーにコーディングをしてもらいます。
静的分析コードを使用して、彼のコードを理解し、クリーンアップします。
ペアプログラミング。あなたが今リストした要件のために彼を「完成」させるhimaペアを見つけてください. あなたは問題を解決し、ソース管理、文書化、彼の行動ごとの質問などを行います。また、最初の男の強みを使用して他の人を訓練します
多くの場合、物事を複雑にしすぎます。たとえば、1つの単純なシェルスクリプトで実行できる作業を実行するために相互に呼び出す3つのシェルスクリプトを使用します。
これは、彼が私に読み書きのできる自己文書化コードを正確に書いているようには聞こえませんが、むしろその逆です。彼が過度に複雑なソリューションを選択したことで、ドキュメントの必要性が非常に高くなり、ドキュメントの欠如がはるかに深刻な問題になっているようです。
他の多くの提案に加えて、試すことができる別のタクトを次に示します。
何らかの理由で、開発者の行動や方法が悪いと考える傾向があるようです。あなたが彼と話し合ったが、彼があなたの満足（または変化する意欲）の正当化を提供しなかったと仮定すると、あなたには2つの明白な選択肢があると思います.彼を追い払うか、それと一緒に暮らすか. この場合、彼がコードをどのように書くかについてあなたの要求を率直に伝え、彼にそれを受け入れるか残すかを選択させることをお勧めします。
例として、以前の雇用主は、（経営陣の再編の後）開発者がコードで「アサート」を使用することはもはや許可されないと判断しました。これは、不要な混乱と現在の「担当者」の既存のスタイルとの一貫性がないと考えたためです。 " グループ (アサーションや防御的なプログラミング手法を使用せずに、非常に直接的な低レベルの C スタイル コードを記述した)。経営陣と直接話し合ったところ、彼らのスタイルに適応するか、去る必要があると言われたので、私は去ることに決めました. 全体として、私はそれが両方の当事者にとって最もうまくいったと思います.
誰もがコーディング、コード ガイドライン、または開発プロセスについて同じ意見を持っているわけではありません。最終的には、お金を払っている人がルールを作成します (実際に何かを作成する必要性とのバランスを取ります)。必要なものについて率直に言えば、開発者はあまり憤慨しなくなります。
しませんか？他のすべてを試した場合は、給料に誰が署名するかを彼に思い出させる時かもしれません.
真剣に！
スター開発者は、バスにひかれて他の誰かが彼のコードに取り組まなければならなくなってから 5 年後、あなたには役に立たなくなります。
CVS を使用しませんか? 私が働いていた会社では、チェックインしなかったために罰金を科し、3回の罰金を科し、あなたは解雇されました. あなたのソース コードはあなたのビジネスです。ソース コードを失うとビジネスを失います。繰り返しますが、彼の給料は会社の基準に従うことに依存していることをこの男に思い出させます.
彼のコードを彼に返して、それを修正するように伝えてください。
コード レビューに失敗します。