非常に大規模で複雑なアプリケーションを学ぶにはどうすればよいですか？
「実際の」ソフトウェア会社に最近雇われた、若くてかなり経験の浅い開発者であるため、次のことを行う方法についていくつかの意見と指針が欲しいのですが。
特に、すべてがどのように機能するかわからない場合に、企業の製品に慣れる方法へのアプローチ。私が今いる会社には1つの巨大な製品があり、絶えず進化していて、2週間ここにいるのですが、若い開発者の涙と欲求不満から作られた特別な種類の接着剤を除いて、すべてがどのようにくっついているのかはまだわかりません。信じられないほど細分化されており、オフィスの4人だけが内部の仕組みを知っています。
製品に役立つ情報を提供する：さて、私は会社の子供であり、最初の数か月で画期的なものを提供することは期待できませんが、あなたが支払われたのと同じくらい。私は以前の仕事の2倍のペースで動いていますが、客観的に言えば、まだそれに値するものは何もしていません。コードを解読しようとする私のラップトップの画面を見つめていた。これは私がここにいるためだと言ってもいいですが、少なくとも最初はここまでですが、私の前の仕事では、頼りになる人で、決断を下し、会社の日常業務のほぼすべての側面に貢献していました。それはたくさんの仕事でしたが、私は利害関係のある会社の内部の仕組みで「つながっている」という感覚を楽しんでいました（もしそうなら共生関係です）。この点を編集してください重要なことを決めるのは皆さんにお任せします
私はそれらについて思うようにもっと多くのものを投稿しますが、漠然とC＃に似ているものだけを読み書きする必要があります
2週間 ？私の2番目の仕事では、新入社員が 'oh！わかった！'瞬間9ヶ月...
それが本当に巨大な製品である場合、彼らはそれを「手に入れる」のに長い時間を期待し、ただ努力し続け、たくさんの質問をするだけです。
私はそれほど新しい開発者ではありませんが、ソフトウェアがどのように機能するか、またはどのように設計されているかわからない状況に突き当たることがよくあります（設計されている場合）。多くの場合、尋ねる人がいても、彼らは私が知っている以上のことを知らないか、他の何かに包まれています。
最初のステップ-準備をします。開発環境をインストールし、ノートブックを入手し、ホワイトボードを片付けます。設計ドキュメントがある場合は、それらを見つけて参照できるようにします。 @mcottleの答えは素晴らしいものです。システムを理解したい場合は、[テストを受ける]/[他の人に教える]のようにアプローチする必要があります。多くの質問を書き留め、コンポーネント間の関係を描き、驚いたことを追跡します。新しい開発者がシステムの大まかなスケッチをフォーマット（wiki、ドキュメントなど）にまとめる場合、それを開始点として他の新しい開発者に渡すことができます-私の本では100万のブラウニーポイント。
2番目のステップ-ユーザーとしてアプローチします。このソフトウェアは何のためのものですか？それは解決するように設計されていますか？マニュアルを読んでください。これで、先に進むときにコンテキストがわかると思います。
3番目のステップ-システムのエッジを決定します。入力はどこから来ますか？最終結果は？
4番目のステップ-コードベースを介して入力をトレースします。最初のパスの詳細にこだわらないでください。質問を書き留めてください。追加のパスを作成すると、それらの質問に答えて、新しい質問を生成できます。
第5ステップ-システムの継ぎ目を見つけます。ここでのアイデアは、主要なアーキテクチャー層を見つけることです（I/Oまたはネットワーク境界は通常、文書化するのに適しています）。
6番目のステップ-次に、物事をコンポーネントに分解します。システムは、YとZに何が起こっているのか不思議に思うことなくXについて考えることができるように十分にモジュール化されていますか？そうでない場合は、その関係を文書化します。ここから、システムを分割して征服し、「十分に」理解するまで各コンポーネントを分解することができます。
これはかなり完全な方法であることに注意してください。非常に大規模なプロジェクトでは、FooモジュールがどのようにBarと相互作用するかを正確に知る必要なく、非常に長い時間を費やすことができるでしょう。私は、システムがどの部分を快適に変更できるか、そして謎に包まれているかを理解できるように、システムについて十分に学ぶよう努めています。これはどのプロジェクトでも正常です。ライブラリは常に5％の機能を使用し、残りの部分については無知のままです。
開発環境がすでにインストールされており、必要なツールがすべて機能していると思います。そうでない場合は、これらのツールから始めます。開発環境のセットアップには、通常、長い時間がかかり、ソフトウェアのダウンロード/インストールを待機する長いアイドル期間がありますが、他のことは可能です。
情報不足については、他の開発者やマネージャーに相談することをお勧めします。上級開発者が忙しい場合は、他の開発者と話してください。彼らはあなたにいくつかのことを説明したり、ドキュメントのソースを示したり、全体像を把握していないことに不満を感じたりするかもしれません。後者の場合、上司に一緒にアプローチして、問題の解決策を考え出すことができます。
高齢者が完全に従事している場合でも、ジュニアに教える/メンタリングするためにある程度の時間を費やすことで、長期的にはワークロードを減らすことができることをおそらく理解しています。しかし、タスクの割り当てについて最終的に決定するのは経営者なので、決定は彼らの決定です。
ヒント、たくさんの質問をしてください。質問のリストを保管し、上級開発者との時間があるときにリストを引き出します。彼らの集中力を妨げる1日の間に5つの質問よりも、10のよく考えられた質問に一気に答える方がはるかに効率的な時間です。
メールを希望する場合は、メールの使用を検討してください。
質問に対する回答が得られたら、それを文書化します。ウィキがある場合はそれを使用してください。作成していない場合。 tiddlywiki であっても、何もないよりはましです。
私がいれば、「すべてがどのように機能するか」を理解することについてそれほど心配する必要はありません。あなたがジュニア/未経験者として雇われているなら、あなたの仕事に集中し、時間が与えられたときに質問をしてください。たとえば、新しいタスクが与えられたら、先輩とのつながりを利用して、より一般的な質問をしますが、一度に多くの質問をしないようにしてください。また、ソフトウェアやドキュメントなど、アクセスできる他の部分をブラウジングするために、毎日少し時間を費やすようにしてください。あなたがそれを知る前に、あなたはそれがどのように一緒に合うかを見るでしょう、あなたは先輩になるでしょう。
あなたがそれが断片化されていると考えるならば、それは実際にはそうではないかもしれません、多分あなたはまだ製品について十分に知らないだけかもしれません。
小説を読むように座ってコードを読むことができる人には感心しますが、時にはそれが少々面倒で、大規模で複雑なソフトウェア製品やライブラリでは実際には機能しないことに気づきます。
私はこの特定の議論に役立つかもしれないコードをここで読み、理解することについて長い記事を書きました technikhil.wordpress.com/2010/07/06/how-to-read-code-a-primer この記事では、自分を改善するという文脈でコードを読むことを扱っているので、読むのに適したコードを見つける方法について説明しています。しかし、この場合は、理解したいコードをすでに特定しているので、これらの点は役立つかもしれません-
- 設計ドキュメントに目を通し、コードがどのように構築されているかを感じてみてください。優れたソフトウェアプロジェクトは、特定のアーキテクチャパターンに従います。これらはコードの編成を決定します。これを理解すると、コードを理解するのがずっと簡単になります。コードのクラス図を作成できれば、レイアウトの良いアイデアを得ることができます。
- 次に行うことは、それをコンパイルして実行することです。これは、プロジェクトで従うプロセスとそのドキュメントによっては、簡単な場合もあれば難しい場合もあります。
- 次に、お気に入りのIDE=を起動して探索に進みます。コードの探索を開始する良い場所は、使い慣れたプロジェクトの機能を追跡することです。これにより、たとえば、さまざまなレイヤーとサブシステムを調べて、それらがどのように相互接続するかを把握します（たとえば、NUnitを探索していたとき）–まず、テストを記述し、そのために必要なコードクラスを確認しました。
- コードで使用されているデザインパターンを試してみてください。デザインパターンがわからない場合は、この投稿を今すぐ読むのをやめて、この本を読む必要があります。設計パターンをよく理解してください。これらは、適切に記述されたコードの設計を認識および理解するための優れた方法です。これにより、コードを読みながら頭に置いておくのが簡単になります。また、プログラマーが行ったニュアンスやカスタマイズをより簡単に識別するのにも役立ちます。
- コードのテストを記述してコードを完全に理解してください。これは、コードのさまざまな部分間の依存関係を理解するのに非常に役立つ方法です。コードのテストを作成しようとするときは、最初にすべての依存関係を満たす（模擬する）必要があります。次に、可能なエントリポイントとコードの終了値を理解する必要があります。これにより、コードの理解が深まり、次のレベルに進むことができます。
- コードをリファクタリングしてみてください。このステップでは、単にコードを理解することから、コードを変更できるほど十分に精通するようになりました。リファクタリングの洗練度が高まるにつれて、理解も高まります。
また、それが本当に巨大なプロジェクトである場合、そのすべてがどのように機能するかを知ることはできません。あなたはいくつかのモジュールの詳細を知っているだけで、他のモジュールとどのように相互作用するかを知っているだけかもしれません。システム全体の専門家であるエンジニアはほとんどいません。
みんな違いますが、私がすぐに理解できるようになった最良の方法は、「難しい」ヤードを行い、降りて学習することでした。基本的に、これには読書とより多くの読書、調査、さらに調査が必要であり、質問をすることを恐れませんでした（ただし、適切な状況と時間で）。
ログファイルがある場合は、これらを調べます。バグの調査にある程度関与していることは、プロジェクトを理解し始めるための優れた方法であることがわかりました。退屈で最も楽しいものではありませんが、解決策を深く掘り下げる機会がありました。できる限り徹底的に問題を調査する準備ができている限り。自分で解決できず、シニアメンバーにエスカレーションする必要がある場合でも、問題を実際に調査する能力を示し、調査した領域を指摘し、何が起こり得るかについて自分の意見を提供できる場合うまくいかない。
すでに多くの時間を割いてロバの仕事をしていることを知っているシニアメンバーは、腰を下ろして机に向かって進んで進んでいく傾向があることがわかりました。
あなたが助けになるかもしれない重要なメモは、質問をするときに答えを書き留めて、もう一度尋ねるのと同じ間違いを犯さないようにすることです。ほとんどの上級開発者は、ジュニアに対してかなりの忍耐力を持っていますが、ジュニアがあなたの言っていることに注意を払っていないように見えるとき、それはすぐに薄くなります。
あなたの新しい役割で頑張ってください。
プロジェクトが本当に巨大である場合、彼らはあなたが2週間、あるいは2か月でそれを知ることを期待しません。もしそうなら、あなたは間違った場所にいます。
私の最新の立場は、1年間出荷される実際の製品に高度な関連性が期待されないというものです。速度を上げるために、ドキュメントを読んで、製品をいじったり、ハッキングしたり、たくさんの質問をしたりすることに多くの時間を費やしました。あなたが得る最初のいくつかのタスク（バグ修正、マイナーな変更）は、プロジェクトに慣れるために始まります。それ以降は、それぞれが理解を深めるはずです。
あなたがレイアウトして従うことができるプロセスがあると私は確信していますが、私はそれをそのままにしておくのが最善だと思いました。より多くのことをすればするほど、より多くのことを学びます。