コードの再利用化は幻か?

285, 2020-02-07

目次

コードの再利用化は幻か?

コードを再利用したいという願望は万人が持っている。
しかし、なかなかそれは実現が難しい。
なぜかと言うと、コードが汎用的でない場合が多いからである。
かといって特殊な状況のコードの再利用も、特殊なだけに汎用性が無く、再利用化が難しくなる。
結果的に、再利用化を狙ったコードも使われなくなり、タンスの肥やしとなる。

コードの再利用化は幻なのか?

スニペットという小さな単位でコードを再利用化する試みも頻繁に行われている。
エディターにはスニペットマネージャーが備わり、ユーザーはスニペットを登録して利用する。
しかし、せっかく登録したスニペットも、あまり使われることは無く、気付いたらスニペットで済ませるハズのコードをわざわざ書いている自分がいる。

これはなぜなのか?

再利用化への心構え

登録したスニペットのコードを、わざわざまた書くというのは愚の骨頂であるが、意外とやりがちだと思う。
なぜこんなことが起こるのか?
それは、心構えが足りないからである。
「コードを再利用するゾ!」という気概、それが足りない。
我々は常にコードを書くときはスニペットを第一に考え、プロジェクトを始めるときはパッケージを考えなければならない。
それが通常の状態になってはじめて、功を成すと言える。

我々はもっとスニペットやパッケージに依存しなければならない。
生産性を上げるためである。
一から書くなんてことは恥ずべきことなのだ。
それが許されるのは、スニペットのコードが何をやっているのかわからない状態の時だけである。
何度も同じコードを書いている自覚があるなら、それはスニペットにしなければならない。

さらに言えば、スニペットをさらに抽象化してライブラリにしなければならない。
しかし、ライブラリの管理はめんどくさいものである。管理面ではスニペットのほうが私は手軽だと思う。
わざわざ依存性を排除して独立したライブラリの結晶にして、さらにそれをインターネットからダウンロードできるようにする。さらにバグをフィックスし、性能を上げて、コミットする。
この労力を割ける人間はあまりいない。なぜなら時間がかかるからだ。

一方、スニペットであれば使い捨てのコードにできる。
ただ、ライブラリではないただのコピペなので、性能を上げたりバグをフィックスしたりすることはできない。
それが必要になるほど、モジュール化されていて、利用率が高ければ、それはライブラリにしてインターネットに公開するべきだろう。

スニペットとライブラリの中間

スニペットのように手軽に使えて、ライブラリのようにコミットできるものがあれば、私は喜んで使うだろう。
コミットできるスニペットである。
しかし、そんなものはあるのだろうか?

スニペットはライブラリより特殊

スニペットはライブラリより特殊である。
汎用性であれば、ライブラリの方が高い。
しかし、実際にコードを書いていて必要になるのは、ライブラリを使っていてかつ特殊な状況である。
スニペットにはライブラリを使用したコードが書かれていて、我々はそれをある程度特殊な状況で使用する。

この特殊な状況というのは、特殊なだけにどうしても登場率が低い。そのためスニペットの利用率も下がる。
たとえばあるプロジェクトでスニペットを沢山作るが、プロジェクトが終了すれば、そのスニペットを利用することは少なくなってしまう。
これはスニペットの使用状況が特殊なために、他に需要がないということだ。
ノリノリで自画自賛しながら書いたスニペットも、プロジェクトが終われば「はい、さようなら」である。
そうなると次のプロジェクトではまた一からスニペットを作ることになるのかというと、それは選択肢の一つであり絶対ではない。
前のプロジェクトで使ったスニペットを汎用化すれば再利用はできるかもしれない。しかし、スニペット内で使っているライブラリを次のプロジェクトでもまた使うかどうかはわからない。

そうなったらどうするべきか?

スニペットのテンプレート化

私の考えている答えは、スニペットのテンプレート化である。つまりライブラリAを使っているスニペットがあり、それをライブラリBに切り替えたい場合、新しくスニペットを作るのではなく、既存のスニペットをテンプレート化して、外部から選択できるようにするということだ。
コマンドでいえば↓のような感じである。

$ show-snippet mysnippet.code --ajax axios

mysnippet.codeが使っているAjaxのライブラリを、--ajaxというオプションで切り替えられるようにする。オプションにはaxiosを渡しているので、↑のコマンドから生成されるコードはライブラリであるaxiosを使ったコードになる。

こうすればオプションを切り替えれば色々なコードを作ることが出来る。
元になっているコード内ではテンプレート言語で分岐をして、オプションを処理する。

もちろんこの方法は最適とは言えないだろう。
スニペットを管理する手間があるし、相変わらず新しいコードを生成したい場合はコードを書かなければいけない。

Capを使ったテンプレート化

ちなみにこの方法は、私が作っているCapというアプリで行うことが出来る。

すでにコードをテンプレート化もしていて、日常的なプログラミングで使っている。
ただ、手ごたえとしてはまだわからない。
スニペットにオプションを加えるということは、スニペットに学習コストを加えるということになる。使用者はオプションを覚えるか、--helpを見る必要がある。

この--helpを見ている時間をどう考えるかだ。それが無駄と感じるなら、この試みは意味がない。

じっさいに、生成されるコードがわずかで、ヘルプを見ている時間が長いと、使用者の幸福度は下がる。
なぜなら、ヘルプを見ている時間で、一から書いてしまったほうが速い場合があるからである。
こうなるともはや本末転倒で、なにをやっているのかわからない。

しかし、ある程度のコード量が生成されれば、使用者の幸福度を上げることが出来る。この場合はコマンドの学習コストも苦にならない。

Capは実験中のプロダクトだが、まだ答えは出ない。その内、目に見えて私の生産性が上がれば、それはCapのお陰かもしれない。しかし、まだ私のCapへの習熟度が低く、そうとは言えないのである。

結論

結論としては、コードの再利用化は特殊な状況では幻であると言える。
しかし、特殊性を切り替えられるようにすればある程度対応できる。
生産性の向上は、プログラマーが取り組むべき大事な問題であり、色々なアプローチを試すのは有意義だと言える。たとえそれが失敗であっても。

おしまい

Webアプリケーションの制作ならNARUPORT

Webアプリケーションの制作ならNARUPORTにお任せください。
Webアプリの他にもGUIアプリやChromeExtension, スクリプトの制作など可能です。
以下のお問い合わせフォームからご依頼ください!

投稿者名です。64字以内で入力してください。

必要な場合はEメールアドレスを入力してください(全体に公開されます)。

投稿する内容です。

スポンサーリンク

スポンサーリンク

スポンサーリンク

スポンサーリンク