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
... ...
@@ -19,8 +19,22 @@
19 19
- エラーハンドリングで頑張るのでは無く、エラーが起きる度に正していく。
20 20
- ただし、例外を発生させている時点で、純粋関数とは言えない。なので"なんちゃって関数型プログラミング"と呼んでいる。
21 21
22
-### 方針2: テスト付きの小さくて分かりやすい関数をたくさん作る
22
+### 方針2: 小さくて分かりやすい関数をたくさん作る
23 23
- DataFrameへの操作なら、DataFrameを受け入れてDataFrameを返すような関数を作る。
24
+- unittestを書くのが簡単になる。
25
+ - 特定の入力に対して出力が一意に定まるようになるので、テストを容易に作れる。
26
+- LLMの支援を受けやすい。
27
+ - LLMは小さな関数を作るのが得意。
28
+ - 「入力されたDataFrameのカラムAとカラムBを使ってDataFrameにカラムCを追加して」のような。
29
+ - プロンプトを考える人間の負荷も低い。
30
+- 共通化できる処理は積極的に共通化する。
31
+ - 共通したコードを使うことでメンテナンス性が向上する。
32
+ - 片方は直したけど、こっちでは直し忘れていた…ということを防げる。
33
+ - 例外的な対処が必要な場合は、明示的に条件分岐して処理する。
34
+ - 「この実験の時は実験条件○○が特殊だったから、この値に反映しないといけない…」
35
+ - 関数に実験名も入力として渡せば条件分岐できる。
36
+
37
+### 方針3: できるかぎりテストを書く
24 38
- pandasの操作は自分で関数化し、それぞれunittestを追加する。
25 39
- 最初は全てにテストを付ける必要は無い。
26 40
- unittestを書いているとコーディング時間が2倍になってしまうかもしれない…
... ...
@@ -34,14 +48,9 @@
34 48
- それぞれの関数にテストを付けてあれば、バージョンアップで挙動が変わらないことを保証できる。
35 49
- pandasの場合は構文が結構deprecatedになることがあり、テストがあると安心してバージョンアップできる。
36 50
- その関数内の書き方だけを修正すればプログラム全体に適用できる。
37
-- 共通化できる処理は積極的に共通化する。
38
- - 共通したコードを使うことでメンテナンス性が向上する。
39
- - 片方は直したけど、こっちでは直し忘れていた…ということを防げる。
40
- - 例外的な対処が必要な場合は、明示的に条件分岐して処理する。
41
- - 「この実験の時は実験条件○○が特殊だったから、この値に反映しないといけない…」
42
- - 関数に実験名も入力として渡せば条件分岐できる。
43 51
44
-### 方針3: Enum, dataclassを積極的に使う
52
+
53
+### 方針4: Enum, dataclassを積極的に使う
45 54
- Enum
46 55
- 同レベルの値を識別するのにとても便利。
47 56
- 同モデルの計測機器A, B, C, ...