その他

コードリーディングのチートシート(随時更新)

その他
この記事は約2分で読めます。

実務でコードの海に溺れそうになったので、いったん立ち返る場所として書いています。

概要

・理解のため、手順のような形で書かれています
・コードリーディングのノウハウを網羅した記事ではありません。

まず何を知りたいかを明確に決めよう

「コードを読むこと」が目的になってはいけません。
自分が作業するスコープを把握することなど、コードリーディングした先を意識することは基本的なことです。
何かしらの目的意識を持つことで理解も深まります。

コードは読むな

いきなりコードを読んではいけません
書かれているコードの使用がざっくり書かれたものが仕様書であったり、図説で存在します。
チームメンバーが工数をかけて作った資料を蔑ろにしてはいけません。

仕様書で、該当箇所を見る

ワイヤーフレームを見て実装する際の大体の関係性を把握したり、要件定義書を見て「今、メンバーがどのタスクを行なっているのか」を見る必要があります。
これを理解せずにいきなりコードの海に飛び込むと溺れるか、あまり理解できずに時間だけを溶かすことになるでしょう。
つまり、今メンバーがやっているのは一覧表示なのに、新人が見ているコードはAPI関係だったりする場合があります。

詳細設計書を読んで、細かいタスクを見る

WBS(作業分解構成図)などはPMが何日もかけて必要な作業を洗い出し、作成したものです。
時間を無駄にしたくなければ、必ず参照しましょう。
次は何したら良いのか?の答えは必ずここにあります

SE/PG側がWBSを見るメリットは、かなりざっくり以下のようなものです。
・プロジェクトの全体像が見える
・粒度が細かいタスクが見える
・作業が構造化されている
・作業のスコープが明確

分からない点は積極的に聞こう

新しくアサインされた側より、絶対にマスターメンバーの方が分かっているので、いまいち分からないところは積極的に聞きに行きましょう。
さもなければ普通に1日溶けるので、悩んでる時間をやめてチームメンバーの5分をありがたく頂戴しましょう。

あとがき

1日目はこれが分からず、最初に言われた「とりあえず資料読んでおいて」で何を知りたいかを明確に理解出来ていませんでした。
自分が理解出来ている範囲での記事なので、今後もっと増えてくれば更新する可能性があります。