前回の続きです。

今回は実際の処理を大きく変えて修正する章の、個人的に気になった部分を取り上げます。

無関係の下位問題を抽出する

作成した関数の処理が成し遂げたい目的のみを実施しているのか？
あるいはそれよりも下位の問題を解決する処理が紛れ込んでいないか？を確認する。

例では、「与えられた地点から最も近い場所を見つける」functionを定義した時を取り上げられている。

var findClosestLocation = function (lat, lng, array) {
   var closest;
   var closest_dist = Number.MAX_VALUE;
   for (var i = 0; i < array.length; i += 1) {
       // 2つの地点をラジアンに変換する。
       var lat_rad = radians(lat);
       var lng_rad = radians(lng);
       var lat2_rad = radians(array[i].latitude);
       var lng2_rad = radians(array[i].longitude);

       // 「球面三角法の第二余弦定理」の公式を使う。
       var dist = Math.acos(Math.sin(lat_rad) * Math.sin(lat2_rad) +
                            Math.cos(lat_rad) * Math.cos(lat2_rad) *
                            Math.cos(lng2_rad - lng_rad));
       if (dist < closest_dist) {
           closest = array[i];
           closest_dist = dist;
       }
   }
   return closest;
};

この関数は最も近い場所を見つけることが目的である。

それを踏まえてみると「球面三角法の第二余弦定理」の公式を使う。の部分は下位問題と捉えることができるので、該当部分は別の関数として抽出ができる。

var findClosestLocation = function (lat, lng, array) {
   var closest;
   var closest_dist = Number.MAX_VALUE;
   for (var i = 0; i < array.length; i += 1) {
       var dist = spherical_distance(lat, lng, array[i].latitude, array[i].longitude);
       if (dist < closest_dist) {
           closest = array[i];
           closest_dist = dist;
       }
   }
   return closest;
};

少しもとの関数もいじるが、ざっとこんな感じになって、コードがスッキリした。

関数に2つ以上の目的を持たせないようにするのは注意してみていきたい。

だからと言って何でもかんでも分割しすぎるとたどる箇所が増えてしまい、かえって読みにくくなることもあると述べられている。

結局、読みやすさは匙加減が必要そうだなぁ。

でも経験値積めばわかってくるものだと思う。

一度に1つのことを

コードを修正する前に、そのコードでどういうタスクを行なっているのか列挙してみると良いそうな。。

これをすることで一度に複数タスクをしていないかを確認することができ、もし行っていればコードを分割して、改善をようやく検討することができるというわけだ。

というか、分割することが大事なようだ。

まぁそれをやろうとしてタスク列挙しているから当然か。

コードに思いを込める

コードを読み手に「プレゼント」するとき、コードを簡単な言葉で説明するべきである。

コードを書くときは、自分の言葉で何をしたいのかを説明してみる。

部屋にあるぬいぐるみに向かって説明するような方法を実践してみることで（ラバーダッキング）、自分の考えを明確にしてコーディングを始められる。

これによって、相手にも理解してもらいやすくなる。

自分のコードを説明しようと思ったことはあまりない。
必要になったら説明はするものの、積極的に説明しようとすると、確かにあいまいに書いている部分はありそう。

曇りなき目でコーディングをしなければ。

短いコードを書く

もはや書かない、書くとしても要求を完璧に満たす必要はないという発想。

例えば「東京のご飯屋さんを検索する」機能を考えるとき、

・日付変更線を跨いでいる場合
・北極/南極が近い場合

などの観点は今回の機能には必要ない。
（日付変更線とか北極/南極がどう影響するのかは知らなかったが、今回の論点とは外れるので無視笑）

ライブラリを時には読んでみる

目を通しておくくらいの温度感で良く、どこかのタイミングで「あ〜そういえばあの機能を使えば楽に実装できるなぁ」を増やすためにする。

苦労して作成した処理が、実はライブラリの機能で一行で速攻解決するよ？みたいなのって昔もあったし。。

知識は力なり🙏

*
*
*

コードを分割する、説明できるようにする、楽をするために必要な要求を明確にする、ライブラリに頼る

これが読んで気になったところかな。

次回、最終回です👏