クソコードができあがるのは「影響の及ぼすコンポーネント量を最小にする」という個別最適の価値観が支配的になった時、です
— magnoliak🍧 (@magnolia_k_) 2022年3月12日
影響の及ぶ範囲を小さくするために、巨大で複雑なコードの塊を一箇所に追加し始めたりするのです
そうした方が関心の範囲が限定できるから...だけど、全体最適ではない
でも悪気はないんです
— magnoliak🍧 (@magnolia_k_) 2022年3月12日
真面目に巨大で見通しの悪いコードを作り上げていくけど、影響範囲が最小になる方が常に正しい、という価値観は「わかりやすい」んですよ
「変更量が最小になる」「影響が最小になる」...目の前のタスクをこなすためには、それが一番良いことに見えるんですよね
— magnoliak🍧 (@magnolia_k_) 2022年3月12日
でも、「継続的に同じペースが保てるか？」「スケールするか？」というと、そんなことは無いけど、それが今のスコープの範囲ですか？って問われるとね
最小の変更量でやりたいことが実現できれば、それに越したことはないけど、それを積み重ねて行った時に、常にその選択をとり続けることが正解か？というとそんなことは無いし、みんな気づいているはずなんだけど、「最小の変更だけを良しとするんでしょ？どうせ...」みたいな価値観が支配的になってしまった時...
つまり、スキルの高低の、その前に、それを取り巻く価値観の方が強く支配的になっていくんじゃないか、と思った。
追記:
コードの所有権の問題もあるんですよね。「変更量が少ない方がレビューが通りやすい」とか / “見通しの悪いコードができあがってしまう、その理由 - Magnolia Tech” https://t.co/3G3oLukPzV
— ぎゃばん@手洗い (@ledsun) 2022年3月17日
こっちを貼るのを忘れてました https://t.co/EFAY3PEkHq
— magnoliak🍧 (@magnolia_k_) 2022年3月17日
所謂クソコードとか技術的負債の原因は「裁量が無い」と「興味が無い」に収斂していく
— magnoliak🍧 (@magnolia_k_) 2022年3月14日
