Mirと技術的負債
「Canonical」のソフトウェア開発者であるAlan Griffiths氏が「Mir」について語っています。
「Mir」は「Canonical/Ubuntu」主導で開発が行われ、将来「Ubuntu Desktop」で採用される予定だったディスプレイサーバーです。
「Ubuntu Desktop」では、「Unity8」とセットで利用することになる予定でした。
技術的負債
私はソフトウェアの開発者である。ソフトウェアの開発者になるということは、ユーザー（非ソフトウェア開発者）がほとんど理解できない多くの問題に取り組むということである。
今回する話は、その問題の一つを成功裏に対処する話である。
ソフトウェア開発者はしばしば「技術的負債」について話をする。
この言葉は、難しい専門用語を使用せずに問題を説明しようとする時に使われる隠喩（メタファー）である。
この言葉は Ward Cunningham氏が最初に使用した表現だと思うが、間違っているかもしれない。
「技術的負債」は、当面の目標を実現するには今の手法では将来的にコストが重くのしかかるため、なんとかしようという思いや状況を表現する隠喩である。
ローカライズの例
例えば、ハードコーディングされた英語の文章が使われているアプリがあるとしよう。そのアプリはデモンストレーションや初期リリースであれば、開発者の想定通りに動くだろう。
しかし英語圏以外のユーザーにアプリを提供するため、ローカライズ作業を行う必要があるなら、多くの修正作業が伴う。
その修正作業はテキストの修正だけではなく、UIのレイアウトも調整する必要があるだろう。
（予め多言語展開を配慮した設計ではなかったということ）
開発者が真のコストを認識していない
「技術的負債」の問題点は、ビジネスの分野に身を置いている開発者達は銀行ローンなどの借り入れに慣れてしまっており、「技術的負債」の真のコストを認識していないという点である。「技術的負債」の負債は、抵当権付きの貸付金よりも非常に高い利息のついた短期の小口ローンである。
結果として多くのソフトウェアプロジェクトは、ビジネスに影響する重要で見えないコストを増加させる「技術的負債」と戦うことになる。
「技術的負債」に取り組んでいる人々が、今回の成功事例を通じ自身の解決策を見出だせたらと願っている。
Mirとは何か？
私が活動しているプロジェクトがMirである。Mirには、とある「技術的負債」があった。
Mirはディスプレイ管理を容易に行うための仕組みを提供するライブラリー集である。
1つもしくは複数のスクリーン上でウィンドウを体系的に管理するサーバーと、ウィンドウの中身（コンテンツ）を提供するクライアント（アプリケーション）で構成される。
サーバー側ではMirは、Ubuntu PhoneやUbuntu Tablet上で動作するUnity8ウィンドウマネージャーが利用している。
またUnity8は、Ubuntu Desktop 16.10でプレビュー版として利用でき、このUnity8もMirをサーバーとして利用している。
クライアント側では、複数の下流プロジェクトがMirを使用しており、GTKやQt、SDL2がMirをサポートしている。
加えてMir上で動作するX11サーバーがある。
XmirはMirサーバー上でXベースのアプリケーションを動作可能にする。
柔軟なプラグインシステム
内部的な仕組みに目を向けると、様々なグラフィックプラットフォームや入力プラットフォームをサポートするため、それぞれのプラットフォームにあったプラグインモジュールを読み込む柔軟な仕組みがある。この文章を書いている時点では、サポートされているプラットフォームは、MesaとAndroidグラフィックスタックである。
これらのデバイスでMirを直接サーバーとして動作させることも、Mir自身やX11をクライアントとして動作させることもできる。
2つのプロジェクトと負債
消費者に出荷される実デバイスにMirとUnity8を搭載することは、大きな利点となっている。その一方で密接な関係にある2つのプロジェクトは、上記で紹介したローカライズの例のような問題があった。
APIとABI、技術的負債
問題を説明するために、APIとABIについて紹介する必要がある。API（Application Programming Interface）は、Mirに対応するコードを記述するためにプログラマーが利用するインターフェースである。
ABI（Application Binary Interface）は、Mirに対応したソフトウェアが動作する際、Mirとプログラム間のコードの振る舞いを決めるインターフェースである。
MirのAPIやABIを変更すれば、Mirを利用しているプログラムは動作しなくなる。
もし既存のプログラムに影響を与えない変更のみを行うなら、MirのAPIやABIは安定しているものと考えられる。
MirにはMirをクライアントとして利用している複数のプロジェクトがあり、安定したAPIとABIの重要性は高く評価され、それに従ってきているのだ。
一方サーバーとしてのMirは十分な統制が取れていなかった。
APIは段階的に発展してきたものであり、ABIはMirのリリース毎に変更されていたのだ。
MirとUnity 8
このゆっくりとしたサーバーAPIの発展は、Unity 8のcompatibility branch（互換ブランチ）によって保守されており、APIの変更はUnity 8に行われMirの各リリースはUnity 8のリリースによって管理されていた。実際のところMirがUnity 8に足並みを揃える必要はないのだが、この状況に関わりのある追加プロジェクト（unity-system-compositorとQtMir）がさらに複雑に絡み合い、高コストなプロセスにしていたのだ。
このcompatibility branchによる保守及びリリースは、Mirのリリースに関わるコストを増加させる。
必要な変更やテストは、関連するプロジェクトに対して横断的に行われるが、それらのプロジェクトは異なるチームに属している。
そのためコストが徐々に増えていったが、このコスト増加は相応のコストであると感じていたため、注意を払うことはなかった。
ソフトウェアのリリースに数週間と数人日かけるなんて本当に不合理なことである。
不安定なサーバーAPIとABI
不安定なサーバーAPIとABIにはもう一つの間接的なコストがある。不安定なサーバーAPIとABIは、Canonicalの外のチームにとってMirサーバーの開発や保守を困難にするものである。
Mirのリリース毎に誰かがサーバーの更新やリリースを行うまで、そのサーバーはリリース毎に動作しなくなるだろう。
この問題は自然の成り行きで起きた変化ではないように思う。
MirサーバーAPIは ABIの安定性に考慮して設計されていなかったし、開発の焦点はより多くの機能を実装することであり、技術的負債のコストを減らすことではなかったためだ。
開発チームによるAPIの統廃合や整理により改善された部分はあるが、根本的な問題の解決には至らなかった。
混沌としたシステムから整理されたシステムへと昇華させるには、実行力とそれを意識した取り組みを必要とする。
そしてその実行力は、リリースプロセスの管理によりいつも失われるのだ。
MirALによる技術的負債の返済
Canonicalには、毎週1日の半分を自分の選択したプロジェクトで活動しても良いという方針がある。私は管理者と相談し、安定したAPIとABIを提供するウィンドウマネージャーを実装し、現状を改善する代替案を提供するための作業を選択した。
私は分離したMirAL（Mir Abstraction Layer）プロジェクトを立ち上げ、Mirのサンプルサーバーからソースコードをコピーした。
その後即座にMirのパッケージングにおいて今まで検出されていなかった一連のバグが顕になった。
修正は難しくなかったがMirの利用に問題が起きた。
- 参照されているがインストールされていないヘッダー
- 見落とされた他プロジェクトへの依存
- 不正なpkg-confファイル
- などなど
Mirのバグレポートを作成し、これらのバグを私の本業内で修正した。
それから汎用的なウィンドウ管理ロジックをサンプルから抜き出し、MirALとウィンドウ管理間のAPIを構築した。
ウィンドウ管理機能
結果このライブラリーには、3種類の基礎インターフェースが登場することになった。- ウィンドウ管理ポリシー
- 基本ウィンドウ管理
- ウィンドウ管理ツール
これはメニューの配置のような基本的なウィンドウ管理機能を提供し、以下のような異なるウィンドウ管理手法間で共通して利用できる機能である。
- 通常のデスクトップ
- ウィンドウをタイリングして配置するデスクトップ
- 組み込みシステムで使用されるキオスク
APIとABIの破壊からの保護
既存のサーバーAPIと共に非常に一般的に発生するABIの破壊から保護するため、修正作業を行った。ABIやAPIを破壊する要因となるものはたくさんあった。
公開しているデータ構造及び仮想関数テーブルは特に変更に脆い。
そこで私が多く利用したテクニックは、”Cheshire Cat”であった。
（※データ構造を非公開にするOpaque pointerのこと）
MirALで再度目的を果たす
はずでしたが、残念ながら「Ubuntu Desktop」で「Mir」が日の目を見ることはなさそうです。「Unity 8」が開発中止となり、「Unity」が「Ubuntu 17.10」を最後に「Ubuntu Desktop」からなくなります。
「Ubuntu Desktop」のデスクトップ環境は「Ubuntu 18.04」にて「GNOME」に変わります。
「Ubuntu Desktop」の次期ディスプレイサーバーとして期待されていた「Mir」ですが、もしかしたらIoT向けに組込みシステムで活用される機会があるかもしれません。
