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

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

エンジニア研修によるプログラムの質の向上を計測する試み

 これから行っていく新しい研究テーマとして、プログラミングやソフトウェア工学に関する研修(講義・演習)が、どのぐらい受講者のプログラムの質に貢献するか、という課題に取り組むことになりました。

 

www.naist.jp情報系企業の新人研修は、多様な出身の新卒エンジニアの知識の底上げを図っていますが、画一的な研修を行うと、情報以外の分野出身の人には難しすぎ、情報系で頑張ってきた人には簡単すぎるといったように、誰にとっても退屈なものになってしまう恐れがあります。また、研修を行う側にとっても、研修の効果が客観的にはわからないために、教材や教え方を改善することは困難となっています。

そこで、当研究室では、まず研修という活動の効果がどのように計測可能であるかという点から始めて、現在行っている研修がどのような人に・どれぐらいの効果を持つのかを調査する方法を確立し、長期的には、ソフトウェア開発能力の測定方法や個人の現在の能力に合わせた研修の提供などの課題に取り組んでいきたいと考えています。

上記プレスリリースは、ソフトウェア工学研究室としては珍しく「これから行う」テーマの発表です。大学院でソフトウェア工学の研究に携わりたいと考えていて、プログラミング技術・ソフトウェア開発能力を計測するという目標や、データ分析という手段に興味のある方がいらっしゃれば、取り組む研究課題の候補として検討していただければ幸いです。

なお、このような研究発表としては資料が世の中に出ていないような研究テーマについて詳しく知りたい場合は、研究室訪問という形でお越しいただくのが早道です。研究室を訪問可能な日の候補をいくつか「いつでも見学会」のサイトからご連絡ください。この申し込みはちょっと物々しい印象があるかもしれませんが、これが研究室訪問を(必要であれば複数研究室同時に)申し込むためのメール窓口になっています。ソフトウェア工学研究室の訪問を希望すると明記されていれば当研究室スタッフから返信しますので、単に送ったメールが見逃されにくいメールアドレスであるという程度に考えて、気軽にお送りください。

 

開発者が行ったソースコード修正作業を学習し代行するボット

当研究室の D1 上田 裕己 君の「開発者が行ったソースコード修正作業を学習し代行するボット」というプロジェクトが、2019年度未踏IT人材発掘・育成事業に採択されました。

 www.ipa.go.jp

このプロジェクトは、彼自身が当研究室の修士論文等で研究してきた技術を基盤に、1年間で応用的なソフトウェアを世の中にリリースすることを目指しています。

研究内容をよく知っている教員でも実際どのぐらいのものが作れるか予想がつかないところですので、研究面での関連情報を提供しながら、今後の展開を見守りたいと思います。

 

Heijo: コード実行可視化によるJava/Androidアプリケーションのリアルタイムプロファイラ

2月に本ブログで紹介した論文が、ソフトウェア科学会論文誌「コンピュータソフトウェア」36巻2号に掲載されましたので、リンクを張っておきます。

Heijo: 動的なコード実行可視化によるJava/Androidアプリケーションのリアルタイムプロファイラ

論文の PDF は、論文誌の冊子体が紙として出される都合上、白黒となっています。カラーでどのように見えるかは、下記記事のものをご参照ください。

ishiotks.hatenablog.com

ソフトウェア工学国際会議 ICSE 2019 に参加しました

5月25日から31日にかけて、ソフトウェア工学国際会議(ICSE 2019)とその関連イベントが開催されました。

私たち奈良先端ソフトウェア工学研究室からは、ICSE本会議でフルペーパー 1件、ジャーナルファースト発表 1件、併設イベントであるプログラミングに関する視線トラッキングに関するワークショップ(EMIP)で発表 1件、プログラム理解に関する国際会議(ICPC)で大阪大学と共同研究のツールデモ発表 1件、合計4件の研究を発表しました。

本会議の様子については、D2の幾谷君による現地レポート記事があるので、そちらをご覧ください。

qiita.com非常に多様な論文が発表されていましたので、ソフトウェア工学に関わっている皆様には、ICSE 2019 勉強会でもその内容を確認していただければと思います。現在7月18日の開催で調整中ですので、予定を確保しつつ公式のアナウンスをお待ちください。

 

コードレビューは活発に活動している人ほど引き受けてくれる

今月末に開催されるソフトウェア工学の国際会議 ICSE にて、Journal-First Track という「論文誌に採択されたが国際会議では未発表」という原稿について、私たちの研究室から1件発表があります。

arxiv.org

 この論文は、オープンソースソフトウェアプロジェクトで行われているコードレビュー活動を調査し、「誰に依頼すると、引き受けてもらえるのか」を機械学習で予測する方法を考えた論文です。データセットには、Android, LibreOffice, OpenStack, Qt プロジェクトに投稿されたパッチ 230,090 個を使っています。

 この論文では、コードレビューは誰でも引き受けてくれるわけではなく、16%から66%のパッチで、レビューのお願いに反応してくれないレビュアーが 1人以上いることを報告しています。引き受けてくれないことがあるからと多数の人に依頼を出すのは迷惑ですから、レビューを引き受けてくれそうな人に依頼を出すというのが課題になります。

 この「レビューに参加してくれそうな人」を予測するとき、レビュアーの "Human Factor" を含めると精度が向上する、というのが論文の報告です。Human Factor といっても色々ありますが、強く効くのは「レビューを引き受けてきた割合」と「これまでに書いたパッチの数」です。そのほか、これまでに書いてきたレビューの数や、レビューとして記述するコメントの量、現在実施中のレビューの数などが予測に寄与する要素となっています。

 この結果は、いつもコードレビューを引き受けてくれる、まじめにレビューを書いてくれる人ほど、これからも引き受けてくれる可能性が高いということを示しています。これだけ聞くと当たり前のようにも思える話ですが、従来研究ではパッチの内容に関係した知識を持っていそうなレビュアーを推薦することだけが考えられていたので、その人たちの過去の行動まで加味したほうがよいことを示した、というのがこの論文の貢献になります。

 この結果をレビュアーの自動推薦に単純に組み込むと、「引き受けてくれる可能性が高い人」を推薦しやすくなるという点では有益ですが、やりすぎると、現在頑張っている人たちにさらに依頼が集中しすぎて、破綻する可能性があることです。作業負荷を能力や態度に合わせて公平に分配できるようになるには、まだまだ先は長そうです。

 

