コードクローンが良いか悪いか、CCFinderを語らないところに、この事件の面白さがある

みずほ証券の話がまだ、話題ってことの続き

この記事

［論点3］どんな開発手法を適用すべきか
http://itpro.nikkeibp.co.jp/article/COLUMN/20130325/465909/

（以下太字は、上記記事より引用）

最近のブログなどの論点は２つのようだ。

　　・詳細設計書の修正に関して
　　・コードクローンに関して

両方とも語ったわけだが、ともに、不自然なとことがあった。
それは、

・ドキュメントがないと保守できない
・コードクローンがあると、保守上、バグが入りやすい

という、反論しやすい意見を感情的に述べていて、
案の定、東証に反論されている。
（それも、ソフトウェア工学をやっている人なら、すぐに思いつく反論で）

ところが、みんなは、みずほ証券を支持していて、
東証の意見をつぶしにかかっているということだ。

---

■ソフトウェア工学には「原風景」がある。

実は、これは、”ソフトウェア工学には「原風景」がある”ということを
知っていると、理解できる。

・ドキュメントがないと保守できない

という言葉は、

・ドキュメントがない「オープンソース」のプログラムは、
　実運用では、使ってはならない

ということになるが、この言葉、古くからこの業界にいる人は、
聞いたことないだろうか・・・

１９９０年代、２０００年代でも、はじめのころは、こんな話が
出ていた。今の人には考えられないだろうが、オープンソースを
そういう理由で使わない時期があったのだ。

　たぶん、その時期を経験していない人たちは、

システムを保守する者はドキュメントを見ないというのだろうか。

という言葉から、そのニュアンスを感じないかもしれないが、
その時代を経過して、判りきったことを（自動化もせず）
二度と見ることもないドキュメントを散々書いてきた人間にとっては、
「あ、あのことだな」と感ずるところがある言葉だ・・・

　そのころは、たしかに

・コードクローンがあると、保守上、バグが入りやすい

　っていうことがあった。そのころは、自動生成よりも、コピペ
よりも、ソースをまとめる方向に行っていた気がする。

　オブジェクト指向の情報隠蔽なども、そんなかんじ。

---

■原風景＝１９９０年代後半から、２０００年代はじめのソフトウェア工学

　つまりだ、今回の話は、１９９０年代後半から、２０００年代はじめ
にかけての、１つの時代を作ったソフトウェア工学に立脚した考え方
を使っているということだ。

　その考え方は、
　　・ウォーターフォール
　　・構造化手法＋オブジェクト指向
　　・ＣＭＭＩ
　という考え方が中心だった。
　ドキュメントの整備などはまさに、ＣＭＭＩの考え方だ

　その後、ソフトウェア工学は、２０００年代後半から、これらの考えへの
反論が始まった。

　　ウォーターフォールから、アジャイルへ
　　構造化手法＋オブジェクト指向に対して、人間中心設計
　　ＣＭＭＩのようなアメリカ中心の大規模開発管理に対して
　　　ユーロ中心の中小規模管理のＶＳＥや、IS0/IEC29110

などなど、いままでの価値観が通用しない社会を持ち出してきた。

　これらの考え方が、教条主義、宗教戦争に今なっていて、
　大局から、「このケースではこっち、このケースではこっち」と
言えない状況になっている。

---

■みずほ証券　ＶＳ　東証

　たぶん、この行き着く先は、非常に大きなブレークスルーが起こって、
将来的ソフトウェア工学がいらなくなるような大事件（ロボットが
ソフトを作る）になるか、永遠と、宗教戦争を続け、学問として
成立しなくなるかだろうけど、そんなことは、このみずほ証券の話
とは、何の関係もないので今回は省略して・・・

　つまりだ。
　みずほ証券の立場は、この１９９０年～２０００年代はじめの
ソフトウェア工学の価値観に基づき、議論を吹っかけようとしている。
　　→みずほ証券側のソフトウェア工学の専門家の立場

　それに対して、東証は、それ以降の議論から持ってきて、
反論している（ここに一貫性はない）。
　　→東証側のソフトウェア工学の専門家の立場

