research/\343\201\252\343\202\223\343\201\241\343\202\203\343\201\243\343\201\246\351\226\242\346\225\260\345\236\213\343\203\227\343\203\255\343\202\260\343\203\251\343\203\237\343\203\263\343\202\260\343\201\247\347\240\224\347\251\266\343\201\256\343\202\263\343\203\274\343\203\211\343\202\222\346\233\270\343\201\223\343\201\206.md
... ...
@@ -20,14 +20,14 @@
20 20
- ただし、例外を発生させている時点で、純粋関数とは言えない。なので"なんちゃって関数型プログラミング"と呼んでいる。
21 21
22 22
### 方針2: テスト付きの小さくて分かりやすい関数をたくさん作る
23
-- DataFrameを受け入れ、DataFrameを返すような関数を作る。
23
+- DataFrameへの操作なら、DataFrameを受け入れてDataFrameを返すような関数を作る。
24 24
- pandasの操作は自分で関数化し、それぞれunittestを追加する。
25 25
- 最初は全てにテストを付ける必要は無い。
26 26
- unittestを書いているとコーディング時間が2倍になってしまうかもしれない…
27 27
- しかしコードの間違いに気が付かず、間違いの判明が後になればなるほど差し戻しの影響が大きくなる。
28 28
- できる限りテストを付けるのが大事である。
29
-- 思ったよりも自分はPandasの挙動は把握できていない場合がある。
30
- - 特にダウンサンプリング、アップサンプリングの挙動は難しい。
29
+- 思ったよりも自分はPandasやPythonの挙動を把握できていない場合がある。
30
+ - 特にpandasのダウンサンプリング、アップサンプリングの挙動は難しい。
31 31
- またpandasは多数の構文を許容するので、間違った構文でも動いてしまう可能性がある。（そして間違った結果がDataFrameに格納されて気が付かない。）
32 32
- ライブラリのバージョンアップを容易に出来る。
33 33
- それぞれの関数にテストを付けてあれば、バージョンアップで挙動が変わらないことを保証できる。