大規模なコードベースをアジャイルですばやく処理する
私の現在の会社では、私が取り組んでいるプロジェクトは、少なくともシステム/バックエンド部分については、Javaでコーディングされています。 Javaコードを処理するタスクが割り当てられると、すべてを理解してソリューションを適用するのに数時間または数日もかかります。理由は次のとおりです。
1）非常に大きいJava EEコードベース
2）多くの抽象化
3）過去の開発者によって作成されたメソッドなど、すべての抽象化を理解することに夢中になると、他のことを考え、元のソリューションを忘れてしまうような穴に陥りがちです。
私の作業環境は俊敏で、迅速に提供することが期待されていますが、会社のかなり新しいメンバーであり、入社前に構築された巨大なコードベースであるため、「俊敏」なタイミングを満たすことは困難です。
ほとんどすべての行/関数が別の抽象化につながり、それらの中にタイムリーな方法でさらに多くの抽象化があるような巨大なコードベースをどのように扱うべきですか？
編集：私は同僚に尋ねることができることを知っていますが、同時に問題解決は私の仕事の一部であるため、私は常に彼らを悩ませたくありません。
まず最初に、コードベース全体を理解する必要がないことを理解します。抽象化には理由があります。特に証明されていない限り、主張どおりに機能することをほぼ信頼してください。
2つ目は、メモを取ることです。これを行うには、「どこでこの変更を行うか」などのメインの質問を書き、その下にインデントして、メインの質問に答えるために答える必要がある質問を書き、次にその質問に答えるための質問を書きます。 。結局、あなたは答えるのに十分簡単な質問に取り掛かり、そしてあなたは戻ってあなたの方法で作業することができます。
コードベースを確認しないと、コードベースの何が問題になっているのかを知ることは困難です。あなたの説明は、以前の開発者が抽象化に夢中になり、あちこちに適用したかのように聞こえます。これは、開発者が単一の原則またはパターンが優れたソフトウェアの鍵であると考え、使用できると思う場所に無差別に適用する場合に時折発生するようです。私の経験では、基本的に、自由に適用した場合にコードの可読性と保守性を支援する単一の原則、KISSがあります。その他のものは、適度に、適切な判断で使用できます。
ただし、コードベースを変更することはないため、現在の状況ではこれは役に立ちません。 Karl Bielefeldtsの答えはスポットオンです：すべての抽象化パスを葉までたどって迷うことはありませんが、最初は実装が抽象化が約束することを実行することを信頼しています。デバッガーでコードをステップ実行すると、そのようなコードがどのように機能しているかを確認するのに非常に役立つことがわかりました。これは、制御フローが本当に不明確な場合、またはバグを追跡する必要がある場合に実行できることです。
そして、目の前の問題に集中するのに役立つすべてのものを使用する必要があります。複雑でほとんどなじみのないコードベースを扱うことは、集中力に非常に負担がかかるので、メモを取り、気を散らすものやノイズから身を守り、必要に応じて休憩を取り、読んだ内容を消化して、パズルのピースを配置します。
多くのことはすでに言った。私の貢献は：
コードを始めるためのメンターを見つける
この巨大なコードベースをナビゲートする必要があるため、ペアプログラミングを実行するように依頼するか、ソリューションへの道を示すことができます（すべての実装作業を行うわけではありません）。
私の職場環境は俊敏です
あなたがアジャイル環境について言及したので、それはAgile Manifestoの意味でagileであるかどうか疑問に思います（ ここ を参照）。それはアジャイルな方法が価値があるとそこに言っているので：
プロセスとツールに関する個人と相互作用
そしてそれは言う原則のリストで
やる気のある個人を中心にプロジェクトを構築します。
彼らに必要な環境とサポートを与え、仕事を成し遂げることを彼らに信頼してください。開発チームへ、または開発チーム内で情報を伝達する最も効率的で効果的な方法は、対面式の会話です。
これらの2つの原則は、どの方向を探すべきかについてのアイデアを与える可能性があります。必要なサポートを求めてもかまいません。忍耐力の「リソース」を監視し、質問が多すぎる場合は通知することを同僚に信頼してください。
そして、あなたが最初から完璧である必要があるとは思わないでください。
私の作業環境は俊敏であり、迅速に提供することが期待されますが、会社のかなり新しいメンバーとして[...]
これら2つは一致しません。たとえあなたが新しい人であっても、あなたが迅速に成長することを期待している会社で働いているなら、それが起こっている方法がないので、別の雇用者を見つけてください。
ほとんどすべての行/関数が別の抽象化につながり、それらの中にタイムリーな方法でさらに多くの抽象化があるような巨大なコードベースをどのように扱うべきですか？
ツーリング。コードに基づいてUML図を生成するいくつかのツールを見つけます。視覚補助は、クリックするよりもはるかに速くコードベースを学習するのに役立ちます。
編集：私は同僚に尋ねることができることを知っていますが、同時に問題解決は私の仕事の一部であるため、私は常に彼らを悩ませたくありません。
知識を新しい同僚に伝えることも彼らの仕事の一部です。 30分を費やして、同僚に尋ねることで5分で見つけられたかもしれないことを理解しようとする場合、それは全員の時間と労力を節約します。
私が読んでいることを正直に言うと、あなたはあなたが十分に速くないのではないかと心配しています。あなたはそうではなく、それは大丈夫です。雇用主は通常、この種のことを新規採用者に頼っています。だから心配しないで、できるだけ多くの質問をしてください。あなたの理解を深めるかのように、特定のことを知らないことを認めることができることを示し、コードがどのように機能するかについて好奇心旺盛で好奇心があることを示します。
スクラムを使用している場合は、これを毎日のスタンドアップで必ず実行する必要があります。それは障害であり、あなたとあなたのチームはそれを削除しようとする必要があります。これについてスクラムマスターまたは上司と話すこともできます。
チームには、新入社員がソフトウェアに慣れるための計画が必要です。たとえば、広範なドキュメントがあるか、それがどのように機能するかを誰かに説明する必要があります。それが複雑なソフトウェアの場合はなおさらです。
私も同じような状況にあります。幸運を！
ここの人々はあなたにいくつかの素晴らしい実用的な提案をしました。上位レベルのコメントをいくつか追加したかっただけです。
私は同僚に尋ねることができることを知っていますが、同時に問題解決は私の仕事の一部であるため、私は常に彼らを悩ませたくありません。
私たちの開発者の多くは、私たちの問題解決スキルを誇りに思っている人なので、助けを求めるのは不自然に感じられます。あなたはその考え方から自分自身を訓練しなければなりません-時々、助けを求めることは皆の最善の利益になるでしょう（そしてあなたとあなたのチームメイトは邪魔にならない方法でヘルプ/訓練に取りかかる方法を理解することができます）。時間が経つにつれて、物事を拾い、あなたはますます少ない助けを必要とするでしょう。また、レガシーコードで表現された概念の不可解な混乱を整理しようとする活動（-とは見えないもの）はnot仕事の説明の中心にある種類の問題解決です。面倒な作業です。ソフトウェアが作成された実際の問題を解決したい。そのためには多少の面倒な作業が必要になりますが、チームの経験豊富なメンバーからの少しの助けで、より早くそこに行くことができます。したがって、バランスを見つけることが重要です。自分で物事を理解するのに少し苦労すると、物事をより深く理解できるようになりますが、やり過ぎることはありません。
私の作業環境は俊敏で、迅速に提供することが期待されていますが、会社のかなり新しいメンバーであり、入社前に構築された巨大なコードベースであるため、「俊敏」なタイミングを満たすことは困難です。
そこにいなければ、問題の正確な原因を特定するのは困難です。組織はそれぞれ異なります。いずれにせよ、あなたがチームの新しいメンバーであり、コードベースがそうであるという事実のために、何らかの助けやトレーニングが必要になるのは当然です。組織はこれを知っている必要があります。問題は、問題を解決しようとしているが、限られた情報と未検証の前提条件で作業している（つまり、組織がどのように支援できる（またはできない）かわからない）ことを理解しようとしていることです。あなたの問題であなたは、あなたのチームメイトはあなたが彼らを悩ませていると感じていると思います、など）最初に質問してください。これらのことについて人々に話します。次に、オプションが何であるか、他に誰と話をするかなどがわかります。次に、行動する方法を決定するためのより良い位置になります。
ほとんどすべての行/関数が別の抽象化につながり、それらの中にさらに抽象化されているような巨大なコードベースをどのように扱うべきですか？
私が言おうとしていることは、より一般的な発言であり、実際に現在の問題を解決するのに役立つことを意図したものではありません（ただし、新しい視点を提供する場合がある）抽象化について文句を言うとき、それは彼らが概念に不慣れであるか、抽象化自体が間違っていることを意味します。それが最初のものである場合、すばらしい：修正するのは比較的簡単です。これらの概念と考え方を教えることができます。 2番目のケースはそれほど簡単ではありません。おわかりのように、優れた抽象化は構造の複雑さと学習曲線をもたらす可能性がありますが、それらが表す概念と問題領域を理解すると、物事を理解したり操作したりすることが難しくなりません（。それらは、ほとんどの状況下で、クライアントコードのビットを記述する方法を理解するために5レベル深く掘る必要がないように設計する必要があります。実際、（あなたの観点から）5レベルであってはなりません。彼らは、彼らが必要とするよりも複雑であってはなりません。ときどき起こるのは、人々が背後にある推論を実際に理解せずに「ベストプラクティス」を実行することです。その結果、多くの余分な抽象化が生じます。代わりに、抽象化は、開発者の作業を容易にするツールとして、非常に慎重に設計する必要があります。多分あなたはここで余分な抽象化に苦労しています。一方、おそらく元の開発者がそれらを導入する十分な理由があったでしょう。前者の場合、現在の位置とそれがレガシーコードベースであるという事実を考えると、ほとんどそれを行うことはできません。
みんな行ってきました！役立つかもしれないいくつかのこと：
ポーカーの計画
誰がタスクをタイムボックス化していますか？計画プロセスに積極的に関与している場合は、何かにかかる時間に関する情報を入力できます。文字列を引っ張っている上級開発者のチームだけだと、新しい人が何かを引っ張るのにかかる時間を忘れがちです。
単体テスト
コードベースに単体テストはありますか？もしそうなら、何かを壊すことなく変更を加えることができるというある程度の自信を持つことができます。何もない場合は、すぐに赤信号として立てる必要があります。
対象を絞った質問をする
上級開発者は、「これはどのように機能するのですか？」ではなく、特定の質問をすることができる場合は、より支援する傾向があります。テクニカルドキュメント、チートシート、または実際の運用に役立つ何かを依頼することを恐れないでください。
ストーリーまたはスパイク？
プロジェクトマネージャーはスパイクを嫌います。しかし、何かがどれだけかかるかを前もって時間をかけて調べることは、2日かかると言ってから5日かかると言うよりもはるかに優れています。