状態、結合、複雑性、コード量の順に最適化する - valid,invalid

There’s No Such Thing as Clean CodeのHacker Newsコメント経由でコードやシステム設計・最適化についての良いコメントを見つけた。どうやらHacker Newsで何度も引用されているらしいが日本語で言及された記事が見つからなかったので取り上げてみる。 コメントは2016年のSandi MetzのThe Wrong Abstractionに関するもので、発言者のcurun1rいわく「私は設計の優先順位をこの順序で学習することで、優れた開発者になれた」。*1 4つの基準と優先順位のガイドライン 状態 > 結合 > 複雑性 > コード量 私は状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減することでコードを最適化する。 コードがよりステートレスになるなら、結合を増やすこともいとわない 結

[ohbarye]

blogged.

[yojik]

単一責任原則にもあっている。ユースケースとアクタが状態を生む > "ユースケースごとに対応するモデルを追加し、元のモデルは抽象にする。変更するコード量はかなり多いが各モデルで気にする状態は少なくなる。"

[for-my-internet-demo]

皆が皆疎結合とそれにまつわるミドルウェアの天才かってゆーと、RDBとトランザクション頼りのがマシみたいなのもあって、ほんとはメンバーの能力感,価値観,ビジネスのステージとかいろいろある気がする

[UKIBORI]

ここいつも何となく迷っている箇所なので言語化されていて助かった。“最終的には2を選び、「コード量と複雑性は高いけれども状態と結合は少なくてすむことを優先した」と説明できるようなプログラムになった。”

[kako-jun]

状態 > 結合までは自然とそうなるけど、4つの中で複雑性（complexity）だけ、定義が直感できないわ。例えば、この優先順を守るためにコード重複の可否がコロコロ変わると、ポリシーが1つにならず複雑なのでは

[osiire]

素晴らしい。けど複雑性だけちょっと誤解を生みやすい気がする。疎結合にできるなら(抽象化層を挟むので)具体性を犠牲にしてもいいといった方が分かりやすい気がする。

[ginpei]

例えばステートレス実現のために結合を許容する、複雑性軽減のためコード複製を厭わない、というような順序付け。この優先度は感覚にも合ってる。「良い設計」言語化の中で一番好きかも。

[auient]

「状態 > 結合 > 複雑性 > コード量」状態を減らすためには結合を増やすのも厭わない、という判断になる

[nakag0711]

インスタンス変数を排除してもバラバラのローカル変数に置き換わるだけの気が…

[sbrtnpg]

すごい言語化

[hamamuratakuo]

4つの基準と優先順位のガイドライン　状態 > 結合 > 複雑性 > コード量　状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減することでコードを最適化する。

[lulichn]

状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減することでコードを最適化する。”[設計][プログラミング]

[t_f_m]

"ステートレスなコードを最優先する理由は、それが最も推論可能なものだからだ" / "状態が入り込むとプログラムは...かなり難しくなる" / 並列・並行が難しいの、もう1つのプログラムの状態が常に入ってくるからか……

[juve534]

優先順位はなるほどなと思った。アーキテクチャレベルで適用できること同意。

[gennei]

状態が多いとテストするのが難しくコードの把握も辛いので状態を減せると本当に助かる。

[ogijun]

この整理は素晴しい。言われてみると極めて妥当。プログラムコードだけじゃなくてDBの正規化などにも適用できそう。

[yarumato]

“状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減する。コードがよりステートレスになるなら、結合増加もいとわない。コードの重複排除をするのは状態・結合・複雑性を増さない時のみに限る”

[aox]

極力人の手でやるようにすれば（電話やFaxを使って）コード量は減らせそうです ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ•̫͡•ʕ•̫͡•ʔ•̫͡•ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ•̫͡•ʕ

[j1nsuke]

マジで感謝

[otihateten3510]

複雑なのは読めないからやめろ。それはお前にしか読めない。／コード量に注目するのはベテランでも同じだ。多くのベテランは初心者と大差ない。

[murashit]

「考えてしまいすぎないための指針」って大事なんだよな

[kazkaz03]

“DRY原則を持ち出してコード量を減らすパッチを受け取ったときに「変更によって状態・結合・複雑性が増しているから受け入れない」と言うことができる。”/指標については既にある気がするな。後で探してみる。

[l__LINE__l]

状態・結合・コード量の多さが複雑性を表しているとするとすっきりくる。複雑性だけ粒度が合わないように感じるが、理由があってそうしたんじゃないかなという気はする

[ledsun]

大意はわかる。けど “ジョブキューをインメモリで管理する場合、その状態を別のキュー管理コンポーネントに任せる（状態--; 結合++）ほうがうまく状態を管理でき” は状態＋＋結合−−に見える。なぜだろう？

[onesplat]

いい話

[takc923]

良い。状態・結合はめちゃくちゃ重要だけど無頓着な人多いんよなあ。

[tinsep19]

「ユースケースが複数ある＝アクターが複数いる」と考えればそもそも単一責任原則に反している。から行くとBFFは自然に思えるな。

[kazokmr]

あくまで優先的な話でコード量を減らすなとは言っていない。それに優先度を意識していけば必然的に複雑性やコード量も減っていくと思う。

[iga_k]

DRY よりも 結合 や 一意 を優先

[surume000]

10万行のコードが圧縮できることよりも、状態や結合の削減を優先するの？

[iekusup]

ほー。