マトリョーシカ人形のようなメソッド設計を避ける - give IT a try

フィヨルドブートキャンプのコードレビューでよく指摘してるシリーズです。 次のようなパンを焼くRubyプログラムがあります。 このプログラムはどういう工程を経てパンが焼かれるのか、ぱっと把握できますか？ def main パンを焼く(粉, 水) end def パンを焼く(粉, 水) 焼く(パンを発酵させる(粉, 水)) end def パンを発酵させる(粉, 水) 発酵させる(パンを整形する(粉, 水)) end def パンを整形する(粉, 水) 整形する(パンをこねる(粉, 水)) end def パンをこねる(粉, 水) こねる(粉, 水) end main 上のプログラムは次のように書いても同じように処理されますが、工程の全体像がつかみやすいのはどちらでしょうか？ def main 生地 = パンをこねる(粉, 水) 整形された生地 = パンを整形する(生地) 発酵した生地 = パ

[fukken]

「脳内フローチャートと一致するメソッド」がどこかに存在しなければならない、という話じゃないかな。下手にあちこちに散ると見通しが悪い。

[rryu]

「焼く(発酵させる(成形する(こねる(粉,水)))」ならまだましなので、2工程ずつの謎の分割が悪さの元だと思う。

[door-s-dev]

前者の方が分かりやすく感じる人もいるかもしれないのが難しいところ...

[trashtoy]

これはケースバイケース. 料理のレシピみたいに処理の「順番」を意識したほうが良い場合はこの例みたいな書き方がいいけど, 処理の「粒度」を意識する場合は入れ子構造のほうが可読性が高くなる場合も.

[turanukimaru]

パンだけではなくベーグル（発酵しない）も焼くことにします。って考えると入れ子が不味いことが解るはず。if (パン){a(b(c(d())))}、if(ベーグル){a(c(d()))}って一部違うコピペが乱舞することになる。そんなコード引き継いだ

[inatax]

こういうケースにこそパイプライン演算子が…と書きに来たけど、ちゃんと言及があったのでにっこり

[manhole]

説明例として分かりやすい。モジュール化と全体感のわかりやすさを目指したい

[nakag0711]

依存するものが少ない方がいいという話

[hatest]

パンではなくてスパゲティのほうがジョークとしては面白かったかも。

[parasporospa]

コールグラフが浅いほうが理解しやすい、と言い換えられるだろうか

[aya_momo]

メソッドチェインって、なんか落ち着かないのよね。

[homarara]

この記事が響く人は、さんざっぱらやらかした後である、というのは致し方ない。

[longyang]

Elixirのパイプライン演算子面白いな

[for-my-internet-demo]

気分のまま上から書いてって切り出したであろうプログラムで見た。動いててもそれは下書きという

[trendy]

考え過ぎの メッセージ 誰に届くかも 知らないで

[xlc]

マトリョーシカ人形から連想されるのは再帰で、再帰ならばこういう使い方がまさに正しくなる。コールバック地獄もこんなパターンだね。

[onesplat]

こんなことやるやついねーよ

[shinagaki]

わかりやすく日本語にしたんだと思うけど、メソッド名が"を"で繋いであると違和感ある

[yood]

コンテキストの問題は答えがない。どちらかに固執しすぎない/AIが担う範囲が広がった時、コンピューター側には関係のないこの問題はどうなっていくのか

[Eiichiro]

オブジェクト分けて、こう書きたくなるなぁ。「パンの元.new(粉, 水).こねる().発酵させる().整形する().焼く()」順番間違えたら、エラーメッセージ入れれば良いし。

[udukishin]

ダメな例は関数型っぽく見えるけどこういうのって言語の特性次第の話になるのかな？

[yarumato]

“a(b(c(d(z))))は実行すべき順序とメソッド呼び出しの順序が逆順になり、処理の流れを直感的に把握できない。メソッド再利用できない。r1=a(z);r2=b(r1);r3=c(r2);r4=d(r3);は起点となるメソッドを見るだけで処理の全体像を把握。”

[iga_k]

わかりやすい！

[bluerabbit]

わかるー