前回の続きです。

今回はこれまでのまとめの章みたいなところを読んだので、復習感が強くて新たに抽出する部分は少なめだった印象です。
ただ、個人的に意識したい部分とかはちらほらあったのでそこをメモしていきます。

ちなみに今回で最終回です。

テストコードを書く

テストコードを書くにも読みやすさを考えようという話。

テストコードが大きくて読みたくないほど恐ろしいものだとすると

・本物のコードを修正するのを恐れる（得体が知れないコードだから）
・新しいコードを書いた時にテストを追加しなくなる

テストが読みやすいと本物のコードの動作が理解しやすくなる

参考書籍にも軽く触れていたが、TDDにも関わる部分だろうなぁと読んでて思った📖🤔

例では、検索結果のスコアを降順にソートする関数sortAndFilterDocsをテストするコードを用いて紹介されていた。

このsortAndFilterDocsをテストするためのヘルパー関数checkScoresBeforeAfter(検証値, 期待値)を使う時の例は個人的に気になった

checkScoresBeforeAfter("2, 1, 3", "3, 2, 1") // シンプルなソート
checkScoresBeforeAfter("0, -0.1, -10", "0") // マイナスは削除
checkScoresBeforeAfter("1, -2, 1, -2", "1, 1") // 重複は許可
checkScoresBeforeAfter("", "") // 空文字は許可

入力値は"12471, 13784"みたいな複雑な値にする必要はなく、"1, 2, 3"のような単純な値で良い。

単純な値でかつ、例のようなマイナス値、少数、空文字と言ったケースの検証をしていくだけで検証としては十分である

テストをやりすぎない

テストカバレッジを100%にこだわりすぎる。

現状90%で、残りの10%は割とどうでも良いテストケースだったりするので、そこに工数をかけるのはコスト的に割に合わない。

コードは変化するものなので、完璧を求めすぎるのも良くないということもありそうだなと思った。

ちょうどテストカバレッジの計測とかをチームのプロジェクトに導入しようかなとか考えていたので頭の隅っこに入れておこう🧠

コードの規模とパフォーマンスを意識する

説明が長くなるので、省略のために言葉足らずな部分が多くなると思うが、

Webサーバの直近1分間と直近1時間の転送バイト数を把握する

という題材で設計・実装を考えるというものを題材にしてリーダブルコードの紹介がされていた。

それらを解決するために、以下3つの方式で解決してみるという話だ。
詳しくは参考書籍を読んでもらいたい。

1️⃣ 素朴な解決策
2️⃣ ベルトコンベアー設計
3️⃣ 時間バケツ設計（バケツ60個）

これらの解決策を以下の観点で見比べた結果が気になった。

・コード行数
・いずれの方式でも扱う共通の関数の計算量
・メモリ使用量
・精度

1️⃣→3️⃣になるにつれコード行数は増え、精度は落ちていくが、計算量やメモリ使用量等のパフォーマンスは全体的に上がるというものだ。

また、3️⃣では、問題を複数のクラスに分割することで設計に柔軟性を持たせ、可読性を上げている。

リーダブルなコードとは、必ずしも行数が短ければ良いというわけではない。
それに、読みやすさだけが全てではなく、実際にコードを書いて動くシステムやアプリがあるわけで、そのパフォーマンスが良くないと作る意味がない。

一つの複雑なクラスを実装するより、問題を分割して複数クラスで実装する方がいろんな観点から恩恵が得られるというわけだ。

以前もやった下位問題を抽出するが近い感覚だろうか

*
*
*

一通りリーダブルコードを読んでみると、命名やコメントの細かい部分から処理の書き換え部分までいろんな観点で良いコードを学べた。

中にはこれ普段からやってるわ〜とか、おっこれ今度意識してみよみたいなものもあったので、参考になった。

言語に若干の差異はあれど、共通して使えそうなナレッジになると思うので、ぜひこの書籍はお勧めしたい。（いまさら）