研究のためのコーディング

小さく試す

プロットは1回の実行にはそこまでかからないが、何度も書き換えるのでうっとうしい

まずは小さなデータ、小さなパラメータで試して、一般のソフトウェアとして動作するかを試すべき

n種類の実行

環境（venv）の問題をあぶり出すための実行

ロジックの問題をあぶり出すための実行を経て、

実際のデータと向き合うための実行

初回から30分かかるプログラムを動かすべきではない

単体テストぐらいは積極的に書いたほうがいいんだろうなあ

リファクタリング

漬物石としてのゴミコード。ゴミというか複雑さが上からどんどん追加されていくと、前からあった部分へのリファクタリング圧力がかかる。その複雑さ/WETさは圧力であると同時に、リファクタリングのための具体例でもある。

図をつくる

1. 小さなデータで、手軽な図を

2. 大きなデータで、手軽な図を

3. 小さなデータで、きれいな図を

4. 大きなデータで、きれいな図を

計算のための時間

時間のかかるコードを書く

進捗を見えるようにする（安心する）

tqdmなど

途中で失敗しても、成功した部分を使いまわしてresumeできるようにする

Jupyterとコードの良いバランス

My proposal to you is modest:

Isolate numeric code.

Make numeric functions pure if practical.

Write tests for the numeric code

Write tests for the critical IO code

You’re going to get a lot of bang for your buck by writing unit tests - inline asserts and regression tests are also high payoff-to-effort.

Notebookの先頭にこれを入れると自動でライブラリをリロードしてくれる

code:py

%load_ext autoreload

%autoreload 2