キャメルケースはスネークケースよりも読みやすい説

プログラムの識別子として複数の英単語をつなげるとき、単語区切りを大文字にしてつなげる CamelCase と、アンダースコアを使ってつなげる sanke_case の2つが良く使われています。この2つのどちらが読みやすいのか実験をした人がいる、というのが意外と知られていない気がしたので、ちょっと紹介しておきます。

To camelcase or under_score - IEEE Conference Publication (著者が配布している版はこちら)

この論文は被験者実験を行っています。 "extend alias table" のようなフレーズの後に、それを識別子に変換したもの(キャメルケースの場合 "extendAliasTable" )と単語のうち1つを偽物に入れ替えたもの(この例の場合 expandAliasTable, extendAlistTable, extendAliasTitle)を表示して、その中から正解を選ぶというタスクにおいて、被験者が目的のフレーズに当たる識別子を正確に、早く認識できるかを調査しています。

基本は統計的に有意な差が出るかどうかの判定をしていて、結果は以下の通りでした。

  • 認識の正確さはキャメルケースのほうが高い(オッズ比 1.515)。
  • キャメルケースのほうが認識に少し時間がかかる(13.5%、実時間にして0.42秒)。
  • レーニングが正確さに影響するかは分からない(帰無仮説が棄却できない)。
  • レーニングで認識にかかる時間は短くなる。

この論文では2つを比べるという都合上、キャメルケースのほうが良いという結論になっています。ただし、この実験設定はけっこう意地悪でもあって、似たような識別子がたくさん並ぶ状況ならば省略表記のほうが読みやすいという指摘もあります。関連研究のところにそういうこともしっかり書いてあるので、論文の著者らもキャメルケースを本気で押そうと思っているわけではなさそうです。

認識時間にほとんど差がなく、トレーニングで認識にかかる時間が短くなるということから、使い慣れたほうを使うほうが早いという常識的な話とも言えてしまいますが、この論文は「読みやすさ」というあいまいな指標を正確さと時間に分解して計測するという実験の作り方として参考になりますし、この研究から視線計測に基づく視認性の調査などにも続いていますから、ソフトウェア工学の中でもプログラム理解という分野を学ぶ上では良い材料であると思います。

 [2019/4/17 追記] この記事を書いた後に気づいたのですが、プログラム理解に関する国際会議(ICPC 2019)の開催情報によると、この論文がちょうど10年前に発表された論文の中から最も影響の大きかった論文(Most Influential Paper)に選ばれたようです。

 

スマートフォンを支えるオープンソースソフトウェア

IPSJ-ONE にて、「ソフトウェアの生態系を探る」というタイトルで登壇してきました。

ipsj-one.org

この発表では時間の都合上、まったく言及することができませんでしたが、「ソフトウェアの生態系(Software Ecosystem)」と総称されるオープンソースソフトウェア群は日常生活に非常に密接にかかわっています。

私たちにとって身近で、かつ、オープンソースソフトウェアを活用している筆頭と言えそうなのが Android プロジェクトです。Android SDKソースコードをダウンロードしてくると、2019年2月時点で、external ディレクトリに300個ぐらいのソフトウェアが並びます。この中には、たとえば以下のようなものが入っています。

  • 1979年に発表された Basic Linear Algebra Subprograms に由来するベクトルや行列を扱うライブラリ。OpenCV なんかも同じ仲間と言ってよいかもしれません。
  • 1984年頃からインターネットの発展に伴って登場してくる、TCP/IP ネットワーク系のツール(ppp, tcpdumpなど)。
  • 1989年頃から登場し始めた giflib, libjpegなどの画像処理系ライブラリ。
  • 1995年頃から登場した zlib, bzip2 などのデータ圧縮・展開ライブラリ群。libpng のように zlib に依存した画像処理なんかも登場します。
  • 1998年頃から揃ってくる動画、音声、XML などの各種データフォーマットを扱うライブラリ。
  • 2003年頃から登場してきた、LLVMApache Ant、JUnit などの開発環境、テスト自動化系のツール群。

スマートフォンが音声や映像、通信を扱うことを考えると入っていておかしくないものばかりですが、有名ツール、プロジェクトがけっこう入っています。約半分は Android が発表される以前のもの(Copyright を見ると 2008年以前)となっていて、実績を積んできたソフトウェアたちが今も活躍しています。COBOL のプログラムが今も企業のビジネスを支えていたり、昔のゲームソフトが今も遊ばれているのと同じように、「必要なソフトウェア」は、しっかり長生きしています。

プロジェクトの由来は手作業で調べているので、勘違い等もあるかもしれませんが、これらのソフトウェアの Copyright には MicrosoftIntelApple、複数の大学の名前も入っていて、コミュニティ全体で協力して信頼できる基本部品を整えるという最近の時流がよく分かる事例になっていると思います。気になる方は、ソースコードをダウンロードして Copyright という文字列を検索してみてください。