今後の開発スケジュール

先月は引越し & 仕事のトラブルでヘトヘトでした。それと、個人的なことですが、入籍しました。式は今年の秋ごろを予定しています。なので、AquaSKK の開発に使える時間は一段と減りそうです。式の準備のことを考えると、とても憂鬱になりますね。とほほ。


それはさておき。


AquaSKK の開発スケジュールでは、現在ベータテスト中の数値変換をリリースした後は、自動ダイナミック補完を実装する予定でした。確か、数値変換のリリースが 6 月で、自動ダイナミック補完が 9 月だったと思います。


数値変換のほうは一月遅れて 7 月中にリリースできると踏んでいるのですが、自動ダイナミック補完のほうは全体的に見直しをかけて、リスケをしたいと思います。まず、主なタスクを以下のように定義します。

  • 新エンジンの追加
  • レガシーエンジンとの互換性の確保
  • 自動ダイナミック補完の実装
  • レガシーエンジンの切り離し

自動ダイナミック補完を実装するためには、まず、現在の入力コンポーネントリファクタリングが不可欠ですが、機能はそのままでコードを徐々に作り替えていく、ということはしません。現在の入力コンポーネント(=レガシーエンジン)はノータッチのまま、新エンジンのコードを追加していきます。


「作り替え」ではなく「付け足し」にする一番の理由は、新旧エンジンのデザインが大きく異なるからです。なので、旧から新に徐々に移行するよりも、スクラッチから新エンジンを書き上げるほうが確実だと判断しました。


なお、二つのエンジンは同時に動作しません。環境設定で、どちらのエンジンを有効にするかを切り替え可能にします。つまり、レガシーエンジンは動作確認用のリファレンスとしていつでも使える状態にしておきます。保険ですね。こうしておけば、新エンジンの実装を進める時の不安感がずいぶん軽減されるはずです。


二つのエンジンの互換性が 100% になったら、新エンジンのほうに自動ダイナミック補完を実装します。互換性を取るといっても、潜在的なバグなどは除きます。これらはちゃんと修正します。そして、新エンジンが充分にこなれ、信用するに足るものだと判断できたタイミングで、レガシーエンジンは切り離します。ただこれは、随分先のことになるでしょう。


こうしてみると、かなりの大手術ですね。ざっとスケジュールすると、年内に互換性の確保まで持っていって、リリースは来年 3 月といったところでしょうか。ひょっとすると大幅に前倒しできるかもしれませんが、今のところは余裕を持ってスケジュールしておきます。


このあたりに関してアイデアやご意見があれば、是非お願いします。