自分に割り当てられた3つ以上のバグを頭の中に入れておくことができないのは普通ですか？また、1,000行のスパゲッティコードを理解することはできませんか？

私は古いコードベースに取り組んでいます... 完璧ではありませんが、どちらの環境にもありません。私の人生で見た最悪のコードベースではありませんが、まだ多くの問題があります。ユニットテストはありません。コードが数千行以上あるメソッド。基本的なオブジェクト指向の原則の誤解; 等

コードを維持するのが痛い。

1. 変数を全面的に再利用して、ひどく記述されたメソッドの何千行もデバッグする必要があるたびに、私は完全に失われます。
2. 私がやったいくつかの修正やリファクタリングは、アプリケーションの他の場所にバグを導入しました。
3. ドキュメンテーション、テスト、または観察可能なアーキテクチャがなく、不適切な名前のメソッドと組み合わせて、使用可能な作業メモリをすべて使い果たしたと感じています。変更する必要があるコードを理解するために覚えておく必要のある他のすべてのことをする余地はありません。
4. 職場での絶え間ない中断は私を邪魔し、私を遅くします。
5. バグ追跡システムがなければ、一度に2つまたは3つ以上のタスクを思い出すことはできません。週末にかけてすべてを忘れます。

私の同僚も同様の問題を抱えていないようです。

1. 彼らは私よりもはるかに速く、ひどく書かれたメソッドをデバッグすることができます。
2. コードベースを変更するときよりもバグが少ない。
3. 20種類のファイルで数千行のコードを読み取る必要がある場合でも、コードを変更するために必要なすべてを非常によく覚えているようです。
4. 彼らは、電子メール、呼び出し中の電話、周りで話している人々、および彼らに質問する他の人々によって邪魔されていないようです。
5. TFSを使用しているので、彼らは既に持っているバグ追跡システムを使いたくありません。彼らは行うべきすべてのタスクを覚えていることを好みます。

なぜこれが起こるのですか？ひどく記述されたコードを長時間操作するときに開発者が習得する特定のスキルですか？私の相対的な悪いコードの経験の欠如は、これらの問題/感情に貢献していますか？記憶に問題がありますか？

はい、構造化された人々が非構造化コード/環境の影響を受けるのは正常です。同僚は、おそらくすべてのバックグラウンドノイズを除去する方が良いでしょう。片頭痛の患者として、片頭痛が来ると、自分の環境を除外する能力が大幅に低下することを知っています。人によって異なります。

同じことはコードにも当てはまります。同僚はおそらく、単一のメソッドで複数レベルの抽象化から生じる「コードノイズ」をフィルターで取り除くことを学び、機能のより大きな領域にコードを「チャンク」することに熟達しているでしょう。

記述したようなコードベースに適応するには、時間がかかります。あなたの同僚は、おそらくもっと成長する時間があり、おそらく「コードベースの初心者」に飛び付かないような慣習、パターン、および構造を理解しているでしょう。あなたが想像できる以上に、カオスにはもっと多くの構造があるかもしれません。同僚と話をして、時間をかけてペアリングしてもらい、割り当てられたバグの1つを解決する方法について彼らの頭脳を選んでもらいます。ユニットX、Y、またはZを開くように求められたら、その理由、関連性があると伝える理由などを尋ねます。

1000行の方法で失われるのは正常です。優れた折りたたみエディタを使用して攻撃し、コメントを追加して、実際にそうすることなく、さまざまな部分を関数や手順に分割します。ものを印刷して、昔ながらの蛍光ペンを使用することも役立ちます。

単体テストのセーフティネットなしでのリファクタリングは、足を踏み入れることです。しないでください。しないでください。

誰もあなたがすべてをメモリに保持する必要はありません。同僚がバグシステムを必要としない、または必要としない場合は、自分に割り当てられたタスクを自分のToDoリストに記述し、タスクの詳細について誰かと話すとき/後にメモを書きます。

私が見る3つの主要なポイントがあります：

ポイント1、2、および3は、同僚がコードベースに精通しているという事実から生じています。つまり、同僚がその癖を知っているということです。これは、デバッグプロセスに長期メモリを使用し、doXYZが実際にUVWを実行しますが、歴史的な理由で名前が変更されなかったことを思い出すことができることを意味します。ただし、コーディングに数か月かかる場合は、あなたの痛みを感じ始めます。

