実務でコードの海に溺れそうになったので、いったん立ち返る場所として書いています。
概要
・理解のため、手順のような形で書かれています。
・コードリーディングのノウハウを網羅した記事ではありません。
まず何を知りたいかを明確に決めよう
「コードを読むこと」が目的になってはいけません。
自分が作業するスコープを把握することなど、コードリーディングした先を意識することは基本的なことです。
何かしらの目的意識を持つことで理解も深まります。
コードは読むな
いきなりコードを読んではいけません。
書かれているコードの使用がざっくり書かれたものが仕様書であったり、図説で存在します。
チームメンバーが工数をかけて作った資料を蔑ろにしてはいけません。
仕様書で、該当箇所を見る
ワイヤーフレームを見て実装する際の大体の関係性を把握したり、要件定義書を見て「今、メンバーがどのタスクを行なっているのか」を見る必要があります。
これを理解せずにいきなりコードの海に飛び込むと溺れるか、あまり理解できずに時間だけを溶かすことになるでしょう。
つまり、今メンバーがやっているのは一覧表示なのに、新人が見ているコードはAPI関係だったりする場合があります。
詳細設計書を読んで、細かいタスクを見る
WBS（作業分解構成図）などはPMが何日もかけて必要な作業を洗い出し、作成したものです。
時間を無駄にしたくなければ、必ず参照しましょう。次は何したら良いのか？の答えは必ずここにあります
SE/PG側がWBSを見るメリットは、かなりざっくり以下のようなものです。
・プロジェクトの全体像が見える
・粒度が細かいタスクが見える
・作業が構造化されている
・作業のスコープが明確
分からない点は積極的に聞こう
新しくアサインされた側より、絶対にマスターメンバーの方が分かっているので、いまいち分からないところは積極的に聞きに行きましょう。
さもなければ普通に1日溶けるので、悩んでる時間をやめてチームメンバーの５分をありがたく頂戴しましょう。
あとがき
1日目はこれが分からず、最初に言われた「とりあえず資料読んでおいて」で何を知りたいかを明確に理解出来ていませんでした。
自分が理解出来ている範囲での記事なので、今後もっと増えてくれば更新する可能性があります。