Overview
Jupyterを使って他人と一緒に作業をするときに、相手に気をつけて欲しいこと、自分が気をつけてることについて、まとめていく。
複数人でのJupyter上での作業は何かとやりにくさがある。実験的なコードが多くて読み難かったり、そもそも、実行可能なのかがわかり難かったり。実際には何かしらのマネージメントサービスと連携させたり、チームでルールを設定したりするわけだが、いつでもそれらを設定できるわけでもない。個人レベルの意識でどんなことを気をつけることができるのか、どんなことをやめて欲しいのか、どうしてくれると嬉しいのかをまとめていく。
絶対に気を欲しいこと
使用されてないコードは残すな
Jupyter上では、簡単にコードを書いて様々なことを手軽に確かめることができる。よくあるのが、最終的に使われてないコードがそのままに残っていることだ。これらがそのまま残ってると、他の人がJupyterファイルを開いた時に最初に行うのは、アクティブなコードとそれ以外の仕分けだ。全体のフローもわかりにくくなるので忘れずに消そう。もしも、使用はされていないものの、重要な部分であるならばコメントアウトなり何なりして、アクティブなコードではないことを明示しよう。
上から順に実行できるようにする
個人的にはこれは本当に気にして欲しい。Jupyter上ではCellを追加、挿入をすることができる。そのため、試行錯誤の中で、最終的に通しで実行するためには、下から上、上から下と、めちゃくちゃな順番でCellを実行しなければいけないファイルが出来上がることがある。（個人的には、そもそも実験段階でもこんなワークフローは避けるべきだと思うが。）
この手のJupyterファイルは共同作業者からすれば最悪だ。きちんと実行順序を把握するのも面倒だし、自分で整えた順序が本当にコードを書いた人の意図したものなのかもわからない。せめて、人とシェアする前に、上から実行できるように整えておこう。
必要なファイルの上書きコードを残さない
共同作業者は言う。『そのコード、動くから。実行しなくて良いから。』
正直な感想は『知らんがな』だ。Jupyter上のコードだ。多くの場合はテストがない。本当に動くかどうかなんてわからんし、そもそも、各パーツごとにどう動くのかきちんと確かめる必要がある。そのJupyter上で作業するってことは何らかのタイミングで少なくともコードの実行はするものだ。その実行によって大切なファイルが上書きされて、大変なことに。。ってのはあってはいけない。
いつ、共同作業者がJupyterのコードを実行しても大丈夫なように、必要なファイルはバージョン管理なり何なりしておこう。
気をつけてくれると嬉しいこと
参照してるファイルの情報を残してくれ
Jupyterファイル内のCellのコード。
data = pd.read_csv('s3://hoge_1/hoge_2/processed_data.csv')
このprocessed_data.csvがどこからなり取ってきたものでチーム内で共有されているなら良い。めんどくさいパターンは、このファイルが別のJupyterファイルで生成され、保存された場合。このファイルを生成しているJupyterファイルを探しにいく必要がある。でもって、よくあるのが、複数のJupyterファイルが、このファイルを保存するためのコードを持っているパターン。どのファイルから作られたのよ？？
何かしらのマネージメントサービスを使ってないなら、せめて、このファイルがどのJupyterファイルから作られたのか、コメントくらいは残して欲しい。辿っていくのが本当に大変。
関数を使ってネームスペースを限定してくれ
Jupyter上では手早く様々な実験をできる。そのためか、グローバルスペースにガツガツとロジックが書かれ、一つの変数名が繰り返しの上書きで再利用されることもしばしば。それが、小さいJupyterファイルならまだ良いが、こういうファイルは100 Cell以上からできてたり。
Cellを関数単位感覚で使ってるようなコードもよく見るが。それなら関数定義しよう。
実行を確認するためのサンプルされたDEVデータを用意してくれ
上にも書いた通り、共同作業者の書いたJupyter上でのコードが本当に動くかどうかなんて、実行しなければわからない。テストないし。
流石に、全てのプロセス用にテストを書けとまでは言わない。でも、大きなプロセス単位でプログラムの確認をするようにフィクスチュアデータは欲しい。きちんと明記されたフィクスチュアデータあれば、プログラム実行時も何かしら必要なファイルの上書きの可能性についてもそんなに神経質にならなくて済むので気が楽だ。もちろん、自分でサンプリングを行ってデータを作るのは全然構わないし、実際そうしてることが多いのだが、それも、時によっては結構時間がかかる。
簡単にで良いからリファクタしてくれ
ある程度コードを書いて、実行を確認したら、10分で良いから立ち止まってコードのクリーニングとリファクタリングをしてくれ。その10分は他の人の1時間を救う。
ファイル名に合ったコードだけ残す
ファイル名はdata_creation.ipynbなのに、データセット作成、モデリング、評価まで全部行ってるファイルがあったりする。おそらく、ファイル名を考えたときはデータセット作成のためだけを考えていたのだろうが、作成後にそのままそこで作業してしまったのだろう。分割するかファイル名を変えるかして欲しい。そのようなファイルが10、20と存在すると、開けるまで何があるかわからないブラックボックス状態だ。
実行にリソースの問題がある部分にはプロファイル情報を残してくれ
時間がかかりすぎるとかメモリを食いすぎる部分の実行には簡単にで良いからその情報を残して欲しい。Cellのマジックコマンドでも良いし、コメントでも良い。大きな問題を抱える部分が、何の明記もなくそこに存在し、長時間の実行の後に問題に気づくなんて面倒だし、共同作業者としてパフォーマンス改善を行うにしても事前情報が明記されているだけで、だいぶ手間が省ける。
最後に
人によっては、『プログラマが普通にコード書いてたら起こらない』とか『綺麗なコード書け、で十分』と思う人もいるかもしれないが、Jupyterでの共同作業者はプログラマのみではない。割と広い範囲の人が、共同作業をしうる。
そうした時に、互いの意識で互いに幸せになれるのは上記のラインなのかなと思ってる。