Noteの過去記事の転載
—-
ソフトウェアの複雑性、歴史の積み重ねによる変更と、例外ルールの多さがけっこうな影響力を持っている
— magnoliak🍧 (@magnolia_k_) 2021年1月26日
あと、例外ルールって、実際のドメインエキスパートからすれば「あーそういえば有るよねー」くらいだったりするけど、コードに落としてみると、8割とかがそうゆうパターンへの対応だったりするんだ
コードの8割とかは例外への対応だったりする一方で、ビジネス側の人はせいぜい2割くらいしかない、実現したい業務の主たる内容に関心の重きを置いている。それは必ずしもコードの量や割合の多さと比例するとは限らない。
一方でコード自体に、王道ルートも例外ルートの色分けは無く(ユースケース図で言うところの基本ルートと、代替ルートは有るけど)、等しくロジックとして実装しなければいけない。テストの密度を変える、みたいな話はあるかもしれないけど、王道ルートだろうが例外ルートだろうが、必要なロジックに合わせてコードを書くしかない。
このビジネスの関心と、コードの関心の非対称性が、時に「なんでたったこれだけのことをやるのにそんなに工数がかかるの？」みたいな不信感につながっていくのではないか。
また、当たり前だけど、ビジネス要求に基づく例外ルート以外にも、「メモリが不足していたら？」「外部サービスへのリクエストが返ってこなかったら？」「インフラに異常が発生したら？」などなど、さまざまなシステム上の要求に従って実装しなければいけないコードが有る。
また、業界の法規制(内部統制とか)からの要求によってはさらに、ビジネス側の主要な関心事項から外れるけど、実装しなければいけないことも発生してくる(ログが参照できるようになっているとか、さらにそれが改ざんできないようになっているとか)。
この非対称性を認識しないと、いつまで経ってもスピード感や、コスト感に対する合意が得られないのではないか？
この王道ルートと、例外(代替)ルートのビジネス上のインパクト大きさの割合が、コードに占める割合と合わないのって、けっこうビジネス側とエンジニアサイドで会話が合わないポイントだよなって
— magnoliak🍧 (@magnolia_k_) 2021年1月26日
「そんな細かいことはいいんだよ」って言われるっていうさ
でも網羅しないといけないんだよっていう
追記：あと、追加する機能自体はすごくシンプルで、小さいけど、既存のコードへの影響が大きい(コード値が追加になる、何かのチェックを緩くするなど）ものは影響調査に物凄い時間がかかるし、整合性を取るために凄い量の改修が発生したりするんだけど、機能を依頼する側から見れば実際に変わって見える箇所は凄く小さいから「なんでそんなに時間がかかるの？こんだけの機能だよ？」となりがち。関心の非対称性は、解消していかないといけない。
