0
1
実現したいこと
バグ混入率の低いプログラムを作りたい。
前提
現在作っているソフトウェアのサイクロマティック複雑度が1250です。
発生している問題・エラーメッセージ
サイクロマティック複雑度75以上はいかなる変更も誤修正を生むと言われています。
また動いているソフトウェアはいじるべきではないとも言われています。
このソフトウェアはリファクタリングすべきですか？
回答6件
#1
総合スコア12151
投稿2024/07/12 08:42
（おことわり：素人です．）
その サイクロマティック複雑度 とかいうやつのことを全く知らないのですが，それは何らかの意味で正規化された値なのですか？ と疑問に思いました．
例えば，規模も内容も全く異なるプログラムAとBとの間で「Aは50 で Bは600 だから～」みたく比較するような話ができる性質の値なのでしょうか？
ちょっとググってみた感じだとそうでもない気がするのですが…？
（であれば，「その値が 1250 だ」という話だけを示したところで，それが何になるというのか？ というところがわかりません．）
それはそれとして，
動いているソフトウェアはいじるべきではないとも言われています
という話に従うのであれば，それは「リファクタリングなんてするな」ということなのではないでしょうか？
仮にこの言葉に従わないのだとしても，（リファクタリングに限らず）行為には目的があるでしょうから，その目的の重要性とリスクとを天秤にかけて判断するしかなく，それは背景事情を知らない他者に問うても意味が無いのでは…？ と思います．
#2
総合スコア760
投稿2024/07/12 09:45
動いているソフトウェアはいじるべきではない
この場合の「動いている」は基本的にはリリース済み・本番環境で稼働中などを意味します。
開発中の話であれば、ある程度フェーズが進んだ状態（例えば機能が一通り実装終わって結合テスト中とか）ならば、「発見したバグ修正以外はいじらない」というのも一定の説得力がある方針だと思います。
そうではなく、単にそれなりにコードを書いてデバッグ実行もできている＝動いている、という意味であれば
リファクタリングすべきでないかとかは何ともいえません。
今どのフェーズであとどれくらい実装が必要なのか、どのくらいの重要度・クリティカルな（バグが許されない）システムなのか、今後の改修やメンテがどのくらい起こり得るか、そしてどのくらいの工数が残っているかetc……次第です。
サイクロマティック複雑度が1250
正直に言ってちょっとどういう状態なのか想像できません。
数千行の神mainメソッドに、あらゆる分岐を含めた全ての機能と処理が詰まっているみたいな状態なんでしょうか？
普通、一定以上の規模のコードは、機能ごとにクラスやメソッド等を分割し個別にテストします（自動テスト/手動テストいずれにせよ）。
サイクロマティック複雑度はメソッド単位のメトリクスなので、分割するだけで自然に下がります。
じっさい適切にメソッドを分割するだけでテストしやすさは各段に上がり、リファクタリング品質改善バグ修正etcに繋がります。
ありがちな悪い例ですが
現状＝神メソッド → メソッド分割しない → テスト（特に自動テスト）を用意しづらい → テストがないのでリファクタリングできない → 段々開発効率が落ちていく → 開発後半のテストフェーズでたくさんバグがみつかるが修正難航 → リリース後もバグ修正とか機能改修の度に同様の地獄
みたいな悪循環スパイラルになる可能性が否定できないのではないかと。
#3
総合スコア10011
投稿2024/07/12 10:25
編集2024/07/12 10:39C#タグが付いているのでVisual Studioの「コード メトリックスの結果」ウィンドウの値ということでいいんでしょうか。
コード メトリック - サイクロマティック複雑度 - Visual Studio (Windows) | Microsoft Learn
階層のルート（プロジェクト）の値であれば、ある程度の規模なら普通じゃないですかね？（わたしの手元のコード行１万のプロジェクトは2000弱でした）
サイクロマティック複雑度75以上はいかなる変更も誤修正を生むと言われています。
これはひとつのメソッドでという暗黙の条件がありますよね（直接言及しているものを見つけられませんでしたが...
階層を開いてひとつのメソッドで1000以上だったら、正常ではないと思います（100以上でもでしょうが^^;
もちろんあえてそうしている（パフォーマンス上そうせざるを得ない等）なら、気にする必要はないでしょう。
#4
#5
総合スコア10011
投稿2024/07/12 13:57
注）わたしはアマチュアで主に自分用の小さなツール（↑に出したのは中でも最大のもの）をちまちま作っている人間です。
数千行の神mainメソッドに、あらゆる分岐を含めた全ての機能と処理が詰まっているみたいな状態なんでしょうか？
はい。
凄いですね。
きっとjmdajmwさんは頭がいいんでしょうね（嫌味とかでなく本心からの感想です）
わたしなんかは頭が悪いので、（自分の書いたコードでも）ちょっと複雑な処理だとすぐにわからなくなってしまうので、概ね下記を守っています（例外もあるがほとんどはそれより少ない）
- １メソッド１画面（30行程度）以内
- １ファイル（≒１クラス）300行以内
- （ロジックの）ネスト３段以内
だた世の中には頭のいい方もおられて、１ファイルが１万行・ネスト20段みたいなプログラムを苦もなく書いておられる方がいます。
実際にプログラミング配信とかで何人かは見たことがあります（ゲーム系に多い印象）
スイスイ書いているので、本人は何も困っておらずわかりやすいプログラムなのでしょう。
〇〇の処理は〇行目あたり等を覚えてるようで、わたしなんかからすれば「意味わかんねぇな」としか思えませんが、困っていないのであれば無理に変える必要もないんじゃないでしょうか。
もしも「多少問題点が出てきた」ということであれば、手遅れになる前に改善していく必要はあるでしょうね^^
#6
総合スコア2374
投稿2024/07/13 01:14
サイクロマティック複雑度1250は異常ですか？
サイクロマティック複雑度75以上はいかなる変更も誤修正を生むと言われています。
循環的複雑度の基準は、対象のソフトウェアやドメインによって、左右されるところがあるので、絶対的なことはいないのですが、個人的な感覚だと、特別な事情がない限り、1250という数値や危険な領域にあると思います。
参考までに、少し前のものになりますが、GitHubにて公開されているソースコードから循環的複雑度が高いものを抽出した記事があります。
この記事でピックアップされているのは循環的複雑度が1500を超えているものが大半ですが、ほとんどが自動生成や難読化が原因です。循環的複雑度1250のメソッドが通常のコーディングによって作成されたものなのだとしたら、問題意識は持ったほうがよさそうです。
また動いているソフトウェアはいじるべきではないとも言われています。
このソフトウェアはリファクタリングすべきですか？
リファクタリングというワードを世に広めたのはマーティン・ファウラーだと思いますが、その著書では「リファクタリングは息を吸うようにすべき」としていたと思います (うろ覚えです…)。つまり、リファクタリングを推進する立場にある人からいわせれば、「リファクタリングをすべきかすべきでないか」「動いているソフトウェアは触るべきか触るべきではないか」という問いはそもそも前提が違っていて、動いているソフトウェアを常日頃からリファクタリングができるようにしておかねばならないというわけです。
もっとも、現実のソフトウェア開発において、そんなに気軽にリファクタリングができるとは限りません。個人的な考えでは、リファクタリングによって得られる効果と、リファクタリングを実施するために必要な費用を見積もってみて、前者が後者を上回るようであれば、リファクタリング実施に踏み切ってみればよいのかなと思います。
例:
- 効果
- 内部品質が向上する
- テストや機能追加がしやすくなる
- 開発者がリファクタリングを通してソースコードの中身をより深く理解する
- 費用
- 単体テストの自動化やCI/CDなど、現行仕様を担保する環境の作成
- チームビルディングやチームの雰囲気づくり
- リファクタリング費用を出してくれる人を説得する (たいていはIT関係ではない人)
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。