CRUD型と呼ばれるアプリケーションでも複雑性は色々な形で内包されていて、そのうち最も厄介なのは時間軸に対して一貫性を欠いた改修の歴史と、業務要件の発露と不一致なアプリケーション構造なのです
— magnoliak🍧 (@magnolia_k_) 2021年10月2日
コード間の関連が、最初に意図した通りにそのまま成長していく分には複雑性は上がっていかないけど、それで済む、ということは逆に言えばコードのビジネス上の価値がシフトしていない、ということではないか
— magnoliak🍧 (@magnolia_k_) 2021年10月3日
あるコンポーネントに対するビジネス上の価値が下がることより、上がっていくことの方が多いけど、だからといって別のコンポーネントの絶対価値は下がる訳ではないので、捨てられるとは限らず、そうすると複雑度は上がっていく一方なんだよね https://t.co/U2uSMSI9O6
— magnoliak🍧 (@magnolia_k_) 2021年10月3日
ビジネスにおける関心の関係性と、コードの関係性のズレを補正することがリファクタリングと言えると思うのです
— magnoliak🍧 (@magnolia_k_) 2021年10月3日
コンポーネントだけでなく、システムですらビジネス上の価値がどんどん変化していくので、コンポーネントやエンティティレベルでの価値の変化は日常茶飯事で、だって情報系作って分析しましょうって話になった時に、まさかこんなにアクセスログが重要な情報になるとは思ってはなかったでしょ？
— magnoliak🍧 (@magnolia_k_) 2021年10月3日
ある情報が全然重要性が薄いと思われて雑に管理されていたのに、ある日突然「超重要」に変わることなんてほんとよく有って、その時にそれまでの管理特性とのfit&gapを真面目にやらないと、詰む
— magnoliak🍧 (@magnolia_k_) 2021年10月3日
気がつくと重要度が上がっていました、というのはヤバいわけです
で、重要度が上がると、どんどん使い方が広がっていって、今まで使っていない組織や、用途への広がりが出て、さらに「なんでこんな精度なの？」「なんで、揃ってないの？」「いついつ以前分はなぜ無いの？」みたいな話になっていくのです
— magnoliak🍧 (@magnolia_k_) 2021年10月3日
データサイエンティストがまずはデータの質を揃える地道な作業から始まるのは、そもそも重要度に対する認識のミスマッチから始まっているんです
— magnoliak🍧 (@magnolia_k_) 2021年10月3日
当たり前だけど、言語やライブラリ、フレームワーク、ミドルウェアはビジネス要求に対しては抽象度が全然高いので、具象化する過程は「色々なやり方がある」状態になっていて、その道筋を間違えると（手段に振り回されると）アレ https://t.co/Wpwqa3niKv
— magnoliak🍧 (@magnolia_k_) 2021年10月3日
