Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Select an option

  • Save karino2/c222a7074f773a1f4dbdc0521f26861d to your computer and use it in GitHub Desktop.

Select an option

Save karino2/c222a7074f773a1f4dbdc0521f26861d to your computer and use it in GitHub Desktop.
アイデアのメモ。
Display the source blob
Display the rendered blob
Raw
{"cells":[{"cell_type":"markdown","metadata":{},"source":["#トピック\n\n- フラットなメリット\n- dupとくくりだしのpros-cons\n- 関数の引数の数\n- オブジェクトのpros-cons\n- 整理はコードを追加する時に行う\n"]},{"cell_type":"markdown","metadata":{},"source":["# bad smell\n\n- 簡単な事なのにすぐに結果が確認出来ない\n- 途中の結果が簡単に確認出来ない\n- 引数が多すぎてしかもほとんどが要らない引数\n- セルの評価順序への深い依存\n - 少し変えたい時に全部dupされてしまう\n- あるコードを直したい時に同じセルがたくさんあり、直したセルと直してないセルがごっちゃになってる"]},{"cell_type":"markdown","metadata":{},"source":["# 重複の長所と短所\n\nコード重複は以前は良くないとされていたが、データ分析では良い事も多い。\n"]},{"cell_type":"markdown","metadata":{},"source":["## 重複の長所\n\n- 過去の結果に影響を与えない\n- 以前の結果を受けてそれをちょっと変えた事を試したい時に、一番簡単に試せる\n- フラットさが変わらない\n- 前うまく行った事は、コピペ後もうまく行く(バグを埋め込まない)\n\n全体的に、データ分析では試してみたい、という事が多くて、試した結果そのコードは不要になる事が多く有る。\n捨てられるコードはもっともコストをかけずに作られるべきである。"]},{"cell_type":"markdown","metadata":{},"source":["## 重複の短所\n\n重複には悪い所もある。\n\n- コードの量が内容に比して大量に増えてしまう\n - どこが必要なセルか探すのが大変\n - 内容を理解するのも大変(後で読み直す時、同僚が読む時) \n - ちょっと違う事を試す時に、全部dupしないといけなくなる(どんどん増える悪循環)\n- ちょっとだけ違うコードがたくさんになり、どれがなんだか分からなくなる\n- もともと同じコードからうまれた2つの実験のうち、片方の実験で必要になって書いた事を別の所に持っていくのが難しくなってしまう場合がある(乖離が大きくなると)\n- 変更をいろいろな所に入れないといけなくなる事がある\n\n重複は何度も使いまわすコードには向いてない。"]},{"cell_type":"markdown","metadata":{},"source":["# データ分析特有の部分\n\n-コードの大半は、一度しか実行されない\n - コードの寿命が短く、書くコードが多い\n- 以前よりもずっと「そもそも試している事が間違っている」という事が多い\n - コードの間違いより仕様の間違いの方が圧倒的に多い\n- どのコードが後でも使われるかが、事前には分からない(試した結果良さそうだと使われる。試す時には分からないから試す訳で)\n- プログラムの小片の結果を、プログラムだけでは無く人間も必要とする\n- 実行時間が凄く長いコード片が日常的にある\n - それを試す事自体が工数として非常に多くなってしまう\n - コードを変更した時に、それを試すのが難しい(時間を食ってしまう)\n - コード整理の結果を確認する為だけに実行するのが難しい\n- 結果が正しいかどうかが良くわからない\n - そもそも結果があってるか分からない\n - 変更した時にその結果があっているかが分からない\n - 確認出来る時も、その確認に凄いコストがかかる\n"]},{"cell_type":"markdown","metadata":{},"source":["# コードの整理の仕方\n\n整理の為だけに実行するのは難しい場合があるので、何か試したい事がある時に、その過程で整理する。\n\n- 一度の整理では少しの部分だけ整理する(全部やろうとしない)\n- あまりそこで問題を発生させないように気をつける\n"]},{"cell_type":"markdown","metadata":{},"source":["後者はちょっと説明も要ると思うので補足。\n通常リファクタリングでは結果を頻繁に確認しながら進めるが、データ分析では結果を確認する事自体が難しい。\n\nそこで、試したい事を試す過程で、それが正しい事を確認する事をもって整理が間違ってない事を確認する事になりがち。\n\nコードを変更すると、必ず間違う可能性が生まれる。そこでこの間違う期待値という考え方が大切になる。\nなるべくコード整理で間違う事を減らしつつ、それでもコード整理で間違う事は実験のコストの一部と考えるべき。\n\n実験の方が大切なので、コストを払いすぎては行けない。\nなるべくコード整理にコストを払わず、でもカオスにはなってしまわないギリギリのバランスを見極める。"]},{"cell_type":"markdown","metadata":{},"source":["コード整理での間違いの発生率を減らす為には、リファクタリングの手順が参考になる。\nあまりバグを埋め込まないコードの変形のやり方のストックを増やし、なるべくそういう変形の比率を多くする。"]}],"metadata":{"kernelspec":{"display_name":"Python 2","language":"python","name":"python2"},"lanbuage_info":{"codemirror_mode":{"name":"ipython","version":2},"file_extension":".py","mimetype":"text/x-python","name":"python","nbconvert_exporter":"python","pygments_lexer":"ipython2","version":"2.7.11"}},"nbformat":4,"nbformat_minor":0}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment