はじめに
・処理の流れは追える
・どこで何をしているかも分かる
でも、
👉 「なんでこの処理が必要なの？」
で止まる人へ
例えば、
if (stock <= 0)
{
throw new BusinessException();
}
コードは読めます。
でも、
・なぜここでエラーにするのか
・なぜDB更新前にチェックするのか
・なぜ例外を投げる必要があるのか
👉 「処理の目的」が分からない
こんな経験はありませんか？
これは、
👉 コードが読めないのではなく
👉 “コードの背景”が見えていない
ことが原因である場合が多いです。
この記事の位置づけ（シリーズ）
この記事はシリーズの7回目です。
・① 新人・初級PGが最初につまずくポイント5選
・② なぜ仕様書とコードは繋がらないのか
・③ 仕様書は読めるのにコードにできない人へ
・④ ソースは読めるのに処理が追えないのはなぜ？
・⑤ どのソースを見ればいいか分からない人へ
・⑥ 処理は追えるのに 「中で何してるか」が分からない人へ
👉 今回は
👉 「なぜその処理をしているのか分からない」
という問題を扱います。
コードは読める。でも理由が分からない
例えば、
if (user.IsDeleted)
{
return;
}
コード自体は読めます。
でも、
👉 なぜ削除済みユーザーを弾くのか
👉 なぜここで return するのか
👉 なぜ IsDeleted が必要なのか
は、コードだけでは分かりません。
ここで必要なのは「文法理解」ではない
ここで多くの人が、
👉 「まだ自分の実力不足だ」
と思ってしまいます。
でも実際には、
👉 コードの問題ではありません
必要なのは、
・業務ルール
・運用ルール
・過去不具合
・システム制約
・設計意図
です。
コードは「理由の結果」
ここが重要です。
コードは、
👉 “何かしらの理由”があって書かれています
例えば、
if (stock <= 0)
{
throw new BusinessException();
}
これも、
・在庫マイナス防止
・二重購入防止
・運用事故防止
など、
👉 何かを守る目的
が背景にある可能性があります。
つまり、
👉 コードは「理由の結果」
です。
どうやって「理由」を推測するのか
重要なのは、
👉 「この処理は何を守ろうとしているのか？」
を見ることです。
例えば、
if (stock <= 0)
{
throw new BusinessException();
}
これを見たときに、
初心者の頃は、
👉 「在庫0ならエラーなのね」
で終わりがちです。
でも実際には、
・なぜここで止める？
・なぜ更新前？
・なぜ例外？
を考えます。
仮説を立てる
例えば、
👉 「在庫マイナス防止では？」
👉 「同時購入対策では？」
👉 「在庫不整合を防ぎたいのでは？」
という形で、
👉 まず“仮説”を立てます
次にコードから根拠を探す
次に、
👉 その仮説が正しそうか
をコードから確認します。
例えば、
・在庫更新処理を見る
・他画面でも同じチェックがあるか見る
・エラー時の処理を見る
・例外メッセージを見る
すると、
👉 「あ、在庫不足防止っぽい」
と見えてきます。
実際の現場では「仮説＋根拠」で考える
ここも重要です。
実際の現場では、
👉 最初から100%分かることは少ないです
そのため、
👉 仮説を立てる
👉 コードから根拠を集める
という形で調査します。
例えば、
・在庫更新前にチェックしている
・他画面でも同じ制御がある
・在庫0時は共通例外になっている
ここから、
👉 「在庫マイナス防止」のための処理
と推測できます。
報告・相談するときも同じ
実際に確認するときも、
👉 「分かりません」
だけではなく、
調査した限りでは、
・在庫更新前にチェックしている
・他画面でも同様の制御があることから、
在庫マイナス防止目的と思われます。
ただし仕様書上の明記が見つからなかったため、
認識確認したいです。
のように、
👉 「仮説＋根拠」
で話すことが重要です。
読む側だけでなく、書く側にも責任がある
ここまで読む側の視点で説明してきましたが、
👉 実はこれは、コードを書く側にも関係する話です
コードだけを見ても、
・なぜこの条件が必要なのか
・なぜここで return しているのか
・なぜこの順番で処理しているのか
が分からないことがあります。
特に、
・仕様書に書かれていない要件
・過去不具合への対策
・外部システム制約
・運用上必要な処理
・暫定対応
こういったものは、
👉 コードだけでは読み取れません
コメントで残すべきなのは「理由」
例えば、悪いコメントはこれです。
// 削除済みユーザーなら処理しない
if (user.IsDeleted)
{
return;
}
これはコードを読めば分かります。
残すべきなのは、こういうコメントです。
// 退会済みユーザーに通知送信すると運用事故になるため除外
if (user.IsDeleted)
{
return;
}
大切なのは、
👉 「何をしているか」ではなく
👉 「なぜ必要なのか」
を残すことです。
まとめ
処理は追えるのに、
👉 「なぜそれをしているのか」が分からない
原因は、
👉 コードの外側にある“理由”が見えていないこと
です。
そのため、
・何を防ぎたいのか
・何を保証したいのか
・何を守ろうとしているのか
を考えながら見ることが重要です。
そして実際の現場では、
👉 仮説を立てる
👉 コードから根拠を集める
👉 「仮説＋根拠」で相談する
という形で調査を進めます。
また、コードを書く側も、
👉 「なぜ必要なのか」
をコメントや設計メモとして残しておくことが重要です。
✔ 1つだけ意識するなら
👉 「この処理は、何を守ろうとしているのか？」
これを考えるだけで、
👉 コードの見え方はかなり変わります
おわりに
コード理解は、
👉 文法
👉 処理の流れ
👉 データ
だけでは終わりません。
その先には、
👉 「なぜその処理が必要なのか」
という、
👉 要件・業務・運用・設計
の理解があります。
もし、
「ここで止まる」
「この処理の意味が分からない」
といったことがあれば、ぜひ教えてください。
今後の記事で取り上げていきます。
■ シリーズ記事
新人・初級PGが最初につまずくポイント5選
→ 初心者が現場で止まりやすいポイントを整理
なぜ仕様書とコードは繋がらないのか
→ なぜ「仕様」と「コード」が繋がらないのかを解説
仕様書は読めるのにコードにできない人へ
→ 「線で理解する」具体的な手順を解説
ソースは読めるのに処理が追えないのはなぜ？
→ 処理を追っていて迷子になる原因を解説
どのソースを見ればいいか分からない人へ
→ 起点からコードを追う方法を解説
処理は追えるのに 「中で何してるか」が分からない人へ
→ コードの意味を理解するための「データの見方」を解説