　一般の人は、１９９０年～２０００年代はじめのソフトウェア工学の
価値観をもとに、発展させて考えている
（たとえば、プロセス改善といったとき、ＣＭＭＩとかは思いつくけど、
　ＶＳＥやSPEAK-IPAをあげる人は、このブログを見ている人と極わずかしないないだろうし
　開発工程というと、要求－設計－実装－テスト－運用・保守を思いつくけど、
　戦略・要件・構造・骨格・表層とか思いつく人は、たぶんデザイナー以外ではない）

　これが、一見するとみずほ証券が、みんなと同じ感覚で、まともなことを
言っているように見えるけど

　論理的に考えると、話がかみ合ってなく、東証のほうが、むしろ正しいことを
言っているように見える理由だ。
　　→と傍観しているのが、最近の実務＆ソフトウェア工学の担当者の立場

コードクローンが良いか悪いか、CCFinderを語らないところに、この事件の面白さがある

みずほ証券の話がまだ話題ってことの続き

この記事

［論点3］どんな開発手法を適用すべきか
http://itpro.nikkeibp.co.jp/article/COLUMN/20130325/465909/

（以下太字は、上記記事より引用）

最近のブログなどの論点は２つのようだ。

　　・詳細設計書の修正に関して
　　・コードクローンに関して

前に「詳細設計書の修正に関して」を論じた。
なので今度は、「コードクローンに関して」について論じる

---

■この事件の不自然さ

この事件の「コードクローンに関して」


ソースコードの品質についても、みずほ証券は問題を指摘している。今回のバグがあったプログラム全体について、「ソースコードの著しい重複が見られるなど、エラーの潜在する率が極めて高い作り方をされており、品質が極めて低い」と主張。これに対して東証は「コードクローン（記述の重複）を含むプログラムは、含まないプログラムと比較して信頼性が高いことが定量的な研究で裏付けられている」と反論した。


という風に書かれているが、これ、不自然に感じないだろうか？

つまり、みずほ証券側は、一般論を持ち出して、
「コードクローン（記述の重複）は問題である！」
といっているように見える。

だから、東証側にそうでない場合もあると反論されてしまっている。

---

■CCFinder

このような「コードクローン」の話をする場合、ソフトウェア工学の人たちだと、
かならず思い浮かぶツールがある。

それが、CCFinder

そしてCCFinderに関して、大阪大学の井上克郎先生が有名なようである。

で、そのホームページ

コードクローン(Code Clone)
http://sel.ist.osaka-u.ac.jp/research/clone/index.html.ja

をみると、（以下赤字は上記ホープページより引用）

一般的に，コードクローンはソフトウェアの保守を困難にする要因の一つである，といわれています．

ここが、みずほ証券の主張のところだが、ちょっとスクロールすると、

これまでの研究と配布先からのフィードバッグにより，全てのコードクローンがソフトウェアに悪影響を及ぼしているわけではないことがわかってきました．今後は，"良いクローン"と"悪いクローン"をどのように効率的に判断するか，ということが課題となっています．

---

■ちょっと考えてみればわかるけど、

