2022/01/31 12:13
ohbarye
blogged.
2022/01/31 13:47
mohritaroh
自分はやっぱりプログラミングにおいては「初心者」なんだなと実感した
2022/01/31 13:50
kako-jun
状態 > 結合までは自然とそうなるけど、4つの中で複雑性（complexity）だけ、定義が直感できないわ。例えば、この優先順を守るためにコード重複の可否がコロコロ変わると、ポリシーが1つにならず複雑なのでは
2022/01/31 14:17
yojik
単一責任原則にもあっている。ユースケースとアクタが状態を生む > "ユースケースごとに対応するモデルを追加し、元のモデルは抽象にする。変更するコード量はかなり多いが各モデルで気にする状態は少なくなる。"
2022/01/31 14:52
iekusup
ほー。
2022/01/31 17:43
surume000
10万行のコードが圧縮できることよりも、状態や結合の削減を優先するの？
2022/01/31 18:17
atsuououo
かなり強い主張だけど良いと思う
2022/01/31 19:02
kazokmr
あくまで優先的な話でコード量を減らすなとは言っていない。それに優先度を意識していけば必然的に複雑性やコード量も減っていくと思う。
2022/01/31 21:27
tinsep19
「ユースケースが複数ある＝アクターが複数いる」と考えればそもそも単一責任原則に反している。から行くとBFFは自然に思えるな。
2022/01/31 22:10
takc923
良い。状態・結合はめちゃくちゃ重要だけど無頓着な人多いんよなあ。
2022/02/01 02:11
for-my-internet-demo
皆が皆疎結合とそれにまつわるミドルウェアの天才かってゆーと、RDBとトランザクション頼りのがマシみたいなのもあって、ほんとはメンバーの能力感,価値観,ビジネスのステージとかいろいろある気がする
2022/02/01 03:28
UKIBORI
ここいつも何となく迷っている箇所なので言語化されていて助かった。“最終的には2を選び、「コード量と複雑性は高いけれども状態と結合は少なくてすむことを優先した」と説明できるようなプログラムになった。”
2022/02/01 07:19
onesplat
いい話
2022/02/01 07:20
ledsun
大意はわかる。けど “ジョブキューをインメモリで管理する場合、その状態を別のキュー管理コンポーネントに任せる（状態--; 結合++）ほうがうまく状態を管理でき” は状態＋＋結合−−に見える。なぜだろう？
2022/02/01 08:20
l__LINE__l
状態・結合・コード量の多さが複雑性を表しているとするとすっきりくる。複雑性だけ粒度が合わないように感じるが、理由があってそうしたんじゃないかなという気はする
2022/02/01 08:58
kazkaz03
“DRY原則を持ち出してコード量を減らすパッチを受け取ったときに「変更によって状態・結合・複雑性が増しているから受け入れない」と言うことができる。”/指標については既にある気がするな。後で探してみる。
2022/02/01 09:14
murashit
「考えてしまいすぎないための指針」って大事なんだよな
2022/02/01 09:27
otihateten3510
複雑なのは読めないからやめろ。それはお前にしか読めない。／コード量に注目するのはベテランでも同じだ。多くのベテランは初心者と大差ない。
2022/02/01 10:34
osiire
素晴らしい。けど複雑性だけちょっと誤解を生みやすい気がする。疎結合にできるなら(抽象化層を挟むので)具体性を犠牲にしてもいいといった方が分かりやすい気がする。
2022/02/01 10:37
j1nsuke
マジで感謝
2022/02/01 10:58
aox
極力人の手でやるようにすれば（電話やFaxを使って）コード量は減らせそうです ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ•̫͡•ʕ•̫͡•ʔ•̫͡•ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ•̫͡•ʕ
2022/02/01 12:53
yarumato
“状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減する。コードがよりステートレスになるなら、結合増加もいとわない。コードの重複排除をするのは状態・結合・複雑性を増さない時のみに限る”
2022/02/02 12:50
ogijun
この整理は素晴しい。言われてみると極めて妥当。プログラムコードだけじゃなくてDBの正規化などにも適用できそう。
2022/02/02 13:01
gennei
状態が多いとテストするのが難しくコードの把握も辛いので状態を減せると本当に助かる。
2022/02/04 17:05
juve534
優先順位はなるほどなと思った。アーキテクチャレベルで適用できること同意。
2022/02/04 22:18
t_f_m
"ステートレスなコードを最優先する理由は、それが最も推論可能なものだからだ" / "状態が入り込むとプログラムは...かなり難しくなる" / 並列・並行が難しいの、もう1つのプログラムの状態が常に入ってくるからか……