今回読んだ内容

今回は「9章　設計の健全性をそこなうさまざまな悪魔たち」を読みました。

普段コードレビュー時に指摘されることのあるコードが具体的に「なぜ良くないのか」を、
実例を交えて学べる内容でした。

「なるほど」と思ったポイント

マジックナンバーとは、ロジック内に直接書かれている意味が読み取りにくい数値のことです。
以下のコードは消費税込みの値段を求めるコードです。

例１

const calculateTotalPrice = (price: number) => {
    return price * 1.1
}

1.1が何も説明がないので、コードを見ただけだと何をしているのか、直感的に理解しにくいコードになっています。
この状態では実装者本人しかほとんど意図を理解できず、保守・改善がしづらくなってしまいます。

また、消費税計算のような計算は使われることが多く、税率が変更される可能性もあります。
その結果

この状態の解決策として、書籍では定数として切り出すことが紹介されていました。

今回のケースに当てはめると、以下のようになります。

例１(改善)


const TAX_RATE = 0.1

const calculateTotalPrice = (price: number) => {
    return price * (1 + TAX_RATE)
}

税率が変更になった場合もTAX_RATEの値を変更するだけで良くなります。

例外の握りつぶしとはtry catchで例外をcatchしたとしても、それに対して何の処理もしないことを言います。

例２

try {
    calculateTotalPrice();
} catch(error) {
   
}

書籍ではこれの問題点としてエラーが発生しても、外からそれを検知することができないことを挙げていました。

検知ができないと次のような問題が連鎖して発生します。

この状態の解決策として、書籍では異常にすぐ気づける仕組みにしておくことが大切と紹介されていました。

具体的なエラーログの書き方については触れられていませんでしたが、catchしたときに少なくともログへの記録やエラー通知を要求するロジックの追加が大事だと書かれていました。

これを読んで開発者が気づくことのできる仕組みも大事だと思いましたが、
加えてユーザーが何かよくわからないけど動かないという状態がないよう、
トーストを出すなどして知らせる仕組みも大事だと思いました。

例２(改善)

try {
    calculateTotalPrice();
} catch(error) {
   console.error(
        "価格計算処理でエラーが発生しました",
        error
    );
    toast.warn("計算に失敗しました")
}

コードを書くときや見直すときは、そのコードを初めて見る人でも意図をある程度理解できるか、数ヶ月後の自分が見ても思い出せるかを意識していきたいです。