研究の現場におけるコードの検証と共有(Google 牧野) 実況 by mamoruk

Mamoru B Komachi @mamoruk

NLP 若手の会シンポジウム、Google 牧野 (@ta_makino) さんの招待講演です〜「研究の現場におけるコードの検証と共有」という内容です！ #yans2014

Mamoru B Komachi @mamoruk

「このコードで本当にいいのか？」一人で書いて誰にも見られないコード……。ウェット系の研究では実験ノートが重要。ドライ系はコードがあれば再現可能？いやいや……。最初の論文に使ったコードはどこにある？動かせる？データは再生成できる？#yans2014

Mamoru B Komachi @mamoruk

科学の前提は、客観性と検証性（反証可能性）。新しい技術を取り入れて、研究ブロセスを再構築したい。まず、書いたコードの管理。前処理スクリプト、メインのプログラム、出力を後処理してグラフ化するコマンド。実はメイン以外も重要。管理しなさいといまはあまり言われていない。#yans2014

Mamoru B Komachi @mamoruk

コードの管理に必要な条件。いつでも以前の状態に戻せる。複数人がコードを修正・マージできる。誰が何を（なぜ）変更したのか調べられる。バックアップ。これらを実現できる、バージョン管理システム (git, cvs, ...) を使おう。#yans2014

Mamoru B Komachi @mamoruk

一般のファイル共有システム（Google Drive, Dropbox, ...）ではダメ？→ダメ。バージョン管理システムは、過去のバージョンを全部保持してくれる。変更した理由のコメントが残せる。行単位で変更を追跡できる。#yans2014

Mamoru B Komachi @mamoruk

研究室単位でリポジトリを用意しよう。実験実行前には必ずコミットするとか。すべてのコード、論文のソース、共有できるデータはリポジトリに保存する。1日最低1回は必ずコミット。#yans2014

Mamoru B Komachi @mamoruk

コードの検証。実験に使っているコードは本当に正しい？→正しさをちゃんと確認していないことが多い。一見分からない問題が隠れている。一度正しく動いてもあとの修正でバグを入れていることがある。システマティックな検証方法を用意する必要。テストコードを書こう。 #yans2014

Mamoru B Komachi @mamoruk

テストコードを書くデメリット。コードを書く量が増大する。機能を変更したときに、テストも変更しなければならない。開発効率が落ちる。テストコードを書くメリット。より早くバグの混入を検出できる。誤りに気づかず仕事を進めるほうが大損失。メリットがデメリットを上回る。#yans2014

Mamoru B Komachi @mamoruk

実行時検査。変数がありえない値になっていないか。プログラムが即死するので仕事では使いにくいが、研究では積極的に使ってよい。実行効率より人間の開発効率のほうが大事。結合テスト。自明な入力と出力を用意する。無効な入力にエラーを返す。必要なテストだけでもあるとよい。#yans2014

Mamoru B Komachi @mamoruk

ユニットテスト。関数やクラス単位で動作が設計通りか確認。複雑な関数を自分で作ったとき、ちゃんと動いているか、その部分だけでもテストする。サンプリングが含まれるコードとか。バグが見つかったら、修正するとともに、再発防止のためのユニットテストを追加するとよい。#yans2014

Mamoru B Komachi @mamoruk

シェルスクリプトでも Makefile でもいいが、全てのテストを実行して結果をレポートできるようにしておく。全て自分で書かなくてよい。やる気にあふれた学生は、全部自分でやりたがるが、はまることも多い。新たに書く前に枯れた実装がすでにないか調べた方がよい。#yans2014

Mamoru B Komachi @mamoruk

テストを書くのは他人のためばかりでなく、自分のためでもある。1ヶ月も経つと自分でもコードが分からなくなったりする。#yans2014

Mamoru B Komachi @mamoruk

研究室リポジトリへのコミットは、できるだけ小さな単位で頻繁に行なうべき。まとめてやろうと思って、できた試しがない。他の人もチェックできる。ただし、コミットしたら他の人が見てくれるとは期待してはいけない。研究室内ばかりでなく一般公開すると、誰もが使えるようになる。#yans2014

Mamoru B Komachi @mamoruk

コードリビューをお願いする。論文の査読と同じ。査読者は上の人である必要はない。同期のメンバーで十分。読む人も勉強になる。いつお願いすべき？　一度に大量にお願いされると大変なので、細かい単位でお願いするのが一番よい。ユニットテストをつける。#yans2014

Mamoru B Komachi @mamoruk

github を使えば pull request で自然とリビューができる。コードの管理、共有、研修がすべて実現できる。研究室レベルの開発でも、このようなコード開発手法を取り入れるべき。最低2人が賛同すれば導入できる。草の根からやるとよい。#yans2014

Mamoru B Komachi @mamoruk

勝手にコードリビュープロジェクト。github に研究コードを公開して、@ta_makino さんに pull request を投げると、コードリビューしてくれる。条件は、お返しに誰かのコードリビューを3件引き受けてもらうこと。#yans2014