ポイント4は中断に抵抗するため、緊急でないビジネスがゾーンからあなたを連れ出さないようにしてください。中断後、そこに戻るには長い時間がかかります。会社のIMをビジーに設定し、コーディングだけの長いブロック（午後）でスケジュールしてみてください

5秒間は、現在作業中のバグを個人的なTodoリストとしてExcelシートを作成します（またはIDEのタスク管理機能を使用します）。

私にはメモリの問題のように聞こえません。あなたの仕事の習慣/傾向はあなたが遭遇しているものによく適合していないように聞こえます、そしてあなたはあなた自身ではなくあなたの同僚について考えすぎています。

1. 千行法-もし彼らがただそれに取り組んでいない限り、誰もがその上で失われるでしょう。彼らはそれを拾ったり、取り戻したりするのが速いかもしれません。経験を除いてそれを変更することはできません。

2. バグを導入するリファクタリングは、それは常にリスクです。変更する前に単体テストを開発して、変更をカバーすることができますが、それは管理者によって許可されていない可能性があります（おそらく許可されていないか、すでに行われています）。また、単体テストはまだ見逃す可能性がある魔法ではなく、バグを導入することもできます。おそらく、リファクタリングしていないだけです。これは（1）に戻り、おそらく修正が必要なものだけに焦点を合わせようとします。つまり、より速くポイントに到達しますが、全体像を逃し、その千行混乱の次のものを修正するのに時間がかかります。

3. 仕事を完了するために必要なものを作成します。それがフローチャートまたは他のドキュメントを作成することを意味する場合、そうします。必要かどうか、作成後に使用するかどうかは関係ありません。

4. 中断は皆を遅くします。それに焦点を合わせると、さらに遅くなります。それを受け入れて、できるだけ早く溝に戻ろうとします。

5. 2つまたは3つのバグを念頭に置いておくと、3つまたは4つの方が悪いことではありませんが、それを改善するのではなく、あきらめて書き留めてください。一枚の紙、ホワイトボード、tfs、Excel、ワード、またはメモ帳-書き留めてください。それはあなたの同僚がやっていることだと思います。それか、ランダムに修正します。

プログラミングは完璧な記憶に関するものではなく、気晴らしを無視できるということではありません。これに焦点を合わせるのは、あなたが作り出している気晴らしだけです。

警告/更新：以下の回答を読んだ後、少しきついと感じるかもしれません。私の意図ではなく、あなたが説明する環境はひどいものであり、ほとんどの人に影響を与えます（おそらく、より優れたプログラマでも苦しむでしょうが、同じ環境で他の人と比較することで「より良い」）。私の答えは、あなたの質問に点ごとに反映することです。環境は（たとえそうであっても）変わらないと仮定します。

完全に意見の答え：

1）それは、技術の経験、アプリケーションの保守（設計が適切でない場合はさらに）、さらにはアプリケーションの特定の部分に依存します。集中力の問題にも依存します（4番）

2）番号1と同じですが、異なるメトリックを使用しています。同じ答え。

3）ノートブロックとペン。または単語/エクセル文書。それほど難しくありません。

4）それは集中の個人的な問題です。ただし、自分で改善することが可能かどうかはわかりません。

5）チケットシステムを使用するかどうかは、プログラマーではなくプロジェクトマネージャーが決定する必要があります。彼の意見を聞く/あなたのポイントを提示します。彼がそれに反している場合は、再びノートブロックとペン。

私はそのような状況を以前に経験しており、その経験に基づいて、あなたの問題は記憶に関係しておらず、あなたの心に何かがあり（ほとんど確実に仕事に関係していない）、あなたをストレスにさせ、集中を妨げています手元のタスクの％。

そのため、最初のステップは、デスクにいるときにそのようなことから心を取り除くことです。

生産性の面で遅れをとっていると感じているため、そのストレスも増大する可能性があります。同僚と話をして、リファクタリングへのアプローチのヒントを求めてください。

最後に、解決した問題や現在作業中の問題を書き留める必要がある場合（恥ずかしがり屋ではありません）（洗練されたバグ追跡システムである必要はありません）頭のてっぺんからそれを100％確信していない状態で述べるよりも、メモ