いつむーななやー

日頃考えていることを書き残します。

システム開発時の規模とか、コーディングについて

システムの規模を測る時やテスト時のケース数の妥当性を測る時などなど、ステップ数で測ることが多いと思います。

でも、今の時代?昔から?ステップ数って本当に参考になるのか?ってずっと疑問なんですよね。

まぁ、でも昔カタギのおじさん?にはとても重要な事らしく、結構頻繁にステップ数を聞かれます。

 

生産性とは?

例えば、ステップ数で成果が測られるのであれば、短時間たくさんのステップを書くことが生産性高い行為となります。

わざわざシステムエンジニアプログラマの方に言うまでもない事ですが、そんな事はありえないわけです。

 

コピペ

一番簡単に誰でも理解できる例はコピペです。

私がみた中でもベストに近い酷い例はこんな感じです。

  • 似た様な、と言うかほとんど同じ3つの帳票がある
  • これを1人のプログラマに依頼し、完成した
  • そのプログラマが居なくなった後に仕様変更が発生

コードを見てみると、丸っとコピペで作っていた。まぁ、ここまではよくある。

しかし、2つ目に作った帳票には、1つ目の帳票で定義し、2つ目の帳票では全く使わないメンバ変数とメソッド丸々残されていた。3つの帳票は、言うまでもないですね。

でも、この人は短期間でステップ数を増やすという意味では優秀なんですよね。参照されない変数、呼び出されないメソッドをコピペで一瞬にして作りだしました。そして、呼び出されない訳ですから、そのコードからバグが検出される事はない

 

しかし、修正する側からしたら悪夢そのものです。

何せ、一つの仕様変更で3箇所直す必要はあるし、影響調査の為にコードを調べていくと、呼び出されないメソッドやら、DBアクセスしてわざわざ値を設定してるのに、その後全く参照されないメンバ変数とか、山の様に出てくる訳です。当然、そう言ったことのないメソッドについても、何故そうしたのか?意味不明なコードが徒党を組んで迫ってきます。

 

まぁ、結局使えるパーツを残して全て書き直しました。結果、ステップ数は1/3以下になりました

 

品質とは?

で、品質についてなんですけど、

上の例の元のコード修正後のコードは、業務的に同じ価値を持ちます。機能が同じなので。

でも、テストケース数の妥当性を判断する指標がステップ数だとしたら、元のコードはステップ数が多い分、ケース数も多くなります。

つまり、もし同じ数だけバグをだしたら、修正後のコードの方が3倍品質が悪いということになってしまいます。何せ分母が1/3なので。

業務的に価値が同じ、つまりユーザに提供出来る価値は同じなのに、テストの工数が3倍かかる。でも、1つのバグの価値は1/3になる訳です。

 

短いコードを書く為に長いコードを書く

今やリファクタリングは一般的な事だと思います。短いコードがいきなり完成する訳でない。まずとりあえず、書いてみて、動かしてみて、そこがスタートラインなんですね。とりあえず、動くなんて状態は試作品

そこから、メソッドやらクラスやら、データの持ち方やらなんなやらかんやらを考えて書き換える。で、これでいける!とか思って書き進めていくと、途中で思った様にできないとか、そのままの方針でもできなくないけど、なんかぐちゃぐちゃして読みづらい、とか。で、また別の方法を考えて書き直す

 出来上がった短いコードの裏には、採用されずに消えていった無数のコード隠れている、普通は。

多分、コピペで適当に動きゃいいレベルのコード書いてる人よりずっと大量のコードを書いている。

 

でも、ステップ数で見る限り、生産性でもバグ発生率でも特にメリットがないどころかマイナスにしかならないんですよね。

 

コードメトリクス?

色々あげつらいましたが、現在私が何か困っているとか、不利益を被っているとかいう事ではないです。

が、アジャイルが流行って、その後、アジャイルは死んだとかいう人がでてきてて、開発に関する考え方ってすごい進歩してると思うんです。まぁ、私の現場までは届いていないですが。

で、色々進歩した結果、ステップ数に変わる認められた指標って何かあるのだろうか?という疑問がわいたのです。

 

私は相当時代遅れの職場にいる、3流システムエンジニアなのでよく知らないのですが、最近はコードメトリクスとかで、出来上がったコードの評価とか、ケース数のとかを出して、それベースで判断したりするんですかね?

これが一般的なんだったら、何周周回遅れなんだよ?!って自分を恥じるしかありませんね。

ただ、ちょっとググったくらいでは、実際こんな感じで管理につかってるよー、みたいな情報は日本語ではなかったですね。

 

私の中ではステップ数なんて、ずっと前から全く信頼していない指標なんです。ですので、少しでもプロジェクトをよく出来る可能性のある指標でプロジェクトを測りたいんですよね。

ただ、代案なしに、ステップ数なんか使えないですよ?とかいってもただの鬱陶しいヤツになってしまうので、コードメトリクスを少し勉強してみようかと思いました。

 

まとめ

  • 規模も生産性もバグ密度も何もステップ数では測れない
  • 無駄が少ないコードが出来上がるまでに、おびただしい数の屍コードが生まれている
  • コードメトリクスでプログラムの質を測れる?
  • これから真面目に検討してみる

 

最初の例に関してはコードレビューしろ、で終わりなんですけど、低予算のカツカツプロジェクトなので、最初の一本をレビューしたら後は放置なんです。

で、プロジェクト全体の品質指標とかそういったところまでを変更させる事はむずかいもしれない。だけど、コードメトリクス分析がある一定の基準を満たさないとコミットしちゃダメ、とかであまりに酷いものは機械的に排除する、とかいう使い方もあるのかなぁ、とぼんやり考えています。