web連載オフシーズン／プログラムの修正／はやる心を抑える

web連載オフシーズン／プログラムの修正／はやる心を抑える

web連載「数学ガールの秘密ノート」のコンテンツ作成環境は自分で作ったものです。公開にはGitHubとNetlifyを使っています。今週からオフシーズンに入っているので、コンテンツ作成環境にいろいろ上がっているissueを解決しておきたいところですが、どうでしょうね。

致命的な問題はその都度解決しているので、現在残っているissueは、主に改善や機能拡張のようなものがほとんどだと思います。そうなると、なかなか手をつけるのが難しいときがありますね。連載更新しているオンシーズンにはできないのでぜひオフシーズンに解決したいところなのですが。

プログラムを改良するときには、プログラムを書き換える前にちゃんと読む必要があります。一見「ここをこうすれば良い」と単純に考えそうになるんですが、実際にはいろんな場面と関わりがあって、そう単純にはいかないことも多いですね。

小さな修正ならばまだしも、大きく構造を変えるような修正の場合には、十分に考える必要があります。一応は、注意すべき点や前提となる設計はドキュメント化しているんですけれど、それでも注意が必要になります。

逆に考えると、このような機能拡張を比較的トラブル少なくこなせるかどうかというのは、設計がちゃんとしているかどうかにかかってくると思います。

とは言うものの、機能拡張はしばしば、設計する時点では、考えていなかった条件が加わったり、それまでの前提条件を一部修正する必要が出てきますので、なかなか難しいものです。

前提条件が壊れていることは、ある程度はプログラムの中にセルフチェックを入れているので大丈夫ですけれど、自分がテストを書いているわけではないので、(というかほとんどテストを書いていないので)機能拡張には注意が必要になります。

「こうすれば、修正ができる」と考えてから、実際にそのように直すまでの間が意外に重要になります。それは、いわば、仮説検証です。「こうすれば、ちゃんと修正ができるとするならば、ここの部分はこういう風に動くはずだ」のようにあちこちを点検するのです。

つい、とっとと直してしまって、壊れているかどうかは後で考えるとやりたくなるんですけれど、あまりそれはうまくいかないし、結局は時間がかかってしまうことが多いですね。

それは一言で言うと「はやる心を抑える」というセルフコントロールの話になるように思います。自分が立てた仮説を検証するのに、やってみればすぐにわかるというのはちょっと早計すぎますね。

修正するときに、あるいは検証するときに、大事なのは「全てを把握しているか」というポイントだと思います。これはいろんな場面で出てきて、たとえばこのデータ構造に与えられるすべてのパターンは何か。URLのここの部分には数字しか来ないと言えるか。ここの文字列は必ず3桁なのか。簡単に言えばそんな感じの問いの積み重ねになります。

一つ一つの問いは単純なものですけれど、それが組み合わされると、場合の数が爆発してしまいますので、確かさを上げる必要がありますね。

いくつかの内容はスタティックにチェックできますけれど、ダイナミックにしかチェックできないものもたくさんありますので、気をつける必要があります。

プログラムを修正するのは面白いか面白くないかで言うと「とても面白い」作業になると思います。ですから、逆に注意が必要で、さもないと作業時間を全部プログラムの修正で溶かしてしまうことになるからです。