2019年9月30日から10月4日まで、アメリカ・クリーブランドで開催されたソフトウェア保守と進化に関する国際会議 35th IEEE International Conference on Software Maintenance and Evolution に参加してきました。
筆者の研究室と直接関係する発表は、筆者と大阪大学の共著による Near-Omniscient Debugging for Java Using Size-Limited Execution Trace というツール発表です。Omniscient Debugging （全知デバッグ、またの名を Time-Travel Debugging, Reversible Debugging）を本気で実装すると実行トレースとして 10 MB/s ぐらいのデータ量を保存する必要があるのに対し、各命令に対して最大 k 回までとデータ量を限って情報を保存すれば、1％以下のデータ容量で、８～９割程度のデータフローが追跡できるようになる、といったコンセプトを示しました。発表資料はこちら（大阪大学ソフトウェア工学研究室のページ）からダウンロードできます。
同会議および併設イベントでは、このほか、先日ソフトウェア設計学研究室で博士課程を修了した Md. Rejaul Karim さん筆頭の Identifying and Predicting Key Features to Support Bug Reporting という論文のほか、東京工業大学、早稲田大学、広島市立大学、大阪大学、日立製作所からの研究が発表されていました。
本会議１日目の基調講演は Laurie Williams による「Software Engineering Research: Beyond Impacting Practitioners」。研究者が追及する State of Art もよいが、それが実務者や社会に対してどのような意味があるのか、State of Practice、State of Society を考えるように、という内容でした。例としてセキュリティの研究者が議論している高度な攻撃・防御方法のほとんどは、きちんとパッチ当てる、適切なパスワードを設定するといった普通の人が日常的に遭遇する問題の解決には役に立たないこと、たくさんのシステムに確実にパッチを当てるのは新規性のある研究にはならないが非常に難しいことを引き合いにして、研究と社会の関係を改めて見直すことを提案していました。
基調講演では、紹介された研究の価値を考えるためのテンプレートとして、以下の文章が示されていました。
The goal of this research is to aid [stakeholder] to [solve problem] through [research technique].
ICSMEに採録された論文から実際にこの文章を作ってみると、多くの論文は開発者に対する技術であり、また研究者やユーザのための技術もあるが、一部論文にはこれが書かれていないと指摘していました。そして、Academia には研究のためのデータはないが頭脳がある、Industry には課題とデータはあるが時間がない、だから産学連携が重要であり、「できるからやる」研究をするのではなく、世の中を良くするための研究をする意識を持つように、そして OSS は世界全体ではないと、安易に OSS のデータ解析に流れがちな研究者に対して釘を刺しつつ、話を締めくくっていました。上記のテンプレートは、簡単で任意の研究で使える、分かりやすいものだと思います。
本会議ではたくさんの論文が発表されていましたが、筆者にとって今回印象的だったのは Keith Gallagher らによる「Teaching Software Maintenance」です。チームで既存のソースコードを調べ、修正すべき場所を特定し、影響を予測するといったソフトウェア保守の活動をどのように授業（演習）として行ったかを報告した論文でした。学生にとっては非常に大変な思いをするが、同時に満足度も高い授業の基本的なやり方と、その結果得られた経験について説明されています。
また、Industry Abstract として論文自体は非常に短い（詳細が書かれていない）ですが、Hyrum Wright による「Lessons Learned from Large-Scale Refactoring」というタイトルの発表も非常に個性的でした。Google では全員が20億行のコードベースを共有しており、コンパイラやライブラリの更新など、システム全体に影響を与える大規模更新が行われること、そしてそれを自動的に適用するには自動テストが重要であることと、勝手にコードを変更されるのを許容する文化が必要であることを説明していました。さらに、API に対してたくさんの利用者がいると、動作に関する取り決めは意味がなく、観測できるあらゆる振る舞いに誰かは依存してくる（With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.）ということを Hyrum's Law と言いたい、と述べていました。たとえばハッシュ辞書というデータ構造の中に格納されたデータは、イテレータを使った取り出しに対して順序を保証しませんが、たまたま社内で最初に使っていた実装では特定の決まった順序（登録順）で出てきていたために、コードの一部はそれを前提にしたものとなっていて、あとでセキュリティ的な理由で順序をランダムにしたとたん、たくさんのコードが壊れてしまったそうです。言い換えるなら、どんな変更を加えても振る舞いが少しでも変われば誰かは影響を受ける、そしてその影響は変更をした人が悪いわけではない、ということでもあります。この話の細かい主張については 詳細が書かれた Web サイト（Hyrum's Law）をご覧ください（この記事を執筆中の現時点では、残念ながら上記のような具体例は掲載されていませんが）。
なお、全体的な傾向としては、研究対象ソフトウェアのドメインとしてマイクロサービスとモバイルアプリの話題が増加していました。技術的な側面はコードクローンや技術的負債、継続的インテグレーションなど、昨年と大きな変化はないように思いましたが、たとえば Etherium のスマートコントラクトに対するコードクローン検出など、今ある技術を新しいソフトウェアに適用するものが目立ったように思います。
