ソフトウェア工学研究の日々

ソフトウェア工学の学術研究を紹介しています。ここではソースコードなどのプロダクトが研究の主役です。

開発者数が増えたときのソースコードの書き方のばらつきの増減

2019年の春から夏にかけてインターンシップソフトウェア工学研究室に来てくれた学生が2019年末のワークショップで発表を行いました.

How Do Contributors  Impact Code Naturalness An Exploratory Study of 50 Python Projects [ResearchGate.net]

Code Naturalness というのは言語モデルN-gram など)を使ってどのぐらいプログラムの中身が予測できるか,つまり「よくあるコード」か,というのを計測しようという考えです.OSS プロジェクトにおいて,人が集まっている度合いと Naturalness に相関のような関係があるのかを,開発がそれなりに長い Python プロジェクト50個で調査したものが以下の図になります.

f:id:ishiotakashi:20200131113113p:plain

論文 Fig.4 より引用.縦軸が予測のしにくさ.開発者数が多い(high),中間(medium),少ない(low) 3つのプロジェクト群のコードで,多いプロジェクトのコードのほうが内容が予測がしにくいという傾向が出ています.


 図を見ると,実は上から順に Hgih / Low / Medium と並んでいて,増えれば増えるほどばらつきが増えるというわけではないようでした.たとえば人数がある程度増えるとコーディング規約などが整備されて予測しやすくなるとか,大人数で開発するようなプロジェクトだと多様な機能を実装していくので(他にない独自の機能を作っていくので)予測しにくくなるとか,などの可能性があります.

 論文ではこれに加えて開発者の Python プロジェクトでの経験(GitHub上で見える活動量)との関係も調べてみたのですが,やはり単純に経験が増えれば予測しやすくなるというわけでもないようでした.

 ソフトウェアの機能や熟練度,開発体制など,ソースコードの内容に絡んでいそうな要因を切り分けていくこと,そして Naturalness という指標自体の性質を調べることが,今後の課題となっています.

 

コードレビューのコメント量はプロジェクトによる

コードレビューで開発者はどのぐらいコメントをしているのか、私たちの研究室で調べた論文が電気情報通信学会の英文誌に掲載されました。J-STAGEからどなたでもダウンロードすることができます。

www.jstage.jst.go.jp

この論文では、Chromium、AOSP、Qt、EclipseLibreOffice という大手プロジェクトでのコードレビューにおいて、コメントの数と、コメントの長さ(単語数)が時間経過・レビュアーの経験によって変化するかを調べました。論文の調査結果から言えること(Implications)としては、以下のようなものがあります。

  • コードレビューのコメント数は平均すると3~13。1コメントは平均22単語。プロジェクトによっても大きく異なる。
  • コメントの数や長さは時間によって変動する。システムが成長するにしたがって増えていく傾向はあるようだが、開発者もレビュアーも相手のコメントのうち必要なもの・興味のあるものにだけ反応するので、必ずしもそうとは言えない。
  • 上記2つの結果から、「このぐらいコメントをしたからレビューもそろそろ終わりだろう」というような予断はできないということになる。
  • 開発者は経験が少ないと、レビュアーは経験が多いと、コメントをたくさん書く傾向にある。もちろんパッチの長さもコメントの量に影響する。パッチに関する議論を短く済ませたい場合は、経験とパッチの長さの両方に気を付ける必要がある。論文には明記されていないが、議論が短くてもバグを見逃したら意味がないし、開発者が経験を積むにも時間が必要なので、たとえば開発者は経験を積むまでは小さなパッチ投稿(で済みそうな Issue の解決)からやっていくというのが良いのかもしれない。

  本当は「このぐらいレビューコメントを書くのが基本ですよ」というようなガイドラインが出ればよかったのでしょうが、残念ながらプロジェクトによる、時期にもよるで、そういう話にはなっていません。この研究はコメント量の話だけで、検出されたバグの数に関しても考慮していないので、活動量に対する効果まで議論できるようになるにはまだ研究が必要なのだろうと思います。

 ちなみに、論文ではプロジェクトに投稿されたパッチ数(Workload)とコメント数の関係も調べていて、影響が小さいことが図表に出ています。プロジェクトが忙しくとも、レビューの活動量に影響が出ていないということは、「忙しいからレビューを簡略化してしまってバグを見逃す」ということはないのかもしれません。こちらも、バグの検出数などをうまく調べることができるようになれば、今後、細かい議論ができるようになるかもしれません。

 

ソースコードの類似度計測ツールの利用例を Jupyter Notebook として公開しました

Google Colaboratory を使って、ソフトウェア工学研究室で開発しているソースコード類似度計測ツールの利用方法を Jupyter Notebook 化してみました(シェルコマンドを並べているだけなので Python 要素は皆無ですが)。

grep 的に類似ソースコードの断片を検索する NCDSearch の利用方法がこちら

ファイル単位で類似度を計算するためのハッシュ値を求めるツールの利用方法がこちら

