私の同僚は彼が働くことを理解していません。何をすべきか？[閉まっている]

私は同僚が作成したライブラリで非常に不明瞭なバグをデバッグするのに3日間費やしましたが、このバグはほとんど発生しません。結局のところ、このバグはロックなしのオブジェクトへのクロススレッドアクセスが原因で発生することがわかりました。実際、これはこの種の最初のバグではなく、以前にも同様のバグがありました。彼はユニットテストを実行するだけで、何かが失敗した場合はどこかにロックをかけます。そして、何も失敗しなければ、うーん、彼のコードは完璧です。彼はスレッド化の安全性について何も考えていないようです。まだ表面化していない類似のバグがたくさんあることは100％確信しています。PMもスレッド処理を理解していないようです。
問題は、彼が私よりもずっと会社で働いていることです。とにかく、「このエリアではこの男は無能だ」と言うことはできません。なぜなら、これは常に「悪いチームプレーヤー」などとして表示されるからです。

そのようなバグを避けるために、スレッドの処理に関するチームのノウハウを改善する必要があることをPMに納得させ、ワークショップやそれに関するプレゼンテーションのようなものを組織して喜んでいると伝えてください。あなたとあなたの同僚の間の個人的なものにしないでください。

バグを示す単体テストを作成し、バグの修正を依頼します。

• 自分のコードを確認して改善を提案するのは、上級開発者の仕事です。
• あなたは彼の仕事の後にチェックするためにそこにいません。
• 彼があなたのアドバイスを受け入れない場合、コミュニケーションの問題を修正するのはPMの仕事です。
• 単体テストのスレッドの問題は、このテストが統合テストやコンポーネントテストではなく、実際に単体テストであるかどうか疑問に思います。

あなたの会社はマルチスレッドを使用すべきではないと思います。

大規模なマルチスレッドプロジェクトを行った後、物事を機能させるには2つの手法が重要であることがわかりました。 最初に、コードを正しく記述する必要がありました。すべてのフィールドを手動でチェックして、参照先が適切に宣言され、適切に同期されていることを確認する必要がありました。（警告：私は私の答えの短いを維持するために少しここでは、物事を単純化しています-またはそれより短い任意のレートで。） 第二に、コードは単一のそれ平らに実行することによってテストされなければならなかったし、マルチコアのマシンを-何分の100％を使用して各コアの。（そして、私がよくやったように、各コアの2％しか使用しない場合、それもバグです。）

これを管理できるかもしれませんが、組織はできません。たとえ彼らが理解していない問題を理解していても、専門知識を持っていません。

ほとんどの言語は、これを回避する方法を提供します。通常は独自のスレッドを持つソケットリーダーを使用している場合は、できる限り迅速かつ簡単にメインスレッドに情報を取得します。さらに良いことに、読みのスレッド部分を処理するシステムクラス/関数を探してください。ほとんどのGUI APIのように、「イベント」を次々に実行するキューを使用します。（その点については、GUI APIのイベントキュー自体を使用してください。）並列処理が必要な場合は、おそらくすべての転送を処理する単一のスレッドでデータ/フィールドを保持できる「ワーカースレッド」を見つけることができます。

マルチスレッドのすべての危険性を強調します。（怖い話：私のお気に入りのバグには、次のような行 int i = 5; i = i * i;が含まれiていました。結果として35の値になりました。私がよく見たのはif (thing != null) thing.reset();、nullポインター例外をスローすることでした。）まったく新しい、奇妙な世界に足を踏み入れて、多分彼らは大きな一歩を踏み出すべきだと。

マルチスレッドがどのように処理されるべきかはわかりません。仕事を一人に任せることができ、失敗したら彼らがすることはすべて捨てられます。しかし、チームは最弱のメンバーと同じくらい強力になるだけであり、優秀なプログラマーでさえ本格的なマルチスレッド化で問題を抱えています。言語の人々がそれを安全にする方法を見つけることを願っています。役に立つソフトウェアをいくつか見ました。しかし、実行時間が重要であり、優れたプログラマーまたは実績のあるチームが利用可能でない限り、マルチスレッドを回避することが最善だと思います。