Meridianの抽象度をあげていく

Meridian計画。
通信エラーがほとんど出ないMeridian TWINができたことで、開発の見通しがかなりよくなりました。
今後は各センサーや各社サーボ対応、また各種の市販ロボットや既存の基板などへの対応を進めていきます。

ということで、そろそろライブラリ化を進め始めるのがよさそうです。

ライブラリ化のよいところ

これまでの開発はまさにプロトタイピングといった感じで、それぞれの機能が動くことを検証するための作業でした。
TWIN版, LITE版, console版, UNITY版を並行して開発しましたが、共通化はせいぜい、関数を同じものにしたり、変数名をなるべく合わせるぐらいでした。

ライブラリ化のビフォーアフター

ライブラリは汎用的に使うプログラムの部品を扱いやすくまとめたものです。
普段から様々なライブラリを使わせていただいていますが、ライブラリ化されているものは関数の機能や役割（スコープ）が明確で、コードを組み立てる時にとても扱いやすいです。
基本コードと応用例の関係性もクリアになり、ライブラリが基本機能、サンプルコードは具体的なロボットに合わせた応用例というふうに役割分担できるようになります。
また、機能ごとの開発もしやすくなりそうです。

他のメリットとして、しっかりとしたライブラリを構成することでオフィシャル感がでてアクセスしやすくなることなどが挙げられます。
「このライブラリを正しく使いこなすぞ」という受け手側の気持ちの変化も生まれそうな気がします。
ライブラリの発表時には、Meridianを使いたくなるような魅力的なデモ動画などで盛り上げていく必要もありそうです。

デメリットとしては、メンテナンスの作業が発生したり、ドキュメントをしっかり揃えるなどの個人作業増が挙げられます。しかしこれは一般化を目指すには、いずれやらねばならぬことかと思います。
また関数化することで初心者から見た時にブラックボックス化するという問題もあります。経験上、ライブラリの中身というのはよほど困った時にしか見ないものです。

Meridianは、中身を理解せずとも誰でもロボットを使える、ということは目指しておらず、誰でも中身を理解しながらロボットを扱える、というものにしたいと考えています。
ライブラリ化は進めつつ、別途解説をつくるなどで対応するのがよいかなと思います。

ライブラリ化の課題

実は自分が一度もライブラリを作ったことがないというのが一番の問題です。
めんどうそうなので人生で避けてきた部分でもあるのですが、システム作りとして一番大事なところなのでちゃんと勉強したいと思います。

次回記事：

前回記事：

目次：