21/04/21 21:43:59.16 U7I+mJcY.net
>>532-533
誰もそんな話はしてない
的外れだから話に参加してくるな
535:デフォルトの名無しさん
21/04/21 22:15:34.01 hZhPN+RC.net
最近SEからPLっぽい事やり始めたんですが、ステップ数の考え方で迷ってます。
例えば
コミット1、ファイルA：ソース1ステップ
コミット2、ファイルA：+50ステップ
コミット3、ファイルA：-49ステップ
のような場合、コミット毎に前回バージョンと比較してステップ数を累積するのと、
コミット1と3で比較するのとではステップ数が異なりますよね？
どちらで比較するのがスタンダードなのでしょうか？
536:デフォルトの名無しさん
21/04/21 22:29:22.41 U7I+mJcY.net
>>535
論理ステップ数で比較するのが一般的です。
URLﾘﾝｸ(e-words.jp)
ソースコード中の改行文字を単純に数え上げたものを物理LOC（Lines Of Code：コード行数）というが、
多くの言語ではコード中にコメントや空行など何も行わない行や、
コードブロックの開始や終了（中括弧{}やbegin/endなど）など実質的な処理を行わない行を記述できるため、
一定の基準を定めてこうした行を数え上げから除外する。こうして数えた行数がステップ数で、論理LOCとも呼ばれる。
537:デフォルトの名無しさん
21/04/21 22:34:08.39 hZhPN+RC.net
>>536
すみません、論理ステップ前提です。
上の+50、-49は全て論理ステップと思って下さい。ちなみにcloc使ってます
前バージョン比較で累積すると新規50ステップ
1-3間で比較すると新規1ステップ
どちらでカウントするのが一般的かというのが知りたいのです
538:デフォルトの名無しさん
21/04/21 22:36:02.33 NCTKtzNH.net
>>534
仮想環境の勉強とか言ってるレベルの人に、CUIしかない(と思う)環境を勧めていいのか？と言ってる
コマンド叩いてサクサク操作ができる人なら、そんなこと聞かないだろと思うから
いや、俺の認識が古くて今では GUI が使えるようになったのなら問題はないんだが
539:デフォルトの名無しさん
21/04/21 22:37:54.75 U7I+mJcY.net
>>537
目的によります。
同じことを実現するのに
・ステップ数が多い（無駄が多い）方を評価したいなら、ステップ数が多い方を選びます。
・ステップ数が少ない（無駄が少ない）方を評価したいなら、ステップ数が少ない方を選びます。
ただし相手が評価されるのが嫌な場合は逆を選びます。
540:デフォルトの名無しさん
21/04/21 22:41:26.40 U7I+mJcY.net
ちなみに、クソコードを50行消して
改善したコードを50行追加した場合、
その人は100行の素晴らしいコードを書いたことになります
クソコードを消すのはプラス評価です。
541:デフォルトの名無しさん
21/04/21 22:42:31.42 hZhPN+RC.net
>>539
なるほど。
因みに目的はバグ密度やテスト密度、生産性などのメトリクス分析なんですが、
この場合あなたはどちらの比較が適してると思われますか？
542:デフォルトの名無しさん
21/04/21 22:45:13.36 U7I+mJcY.net
>>541
ステップ数は全く意味がない値なので何にも適しません。
543:デフォルトの名無しさん
21/04/21 22:46:40.01 hZhPN+RC.net
>>542
それは流石に嘘・・・
544:デフォルトの名無しさん
21/04/21 22:47:20.46 U7I+mJcY.net
クソコードを削除すると生産性は上がります。
この事実に結びつかないメトリクスは
意味がありません。
545:デフォルトの名無しさん
21/04/21 22:49:51.23 hZhPN+RC.net
>>544
普通に組んでたから気持ちはわかるが暴論よ・・・
レビューの結果糞コードに変身する場合もあるんですよ><
546:デフォルトの名無しさん
21/04/21 22:53:43.72 NCTKtzNH.net
近頃は面倒なんでカバレッジ率ぐらいしか見てないな
ステップ数は顧客に報告する時だけ…
547:デフォルトの名無しさん
21/04/21 22:55:34.22 U7I+mJcY.net
ステップ数はただの「量」です。
家の中にモノがたくさんある。これはいいことでしょうか悪いことでしょうか？
モノはゴミかもしれません。多いことが良いことかどうかなんてわかりません。
メトリクスは量を除いて計測します。
そして良いものがこれくらいある。
ゴミがこれくらいある。という言い方しかできません
メトリクス分析するなら、量の概念は除いて計測します。
548:デフォルトの名無しさん
21/04/21 22:58:53.03 wGFkmeDC.net
量じゃないメトリクスってなんだ？
549:デフォルトの名無しさん
21/04/21 22:59:45.21 YcNEV+yo.net
>>535
もちろんコミット1と3の差分でカウントするよ
一度書いたけど採用しなかったコードなんて計測する意味はない
最終的に採用したコードのステップ数に応じてテストの件数を計画・評価するんだから当然じゃん？
遠回りしようが近道しようが、同じだけの改変には同じだけのテストが要る
550:デフォルトの名無しさん
21/04/21 23:07:36.61 hZhPN+RC.net
>>549
ありがとう。
確かに無駄コード分、必要テスト数が増えてしまうもんね。
その方向でまとめてみる。thx！
551:デフォルトの名無しさん
21/04/21 23:53:32.96 n9Psf8QY.net
フローで評価したいならコミット1から現在のコミット3の間に発生した+50と-49の変化を分母にする
ストックで評価したいなら評価時に残ってる2ステップを分母にする
新規50ステップや新規1ステップはどっちつかずで微妙だし
必要テスト数を出すためにステップ数やテスト密度使うのも微妙だなぁって感じる
552:518
21/04/21 23:54:32.93 SVTBKWZf.net
>>519
出来ました！
ありがとうございました
553:デフォルトの名無しさん
21/04/22 04:38:17.22 gbeL+P6Z.net
ステップ数とテストの数に相関関係はないぞ
リファクタリングしてコードを減らしても
動作は変わらないんだからテストの数は変わらない
554:デフォルトの名無しさん
21/04/22 04:40:05.35 gbeL+P6Z.net
長いコードを関数に分けると関数呼び出しのためにステップ数は増えるが
長いコードに含まれるフローパターンの組み合わせが
関数にすることで減らすことが出来るのでテスト数は減る