仙塲大也さんの「良いコード/悪いコードで学ぶ設計入門」を読んだ内容を、自分なりの理解も含めて少しずつ整理していきます。
参考書籍：
良いコード／悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方
感想だけでなく、「普段の開発でどう活かせそうか」も合わせて考えていきます。
今回読んだ内容
今回は「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("計算に失敗しました")
}
今後意識したいこと
コードを書くときや見直すときは、そのコードを初めて見る人でも意図をある程度理解できるか、数ヶ月後の自分が見ても思い出せるかを意識していきたいです。