どちらも Notebook 内部に実行例が保存されているので、リンク先を見に行くだけで Google のホスト上での実行結果を確認することができます。また、Jupyter Notebook 的な良さとして、その場でオプションを書き換えて実行しなおすことができ、結果の変化もすぐに確認することができます。

ソースコードの類似度計測はコードクローン検出という名前でも知られる技術の1つですが、具体的にどんな入力からどんな出力を出すものなのか、ちょっと結果を見てみたいという人はぜひご覧ください。各 Notebook とも、末尾には対応する論文や資料へのリンクも用意してあります。

 

プログラミング言語処理の練習課題

研究ではプログラミング言語で書かれたソースファイルの中身を調べることが多くありますが、そのような処理をどのようにプログラムで記述するかまでを入学時点で知っている学生は、ほとんどいません。各研究課題に合わせて、プログラミング言語の字句解析や、構文解析といった技術について勉強をしてもらっています。

そのための資料の一部は SlideShareGitHub で公開しています。どのような感じの技術であるか知りたい人はご覧ください。

www.slideshare.net

スライドに書かれた演習問題(Java プログラムの中に定義されたメソッド宣言の一覧を取ってくるなど)は、この手の研究を始めるにあたってよくある処理の代表のつもりで選んでいます。スライド内で参照されているリポジトリGitHub - takashi-ishio/ParserExample)に、Java で記述された構文解析の実装および実行例を収録しています。自分で作らずに回答だけを見たい人は "implemented" ブランチのソースコードをチェックアウトして実行してみてください。実行をコンソールで行う手順を Google Colaboratory を使って作ってみたものがこちらにあります。

プログラミング言語処理には馴染みがない人も多いかもしれませんが、こういうものから簡単に触れてもらって、興味を持ってもらえると幸いです。

 

Git の diff では --histogram を使うべき

当研究室博士後期課程の Yusuf Sulistyo Nugroho さんが発表した、言いたいことは論文のサブタイトル("Use --histogram for code changes")で終わっている論文です。オープンアクセスとなっているので、どなたでも全文をダウンロードできます。

link.springer.com

git diff では使用するアルゴリズムをいくつかから選ぶことができます(参考:Git のオプションをまとめられている方の記事)。この論文では、アルゴリズムを histogram にした場合としない場合でどちらが良いか、また、そのような差が、diff をベースにしてバグが最初に導入された原因コミットを特定する技術(を使った各種研究)に影響する可能性を議論しています。

研究のアプローチは、21,590件の変更に対して、母集団を代表できるよう377件をサンプリングして、それらを手作業で調査する、という方式での調査となっています。画期的な方法があったわけではなく、地道な調査です。

結果として、diff アルゴリズムの結果は劇的に違うわけではないが、histogram のほうが良い、と報告しています。この報告の影響で、git の Windows Explorer への統合等の UI を提供している gitextensions プロジェクトでも histogram をサポートされるようになりました。以下の issue として論文(の著者最終版)が引用されています。

github.com

Git のオプション自体はこの研究を行う前から存在していたので、やったことだけを見ると「オプション機能1つの効果を調べた」という一風変わった論文となりました。様々なソフトウェア工学の研究で Git が基盤ツールとして使われるから、重要性を査読者に高く評価してもらえたのだと思います。

 

ソフトウェア保守と進化に関する国際会議(ICSME2019)に参加してきました

 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%以下のデータ容量で、8~9割程度のデータフローが追跡できるようになる、といったコンセプトを示しました。発表資料はこちら(大阪大学ソフトウェア工学研究室のページ)からダウンロードできます

 同会議および併設イベントでは、このほか、先日ソフトウェア設計学研究室で博士課程を修了した Md. Rejaul Karim さん筆頭の Identifying and Predicting Key Features to Support Bug Reporting という論文のほか、東京工業大学早稲田大学広島市立大学大阪大学日立製作所からの研究が発表されていました。

 本会議1日目の基調講演は 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 のスマートコントラクトに対するコードクローン検出など、今ある技術を新しいソフトウェアに適用するものが目立ったように思います。

 

ソフトウェア工学国際会議 ICSE 2019 の発表スライド日本語版を公開しました

日本ソフトウェア科学会第36回大会にて、トップカンファレンス特別講演という発表の機会をいただきました。このとき使用したスライドを SlideShare にアップロードしました。

www.slideshare.net

論文の大まかな内容については過去の記事にありますので、そちらをご覧ください。あえて短くまとめると「コメントに書いた URL は、リンク先の内容が変わったり、リンク切れになることが結構あるので、便利だけど気を付けよう」というところです。

会場における質疑応答で、最も考えさせられたのは、URL をコメントに書くのはダメだと言われたとき、どうしたらよいかというご質問でした。URL はリンク切れになるリスクがあるのは間違いなく、しかし設計や実装における何らかの意思決定にかかわる技術資料をすべてリポジトリに詰め込んでおけばよいのかと問われると素直に肯定できません。それではどうするべきか、というドキュメント管理のベストプラクティスは私の知識不足もあって会場では回答することができませんでした。ご存知の方がいたらぜひご教示ください。