Windowsの.netなんかで、ソースを自動生成するとき、同じ言葉が自動的に入って作られる
また、書き方の基準(コーディング規約）を決めてしまえば、同じ言葉になるところも多い。
ということは、生産性をあげるには、同じソースコードが何回も出る可能性が高く、
それを後から見れば、コードクローンになる。

１箇所にまとめるという手もあるが、その場合、新しいものが、既存のモノと微妙に
違ったり、将来違う可能性があるとき、１箇所にまとめないほうがよい（まとめられない）。


一方、保守になると、１箇所にまとまっているほうが修正しやすい。
何箇所もあると、修正の手間もかかるし、修正漏れの危険もある。

ということは、コードクローンは、新規開発と保守の間でトレードオフがあるということは
気づくはず。

井上先生の研究は、この「ちょっと考えた結果」を支持している。

---

■ということで・・・

CCFinderを知っている人なら、井上先生の研究に行き着き、
すぐにわかるはず。

ただ、一般の開発者は、これに気づきにくい

なぜかというと
・コピペは悪という価値観がある（やっているかどうかではなく、価値観）
・「コードクローンはソフトウェアの”保守”を困難にする」という話は先に出回った
・CCFinderを知っているのは、研究者の間であって、一般の開発者では知られていない
　　　→ましてや井上先生の名前は知らない。

そこで、これは、耳障りのいい言葉として、受け入れられた。

そこにみずほ証券が目をつけたことは判る。

---

ただ、ソフトウェア工学の専門家の人は、すぐに反論されると、
なぜ、思わなかったのか？

この辺の話の流れを知っていれば、「一般論」として話すのではなく、
もっと用心して、話をガードしながら話したはず

ということになるが、これは、また別の機会に書こう。

そもそもＵＭＬだと、「詳細設計書」は、書かなくないか？

みずほ証券の話がまだ、話題のようだ。

この記事

［論点3］どんな開発手法を適用すべきか
http://itpro.nikkeibp.co.jp/article/COLUMN/20130325/465909/

（以下太字は、上記記事より引用）

最近のブログなどの論点は２つのようだ。

　　・詳細設計書の修正に関して
　　・コードクローンに関して

ここでは、まず、この２つに関して論じて、
その後、本質的な問題にうつる。

はじめに、「詳細設計書の修正に関して」

---

　まずここで、東証側とみずほ証券側で、話がかみ合っていないことを
確認したい。もちろん、これはみずほ証券側の作戦であろう。

東証側が言っているのは、
・コーディングが済むと、ソースコードが詳細なドキュメントになる

といっている。これは、「詳細設計書」を除くと、その通りとなる。
たとえばＪａｖａであれば、
　　・クラスの説明のドキュメントは、ソースからJavadocで自動生成できる
　　・クラス図も自動生成できる
　　・シーケンス図も、クラスからの呼び出し関係にすぎず、
　　・strutsであれば、画面遷移は、struts-config.xmlから、自動生成できる

つまり、「ソフトウェア工学が進んだので、ソースコードさえあれば、
自動生成によりドキュメントは作れる。その意味で、ソースコードが詳細な
ドキュメントになる」という意味で言ったのであれば、これは、単純に
・・・そうだねというしかない話である。

---

　みずほ証券の議論は、これに対し、
　　「東証の品質は、ひどいもんだ」
　という風に話を持って生きたいようだ。どうも・・・

　そのために、論理的に話をすすめず、わざとだと思うが、語気によって
感情論に話をもって生かせ、一般の人を味方につけて、東証が悪いという
ように持っていかせようとしている。

たとえば、

システムを保守する者はドキュメントを見ないというのだろうか。


といっている、これは、一般の人に、
「そんなことはない、ドキュメントは見る。みずほ証券の言っていることは
　ただしく、東証は間違いだ、東証は、わるい」

という論調を導こうとしているように見える（でなければ、反語表現は使わないはず）。

しかし、東証は、ドキュメントを見るか見ないかは、議論していない。

ソースコード自体が、最も詳細なドキュメントである

といっているのであるから、ドキュメントは存在することになる。
また、他のドキュメントが存在しないとも言っていない。
現在のソフトウェア工学では、ソースがあれば、自動生成により、多様なドキュメントを作成できる。
このほうが、むしろ修正ミスを防げて、合理的だ。

---

なので、その後の

コードだけが頼りというのでは、ソフトウエア工学が長年にわたって培ってきた知見をすべて無視することになる

なことはなく、むしろ、ソースコードをたよりに、仕様書を作って、
可視化する方向にソフトウェア工学は移っている。

これは、前に反語表現を使って、みんなに東証が悪いという印象を
与えた後に、感情的なダメ押しをするための言葉であろう。

---

さて、議論から外した詳細設計書。
これなんだけど、そもそもＵＭＬだと、「詳細設計書」は、書けなくないか？


いい、いくよ！付いてきてね！！

ユースケースに対して、そのアクティビティを書いて、
要求を明示するよねえ
　　→ユースケース図、アクティビティ図

そのアクティビティに対し、入出力を明示し
（ここが入出力設計、ＵＩ）
その入出力を元に（正規化とか）、クラスをつくるよねえ
　　→クラス図（ＥＲ図に相当する）

その後、ＭＶＣアーキテクチャを採用したとすると、
なんかのフレームワークを決めて、

アクティビティ図の入出力に対する部分が
　　Ｖｉｅｗとなり、
クラス図（ＥＲ図に相当する）ところが
　　モデル（ＤＡＯ）になり
アクティビティは、Ｖｉｅｗを受ける部分にあたるので
　　コントローラーとなる。
　　→コントローラーが
　　　　　クラスとなるか(Struts,Actionクラス）
　　　　　メソッドとなるか(CakePHP,Zendなど）
　　　は、フレームワークやアーキテクチャによる
これで、アーキテクチャに基づいたクラス、メソッド割がきまる。

そして、クラスから、何を呼び出すかという、呼び出し関係と
メッセージ（引数）を、シーケンス図に描き、
状態遷移は、遷移図（ステートマシン図）に書ける

・・・が、たとえば、クラス内の初期値の値や、クラス内での
ループの細かいこと、Ｊａｖａの標準関数の呼び出し
までも、シーケンス図で書くかというと・・・かけないよね。
そこまで書くと巻物になってしまう。

　ということは、初期値はどうで、それを、Ｊａｖａの標準関数を
使ってどう処理するかの細かいことは、自然言語かフローチャートになる。

ところが、フローチャートはＵＭＬではない
また、自然言語で書くということは、「なぜＵＭＬは図にしているの？」
という問題と矛盾する。

付いてきた？だいじょうぶ・・・

つまりね、ＵＭＬに固執すると、
　ということは、初期値はどうで、それを、Ｊａｖａの標準関数を
使ってどう処理するかの細かいことを
書くところ＝詳細設計書は、ないのよ・・・

ということは、ＵＭＬを認めたならば、詳細設計のドキュメントが
ないからといって、ソフトウェア工学が終わったわけじゃないのよ。

---

ということで「詳細設計書の修正に関して」は、感情論に流れていて、
議論としては、？？？なことは、判っていただけましたでしょうか？

次は、「コードクローンに関して」も？？？なことを書いてみたいと思います。

パソコンでロケットが打ちあがるということよりも、驚くべきこと・・・

昨日のサイエンスＺＥＲＯ

次世代ロケット　世界に挑む！
http://www.nhk.or.jp/zero/contents/dsp421.html

北朝鮮のコントロールルーム

http://blog.livedoor.jp/dqnplus/archives/1706509.html

よりコンパクト、「パソコンでロケットが打ちあがる」、
とか、ポリ袋の素材で、ロケットを飛ばすとか、
驚きどころ満載だったんだけど、

そんなことより、もっと驚きだったのは、

人工知能を使ってロケットを打ち上げる。
その人工知能を使うところは、テスト！
っていうところ。

単純に人工知能を使うのではなく、
あることに（●●：漢字２文字）着目して、
テストを行う。
これにより、従来職人芸だったテスト（調整）工程が
簡単になる・・

やっぺ～、自分が今年後半やろうと考えていた研究と、
まるかぶりだ・・・（●●が被っている）

さっすがに、ロケットまでは、調査してなかったぜ・・・
もっとも、たぶん、同じ方式ではない
（自分はＡＩを使わないので）とおもうけど・・
逆に同じことをやってくれていると、その上に乗れるので、
ありがたかったりする・・・

やばい、早くなんかで、発表しておいたほうがいい・・・
でも、まだ、まとまってない。アイデア段階なので・・

ＪＡＸＡ，おそるべし。
サイエンスＺＥＲＯは、「モヤモヤさまぁ～ず2」の次に見逃せない・・・

Ｐ．Ｓ　きのうの「モヤモヤさまぁ～ず2」を見てたら、
大江アナが、モーニングサテライトに出るというので、
早く起きなきゃと思い、

今日起きて、テレビをつけたら、「おはスタ」やっていた orz