アカウント名:
パスワード:
銀行の勘定系なんてコピペの嵐だろうに。JCLとか。今後、みずほがシステム停止とかした時に大量のコードクローンが見つかったら、「重複する記述を含むプログラムは品質が極めて低い」という指摘を甘んじて受けるつもりなんだろうか。
ワインバーグの工学の第一法則 壊れてないものを直すな。
機能追加で動いている物に手を付けて綺麗に作りなおすのは担当者のエゴだと思う。重複があろうと完全分離したほうが安心じゃないのかな?株って株式取引所で人手の売買立会での誤発注も取り消しできない厳しい世界じゃなかったのか?一瞬の判断ミスで破産する世界だろ。
> 壊れてないものを直すな。> 重複があろうと完全分離したほうが安心じゃないのかな?
仕様変更が無い限りにおいては、全く正しいとは思います。
でも、重複部分は時限爆弾みたいなもので、重複部分が仕様変更対象となったときは、全部見直しをしなければいけないのですが、往々にして、直し忘れとか、別処理にしなきゃいけないのに他の箇所と同じコードをつっこんだとかで、無数のバグに悩まされることになります。
# まあ重複の排除って、# 関数のポインタとか、抽象クラスとか、高階関数とかの支援がある言語でないと、# 事実上無理ですよね。
リファクタリングってことばがあるわけで
リファクタリング信奉者は実務を知らない
と、言う人がたまにいるが、多くは「実務」とは何かを考えたことはない。「実務はリファクタリングではない」「リファクタリングは実務ではない」というトートロジーに陥っているだけである。
「実務」とは、開発者とは別の顧客がいて、開発者の生産物(成果)を渡すことで顧客から対価を受けとる事を前提とした作業とするならば、たとえば、
1.開発を行う2.機能的な評価をする3.機能以外の要件(性能、保守性)を満たすためにリファクタリングするというプロセスに顧客と合意がとれているのであれば、それは「実務」である。
「リファクタリング信奉者は実務を知らない」という人はそういうプロセスの「実務」を想像できないだけである。
対価が取れる作業であれば、リファクタリングは「実務」である。対価が取れない作業はやるべきではないという経験則があるような気がするだけ。#具体的な対価はなくても、やったほうがいいだろうという作業はあると思う
実際は程度の問題であり、ひどすぎるコードの場合は一個一個バグを潰していくより、根本的に作りなおした方が良い場合もあるわけで…
実際はそこまで極端な例は少ないでしょうけど、少なくとも完全否定するものではありません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
みずほの主張は自分の首を絞めてるようにしか思えない (スコア:5, 興味深い)
銀行の勘定系なんてコピペの嵐だろうに。JCLとか。
今後、みずほがシステム停止とかした時に大量のコードクローンが見つかったら、
「重複する記述を含むプログラムは品質が極めて低い」
という指摘を甘んじて受けるつもりなんだろうか。
Re: (スコア:4, すばらしい洞察)
ワインバーグの工学の第一法則
壊れてないものを直すな。
機能追加で動いている物に手を付けて綺麗に作りなおすのは担当者のエゴだと思う。
重複があろうと完全分離したほうが安心じゃないのかな?
株って株式取引所で人手の売買立会での誤発注も取り消しできない厳しい世界じゃなかったのか?
一瞬の判断ミスで破産する世界だろ。
Re: (スコア:0)
> 壊れてないものを直すな。
> 重複があろうと完全分離したほうが安心じゃないのかな?
仕様変更が無い限りにおいては、全く正しいとは思います。
でも、重複部分は時限爆弾みたいなもので、
重複部分が仕様変更対象となったときは、
全部見直しをしなければいけないのですが、
往々にして、直し忘れとか、別処理にしなきゃいけないのに他の箇所と同じコードをつっこんだとかで、
無数のバグに悩まされることになります。
# まあ重複の排除って、
# 関数のポインタとか、抽象クラスとか、高階関数とかの支援がある言語でないと、
# 事実上無理ですよね。
Re: (スコア:1)
リファクタリングってことばがあるわけで
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:0)
リファクタリング信奉者は実務を知らない
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:1)
と、言う人がたまにいるが、多くは「実務」とは何かを考えたことはない。
「実務はリファクタリングではない」「リファクタリングは実務ではない」というトートロジーに陥っているだけである。
「実務」とは、開発者とは別の顧客がいて、開発者の生産物(成果)を渡すことで顧客から対価を受けとる事を前提とした作業とするならば、たとえば、
1.開発を行う
2.機能的な評価をする
3.機能以外の要件(性能、保守性)を満たすためにリファクタリングする
というプロセスに顧客と合意がとれているのであれば、それは「実務」である。
「リファクタリング信奉者は実務を知らない」という人はそういうプロセスの「実務」を想像できないだけである。
対価が取れる作業であれば、リファクタリングは「実務」である。
対価が取れない作業はやるべきではないという経験則があるような気がするだけ。
#具体的な対価はなくても、やったほうがいいだろうという作業はあると思う
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:1)
実際は程度の問題であり、ひどすぎるコードの場合は一個一個バグを潰していくより、根本的に作りなおした方が良い場合もあるわけで…
実際はそこまで極端な例は少ないでしょうけど、少なくとも完全否定するものではありません。