第3部 コードの再構成 ~コードを短くする~

不要なケースをそぎ落とす

要求の内、100%全てのケースを満たすのではなく、満たさなくてもよいケースを見つけ、そぎ落として簡単にすべき、とのこと。ありえないケースはコードを書かない、という話だ。

例えば「サッカーのスコアをチェックして結果を表示する機能が欲しい」という要求の場合、以下のチェックは不要だとわかる。
 1. スコアに数値以外が入っている場合、エラーにする
 2. スコアがマイナスの場合、エラーにする
「1」も「2」も入力時点で自然数しか入らないよう、DBの定義や設計を見直してもらうべき。さらに言うと、スコアがマイナスになることはサッカーという競技上ありえないから。

駆け出しの頃、コードを無邪気に書いて、コードレビューで物凄い量の指摘を受け、物凄い量を削った記憶がある。あの時はショックだったな。でも仕方ない。今思うと、無邪気に書いたコードは読みやすさの欠片も配慮していなかったから。。。初心を忘れないようにしよう。

不要なコードを削除する

不要なコードは将来のコードのジャマをするから削除すべき、とのこと。確かに、コード量が多いと読み解くのに時間が多くかかったり、突如バグとなって牙を剥いてくることもある。

過去を振り返ると、コードを消すのが苦手だった。今まで書いてきた時間がなくなる気持ちになるから。そのせいでムダなコードが大量に残っていたなぁ。。。

使っていないコードはIDEが教えてくれるので比較的簡単に探せる。道具の力も使って不要なコードを削除するよう努めよう。

コードを書かずに済む方法を考える

最も読みやすいコードは何も書かれていないコード、とのこと。そりゃそうだ。書かれていなかったら読む必要ないんだから・・・というのは冗談で、わざわざコードを書くんじゃなく、ライブラリや再利用可能な関数を使おう、という意味だ。

まぁほぼ全員が同意する内容だろうな。ライブラリや関数を使えば、他で動作している実績があるから安心して使える。もしライブラリや関数にバグがあっても、作成した人や保守担当の人が直してくれる。自分でコードを書く必要がないから「コード書かずに済む」から使わない理由がない。

でも、「そのライブラリが使えることを知らなかったからコードを書いた」ということはあると思う。ライブラリの全てを把握するのは難しいから、コードを書く前に「ライブラリで解決できないか?」を自問してライブラリを見る癖をつけた方が良さそう。

この記事が気に入ったらサポートをしてみませんか?