前回の記事↓で国内ソフトウェア工学事情を勢いに任せて書いたら思いのほか炎じょ……バズってしまい、しかも身内のソフトウェア工学の先生方に火をつけまくってしまいまして、いやはや。関係者の皆様すみませんでした*1。
フォローの記事も書こうと思ってたんですが、少々タイミングを逸してしまった感。でも少し誤解を与えたところもあるんで、また時間ができれば書こうかと思います。
bonotake.hatenablog.com
しかし、それから一週間くらい経ちまして、今度はソフトウェア工学に関わる人間としてはなかなか嬉しいニュースが。
それで、つい以下のようなツイートをしたところ、これも軽く話題になってるようで、今もまだ通知が止まらない感じです。
automatic repair、ついに来たか
— takeo (@bonotake) 2018年9月14日
これはガチで近年のソフトウェア工学の成果
Facebook、バグを自動で修正する新ツール「SapFix」開発 https://t.co/X0D6Xidmj1 via @cnet_japan
バグの自動修正（automatic repair）はここ数年ソフトウェア工学の国際会議ではかなり盛り上がってる研究トピックです。
これをFacebookがツール化した、というので、やはりこの分野の人間としては大変気になるところ。話題としてもキャッチーですしね。
しかも、この開発リーダーを務めたMark HarmanのFacebookへの投稿を読むと、
I am really delighted and also very proud that we are, today, announcing the first industrial-strength scaled-up automated program repair, now in continuous integration and deployment at Facebook.
とあって、社内の開発フローにさっそく組み込まれた模様。
ちなみにこの Mark Harman、ソフトウェア工学の世界ではプログラム解析の大御所として著名な研究者で、UCL（ロンドン大学）の教授でありながら、最近はFacebookの Engineering Manager （エンジニアの統括マネージャー？）を務めています。
こういったあたり、海外のソフトウェア工学分野は産学が上手く結びついてるんだなぁ、というのを感じさせますねぇ。
で、そのMark Harmanが陣頭指揮を取って開発した自動バグ修正ツール "SapFix" なんですが、Facebookのブログに簡単な解説記事があります。
code.fb.com
ということで、この記事では残り、このブログ記事を元に、SapFix がどんなツールなのかを簡単に解説していきます。
ちなみにざっと読んだところ、実はそんなに凄いことはしていません。
Androidアプリを対象に、まず自動テストツール "Sapienz"を使って自動テストをかけます。なおこのSapienzも、search-based testing という、最近研究が盛んな技術を元にMark Harmanの研究室で開発された自動テストツールなんですが詳細は省略。ご興味ある方は（＋論文読める方は）以下の論文をば。
で、このテストでクラッシュが観測されるとSapFixが稼働するわけですが、その内容とは
- 過去の修正から人手で作った修正パッチのテンプレートを、そのまま持ってくるか、あるいはそれがハマらなければミューテーションを使ってテンプレートを変形してパッチを作成。
- 上で出来上がったパッチを元に、さらに複数のパッチを生成。
- 生成したパッチがコンパイルを通るようなら、さらに開発者が人手で書いたテストとSapienzで生成したテストを流して、このパッチでもうクラッシュが起こらないか＋別のクラッシュが発生しないかチェック。
- チェックを通ったパッチは人間がレビューして、良さそうならそのパッチを適用。
なお1. で使われてるミューテーションっていうのは、文法に従ってプログラムを適当に（'+' を '-' にしたり、変数名を入れ替えたり）書き換える……というもので、元々はわざとバグを埋め込んでテストがそれを見つけられるかを診る、テストを評価するために生まれた技術なんですが、早い話、要はデタラメに書き換えてるだけです。
いかがでしょう。ぶっちゃけ全然凄いことしてません*2。むしろ「えっ、これでホントにバグ直るの？？」ってレベルです。
ただ、個人的には結構感心しました。まぁこれが実用上使いものになるかどうかはこれからの評価を待たないといけなさそうですが、これで本当に使えるんならすごいなと。
automatic repair には例えばプログラムの意味まで踏み込んで理解し、バグの内容をちゃんと解析した上で然るべき修正パッチを生成する、なんて手法も研究されてます。で、第一線の研究者が開発に携わってるんで、そういうアプローチも知らない訳はないと思うんです。
でもそういうの敢えて使わずに、簡単な解析だけど軽くて実用のソースコードのサイズに耐えうる技術を使ってるんじゃないですかね、これ。
そういう、研究者の独りよがりでない「現場で使えればいいじゃん」っていう割り切りが凄いなと。
あとはこう言ったら言葉が悪いですが、こんな簡単な解析＋自動修正を「数撃ちゃ当たる」的にやっても効果が出ちゃうほど、現場ではしょうもないバグが頻発してるってことなんだと思います。
これも勝手な推測なんですけど、FacebookみたいなDevOpsベースの企業では超短期開発でひたすらアップデートをかけ続けてるはずで、開発＋リリース前テストに手間隙かけるよりは、実装はなるたけ簡素に済ませて、CI使って物量でバグを短期間に潰す、ってスタイルを採ってるのかな、と想像します。それならこの手法でも十分効果あるんではないかと。
ということで、最新鋭の技術とかを駆使してるわけでもなければ、理論的に凄い技術も使ってない、でも自らの開発現場に見合った、実用上もっとも効果がある技術を採用しているってことなのかな、と思った次第。
それでも実際の開発フローに組み込めるまで持っていくあたり、相当な作り込みをしてるんじゃないかな、とは想像しますが。これで本当に効果あったらすごいですね。
先のブログ記事によると、もうちょい手を入れた後でこのSapFix（と、テストツールSapienz）はオープンソースにする予定だそうで、ぜひ、中身を覗いてみたいです。
p.s. ……と、この記事をちょうど今書き終わろうかってところで、当の Mark Harman からFBで友達申請が来ましたｗ びっくりしたー。ツイート見られちゃいましたかね。
追記） 一晩明けてちょい読み返して思ったんですが……全体的にものすごく簡単な技術で構成してるのは事実だと思うんですが、絶対どこか一工夫は入れてると思います。特に怪しいのはパッチを複数作成するところ。脚注には元々書いてますけど。
ここは多分論文書いてどこかに投稿中なんで、まだ明かせないんだと思います。もしその論文が入手できたら補足記事を書きます。
