抽象度を下げる

最初から関数を作ろうとしない

繰り返し作業も、完全に理解できるまでは、手続き的に操作し、いちいち結果を確認する

割と普段のプログラミングと異なる考え方が要求されることが多い

型と構造で把握しきれない

同じcol名が存在するtableどうしをjoinすると、col_rightのようなkeyが生まれるとか、

具体的な結果を逐一見れば一瞬でわかるが、

頭の中でシミュレーションした時に抜けがち

jupyterで手続き的に見たほうが早い、ということが多い

最近やったこの辺のリファクタの体感が良かった

元のコードは2ヶ月ぐらい前に自分で書いたもの

元のものはかなり抽象的だった

そもそも扱っている問題が複雑で、その抽象でカバーすべきものも多かった

設定ファイル的なものを流し込んで内部でよしなにやるというもの

体感として難しくて、やや嫌気がさすものだった

一部のケースでバグが発生するが、その修正も乗り気になれない

設定ファイル的なものを扱う場合は、その設定の範囲の全ての組み合わせをカバーしないといけない

もう少し具体性を上げたものに書き換えた

イメージとしては、DSL的な道具を提供して、個別にロジックを書いてもらうようにする

(全然DSLではないが書く前のイメージ)

利用側がいくつかの分岐のあるロジックを明示的に書く

これはかなりコードの可読性が上がる

3重ぐらいに重なる条件が明示的に記述されるので意味がわかりやすく、メンタルモデルと一致しやすい

本題と関係ないが、インターフェースが良かったので、内部を書き換えるだけで済んだのも気持ちが良い

また、今回は両ケースで多少の妥協をしている

要件のすごい細かい部分をカバーしていない

その要件も必要だよねとなったときに、どこを修正すべきかが明確になる

今回の良さを他にも活かすなら、

その分かりづらさの原因が抽象度が高いことにあるのなら、下げてみるアプローチも考えみる、とかか