bad smell

重複の長所と短所

コード重複は以前は良くないとされていたが、データ分析では良い事も多い。

全体的に、データ分析では試してみたい、という事が多くて、試した結果そのコードは不要になる事が多く有る。捨てられるコードはもっともコストをかけずに作られるべきである。

重複には悪い所もある。

コードの量が内容に比して大量に増えてしまう
- どこが必要なセルか探すのが大変
- 内容を理解するのも大変（後で読み直す時、同僚が読む時）
- ちょっと違う事を試す時に、全部dupしないといけなくなる（どんどん増える悪循環）
ちょっとだけ違うコードがたくさんになり、どれがなんだか分からなくなる
もともと同じコードからうまれた2つの実験のうち、片方の実験で必要になって書いた事を別の所に持っていくのが難しくなってしまう場合がある（乖離が大きくなると）
変更をいろいろな所に入れないといけなくなる事がある

重複は何度も使いまわすコードには向いてない。

-コードの大半は、一度しか実行されない

コードの寿命が短く、書くコードが多い
以前よりもずっと「そもそも試している事が間違っている」という事が多い
- コードの間違いより仕様の間違いの方が圧倒的に多い
どのコードが後でも使われるかが、事前には分からない（試した結果良さそうだと使われる。試す時には分からないから試す訳で）
プログラムの小片の結果を、プログラムだけでは無く人間も必要とする
実行時間が凄く長いコード片が日常的にある
- それを試す事自体が工数として非常に多くなってしまう
- コードを変更した時に、それを試すのが難しい（時間を食ってしまう）
- コード整理の結果を確認する為だけに実行するのが難しい
結果が正しいかどうかが良くわからない
- そもそも結果があってるか分からない
- 変更した時にその結果があっているかが分からない
- 確認出来る時も、その確認に凄いコストがかかる

整理の為だけに実行するのは難しい場合があるので、何か試したい事がある時に、その過程で整理する。

後者はちょっと説明も要ると思うので補足。通常リファクタリングでは結果を頻繁に確認しながら進めるが、データ分析では結果を確認する事自体が難しい。

そこで、試したい事を試す過程で、それが正しい事を確認する事をもって整理が間違ってない事を確認する事になりがち。

コードを変更すると、必ず間違う可能性が生まれる。そこでこの間違う期待値という考え方が大切になる。なるべくコード整理で間違う事を減らしつつ、それでもコード整理で間違う事は実験のコストの一部と考えるべき。

実験の方が大切なので、コストを払いすぎては行けない。なるべくコード整理にコストを払わず、でもカオスにはなってしまわないギリギリのバランスを見極める。

コード整理での間違いの発生率を減らす為には、リファクタリングの手順が参考になる。あまりバグを埋め込まないコードの変形のやり方のストックを増やし、なるべくそういう変形の比率を多くする。

データ分析では、従来のプログラミングとは違う構造が望ましい部分がある。一番重要なのは、フラットな構造の望ましさだと思う。

フラットな構造とは何か、という事を考えるには、そうでない極端な物を見ると分かりやすい。

GOD関数という物を考える。 GOD関数は、その関数を実行するとその内部で全部の必要な事をやって、帰ってくる、という関数。

GOD関数の特徴

データ分析に慣れてないプログラマが書きがち。