アカウント名:
パスワード:
タイトルどおりなんだけど、3段落目の
リファクタリングされたコードの方が解析性が劣り
と
リファクタリングすることの利点として保守性指数が僅かに高かった
が、矛盾してない?俺の思っている保守性とは、また違うものなのかしらん?
矛盾しないように解釈するなら、コードを理解するコストと、問題発生時に修正するコストの違いじゃねぇの。
この論文では解析性(人間がコードを評価した結果)保守性指数(ツールがコードを評価した結果)なのでツールは人間の感覚を再現するものではない、ということかと。
「解析性」は「可読性」と読み替えるとして、「バグが出て修正に時間がかかっている」らしい記述からすると、リファクタリングに失敗して保守性は低下しているようですから、「保守性指数」の算定アルゴリズムが現実の「保守性」を表していないということでしょうか…
例えばだけど、
unsigned char pink[3];rgb[0] = 0xFF;rgb[0] = 0xCC;rgb[0] = 0xCC;
を
struct Color { unsigned char red; unsigned char green; unsigned char blue;}; Color pink;pink.red = 0xFF;pink.green = 0xCC;pink.blue = 0xCC;
みたいなリファクタリングだと、保守性が上がって解析性が下がってる、ってことでしょ。プログラマはpink[0]が赤成分なのか青成分なのかわからないけど、pink.redはそれを間違う心配がない。一方で、「unsigned char pink[3];」を見れば、pinkが0〜255の値を持つ配列だっ
バグが出て修正に時間がかかったのに保守性は改善したとか、いろいろ矛盾していますね。
可能性・統計情報を適切に読み解けてない・記事(あるいは翻訳)が傾向と事例を区別できていない・まともにできる人がいなくて、「失敗することが多かった」と言っているだけ :
元の論文を読めばわかることだけど、適用したリファクタリングは以下のようなもの。特にR3~R6を無分別に適用したせいで、コーディングのミスや漏れを防げるようになった代わりに、処理の具体的内容が読みづらくなったということだと思う。
Selected Refactoring Techniques are:R1- Introduce Local ExtensionR2- Duplicate Observed DataR3- Replace Type Code with SubclassesR4- Replace Type Code with State/StrategyR5- Replace Conditional with PolymorphismR6- Introduce Null ObjectR7- Extract
Selected Refactoring Techniques are:
R1- Introduce Local ExtensionR2- Duplicate Observed DataR3- Replace Type Code with SubclassesR4- Replace Type Code with State/StrategyR5- Replace Conditional with PolymorphismR6- Introduce Null ObjectR7- Extract
あなたの分別はある人からしたら無分別かも知れないし、ある人の分別はあなたにとっては無分別かも知れない。したがって、彼らがリファクタリングと言っているものは、あなたにとってリファクタリングではないのだろう。
ただ、この論文の中では"Refactoring Techniques"を適用することがリファクタリングなんだ。そして、リファクタリングをしたのは学生さん。ある意味、予想通りの結果。
びっくりするくらい大規模なリファクタリングしてますね。クラス階層変えるような変更は、慎重にやらないと読みづらくなることは十分あり得ると思います。て考えると、特に意外な結果ではなくて、「無分別なリファクタリングは返ってコードが読みづらくなる」という当たり前の結論のような。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
保守性≒解析性だと思ってた (スコア:0)
タイトルどおりなんだけど、3段落目の
リファクタリングされたコードの方が解析性が劣り
と
リファクタリングすることの利点として保守性指数が僅かに高かった
が、矛盾してない?
俺の思っている保守性とは、また違うものなのかしらん?
Re: (スコア:0)
矛盾しないように解釈するなら、コードを理解するコストと、問題発生時に修正するコストの違いじゃねぇの。
Re: (スコア:0)
この論文では
解析性(人間がコードを評価した結果)
保守性指数(ツールがコードを評価した結果)
なのでツールは人間の感覚を再現するものではない、ということかと。
Re: (スコア:0)
「解析性」は「可読性」と読み替えるとして、
「バグが出て修正に時間がかかっている」らしい記述からすると、
リファクタリングに失敗して保守性は低下しているようですから、
「保守性指数」の算定アルゴリズムが現実の「保守性」を表していないということでしょうか…
Re: (スコア:0)
例えばだけど、
を
みたいなリファクタリングだと、保守性が上がって解析性が下がってる、ってことでしょ。プログラマはpink[0]が赤成分なのか青成分なのかわからないけど、pink.redはそれを間違う心配がない。一方で、「unsigned char pink[3];」を見れば、pinkが0〜255の値を持つ配列だっ
Re: (スコア:0)
バグが出て修正に時間がかかったのに保守性は改善したとか、いろいろ矛盾していますね。
可能性
・統計情報を適切に読み解けてない
・記事(あるいは翻訳)が傾向と事例を区別できていない
・まともにできる人がいなくて、「失敗することが多かった」と言っているだけ
:
Re: (スコア:0)
元の論文を読めばわかることだけど、適用したリファクタリングは以下のようなもの。特にR3~R6を無分別に適用したせいで、コーディングのミスや漏れを防げるようになった代わりに、処理の具体的内容が読みづらくなったということだと思う。
Re:保守性≒解析性だと思ってた (スコア:1)
その操作を個々の状況、条件から適切なものを選んで適用するのがリファクタリングなんだから、無分別に適用したらリファクタリングじゃない。
Re: (スコア:0)
あなたの分別はある人からしたら無分別かも知れないし、ある人の分別はあなたにとっては無分別かも知れない。したがって、彼らがリファクタリングと言っているものは、あなたにとってリファクタリングではないのだろう。
ただ、この論文の中では"Refactoring Techniques"を適用することがリファクタリングなんだ。そして、リファクタリングをしたのは学生さん。ある意味、予想通りの結果。
Re: (スコア:0)
びっくりするくらい大規模なリファクタリングしてますね。
クラス階層変えるような変更は、慎重にやらないと読みづらくなることは十分あり得ると思います。
て考えると、特に意外な結果ではなくて、「無分別なリファクタリングは返ってコードが読みづらくなる」という当たり前の結論のような。