はじめに
みなさんはソースコードを理解するのは得意でしょうか？
プロジェクトに途中参加したり、既存システムの改修したりする場合、既存の（他人が書いた）ソースコードを読んで理解するのは必然かと思います。
私はソースコードを理解するのにとても時間が掛かってしまうタイプでした・・・
なぜ時間が掛かってしまうのか？
ソースコードを理解するのに時間が掛かってしまう理由ですが「全体像が把握できない」ことが大きな原因でした。（これは今となって分かったことです。）
そもそも全体像が把握できないため、
- ソースコード（クラス数）の規模が掴めない
- 機能追加や修正を行う際、どのクラスに手を入れればいいか分からない
- 実装者の設計方針・意図が分からない
といった状態に陥っていました。
当然、ソースコードの規模が大きくなればなるほど、全体像を把握するのが難しくなります。
「どのクラスから見てけばいいの？」「このクラスとこのクラスの関連は？」みたいな感じですね。
クラス図を書くようになった
私の参加しているプロジェクトでは、UML（クラス図やシーケンス図）を描くことが多いのですが、これが今となっては非常に有難かったと思います。
そんなこともあり、私は既存のソースコードからクラス図を描いてみることにしました。
なお、一般的には「クラス図を書いて → 実装」という流れが多いかと思います。
結果、リバースしてクラス図書くということにより、ソースコードの「全体像が把握できる」ようになりました
全体像が把握できると、
- ソースコード（クラス数）の規模が掴める
- 機能追加や修正を行う際、どのクラスに手を入れればいいか分かりやすい
- 実装者の設計方針・意図がなんとなく分かる
ようになり、先ほどの問題が解消されました。
それだけでなく、
- 忘れたときに再度見返すことができる
- 作成したクラス図を他のメンバーにも展開できる
といったメリットも出てきました！
それ以来私は、既存のソースコードを把握する際は必ずクラス図を書くようにしています。
クラス図を描く際のポイント
個人的には以下の点を意識しています。
- クラス図の描き方（集約/コンポジット/依存、プロパティ/メソッドなど）にはこだわり過ぎない
- こだわりすぎてクラス図を描くモチベーションを下げないようにする
- クラス図（静的構造）なんだけども、重要なシーケンスは意識して描く
- ポイントや注意点は積極的にコメント（ノート）として記載する
クラス図を描くとこんな感じになります
上司「このプロジェクトの不具合対応を行ってもらうから、ソースコード一通り把握しておいて！」
といった依頼があったとします。
（まぁこれくらいの規模だったらめっちゃ小さいですがｗ いい例がなくすみません
）
これをリバースしてクラス図にしたとすると、こんな感じになります。
クラス図によって全体像が把握しやすくなり、不具合対応や機能追加対応が行いやすくなるのではないでしょうか？
おわりに
クラス図を書くようにしたらソースコードの理解がぐーんと上がった話について記載させて頂きました。
ちなみに、社員にソースコードの理解について聞いてみた所、
- リファクタリングする
- コードを書いた人（作者）の気持ちや思想を理解する
- 頭の中で理解する
といった方法があがりました。（私も元々は「頭の中で理解する」タイプでした。）
今回の内容が少しでも役に立てれば嬉しいです
また、皆様が実践されている「ソースコードを理解するための手法」がありましたらコメントなど頂けると嬉しいです