アカウント名:
パスワード:
銀行の勘定系なんてコピペの嵐だろうに。JCLとか。今後、みずほがシステム停止とかした時に大量のコードクローンが見つかったら、「重複する記述を含むプログラムは品質が極めて低い」という指摘を甘んじて受けるつもりなんだろうか。
ワインバーグの工学の第一法則 壊れてないものを直すな。
機能追加で動いている物に手を付けて綺麗に作りなおすのは担当者のエゴだと思う。重複があろうと完全分離したほうが安心じゃないのかな?株って株式取引所で人手の売買立会での誤発注も取り消しできない厳しい世界じゃなかったのか?一瞬の判断ミスで破産する世界だろ。
明らかな誤発注の場合には、取り消せますよ。だからこそ、取り消し機能があったのですし。ついでに言えば、株の売買契約が成立する前なら、誤発注でなくても取り消せます。ジェイコムの場合、誤発注に気がついて、『まだ、買い手が気がついていない、契約も成立していない』状態、すなわち取り消すことができるのは当たり前の状態で、取り消しコマンドが機能しないという、株の売買をするソフトとして絶対にあってはならないバグだったのです。で、みずほの誤発注者は、数回取り消しのコマンドを実行しようとしてうまくいかないので、東証にも連絡し、それでもらちがあかないので、非常手段として、本来は禁止されている『自分が出した売り注文に、自分で買い注文を入れて買い戻す』というやり方で、契約が成立していなかった残りの株を回収しています。最小からそうすれば、被害はもっと小さくなったかもしれませんが、自分で同時に売りと買いの出すのは、相場操縦を目的とした自作自演の不正行為と見なされる禁止事項なので、普通は『発注の取消』を実行します。
ところで、『壊れていないもの(正確に言えば不具合がまだ見つかっていないもの)を治すな』は、必ずしも絶対に守らなければならないルールではなく、今どきはリファクタリングという名称がついた、定常作業では? それに、入力した数値の範囲チェックがなく、発行株数をはるかに上回る数の株を、値幅制限のルールを逸脱する値段で売り注文できてしまったというのは、バグどころの話ではないです。
発行株数をはるかに上回る数の株を、値幅制限のルールを逸脱する値段で売り注文できてしまったというのは、バグどころの話ではないです。
>発行株数をはるかに上回る数の株
空売りとか良くある
>値幅制限のルールを逸脱する値段
初値だったから、値幅制限なんて存在しない
東証が、壊れている事かもしれない事を認識しつつ、「まだ壊れてないから改修するリスクは踏みたくないなぁ」と考えてたとしたら、それがまさに重過失とやらになるんじゃないの?
> 壊れてないものを直すな。> 重複があろうと完全分離したほうが安心じゃないのかな?
仕様変更が無い限りにおいては、全く正しいとは思います。
でも、重複部分は時限爆弾みたいなもので、重複部分が仕様変更対象となったときは、全部見直しをしなければいけないのですが、往々にして、直し忘れとか、別処理にしなきゃいけないのに他の箇所と同じコードをつっこんだとかで、無数のバグに悩まされることになります。
# まあ重複の排除って、# 関数のポインタとか、抽象クラスとか、高階関数とかの支援がある言語でないと、# 事実上無理ですよね。
リファクタリングってことばがあるわけで
リファクタリング信奉者は実務を知らない
と、言う人がたまにいるが、多くは「実務」とは何かを考えたことはない。「実務はリファクタリングではない」「リファクタリングは実務ではない」というトートロジーに陥っているだけである。
「実務」とは、開発者とは別の顧客がいて、開発者の生産物(成果)を渡すことで顧客から対価を受けとる事を前提とした作業とするならば、たとえば、
1.開発を行う2.機能的な評価をする3.機能以外の要件(性能、保守性)を満たすためにリファクタリングするというプロセスに顧客と合意がとれているのであれば、それは「実務」である。
「リファクタリング信奉者は実務を知らない」という人はそういうプロセスの「実務」を想像できないだけである。
対価が取れる作業であれば、リファクタリングは「実務」である。対価が取れない作業はやるべきではないという経験則があるような気がするだけ。#具体的な対価はなくても、やったほうがいいだろうという作業はあると思う
実際は程度の問題であり、ひどすぎるコードの場合は一個一個バグを潰していくより、根本的に作りなおした方が良い場合もあるわけで…
実際はそこまで極端な例は少ないでしょうけど、少なくとも完全否定するものではありません。
そう思うならそうすればいいんじゃないの
ところがね…
一体いつから───────壊れていないと錯覚していた?
ってぐらい、明らかにまずい箇所があるコードが使い続けられてることも多々あったりして。
「壊れてないものを直すな」といっても、ソフトウェアをジェンガにしちゃいけませんけどね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
みずほの主張は自分の首を絞めてるようにしか思えない (スコア:5, 興味深い)
銀行の勘定系なんてコピペの嵐だろうに。JCLとか。
今後、みずほがシステム停止とかした時に大量のコードクローンが見つかったら、
「重複する記述を含むプログラムは品質が極めて低い」
という指摘を甘んじて受けるつもりなんだろうか。
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:4, すばらしい洞察)
ワインバーグの工学の第一法則
壊れてないものを直すな。
機能追加で動いている物に手を付けて綺麗に作りなおすのは担当者のエゴだと思う。
重複があろうと完全分離したほうが安心じゃないのかな?
株って株式取引所で人手の売買立会での誤発注も取り消しできない厳しい世界じゃなかったのか?
一瞬の判断ミスで破産する世界だろ。
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:2, 参考になる)
明らかな誤発注の場合には、取り消せますよ。だからこそ、取り消し機能があったのですし。ついでに言えば、株の売買契約が成立する前なら、誤発注でなくても取り消せます。ジェイコムの場合、誤発注に気がついて、『まだ、買い手が気がついていない、契約も成立していない』状態、すなわち取り消すことができるのは当たり前の状態で、取り消しコマンドが機能しないという、株の売買をするソフトとして絶対にあってはならないバグだったのです。
で、みずほの誤発注者は、数回取り消しのコマンドを実行しようとしてうまくいかないので、東証にも連絡し、それでもらちがあかないので、非常手段として、本来は禁止されている『自分が出した売り注文に、自分で買い注文を入れて買い戻す』というやり方で、契約が成立していなかった残りの株を回収しています。最小からそうすれば、被害はもっと小さくなったかもしれませんが、自分で同時に売りと買いの出すのは、相場操縦を目的とした自作自演の不正行為と見なされる禁止事項なので、普通は『発注の取消』を実行します。
ところで、『壊れていないもの(正確に言えば不具合がまだ見つかっていないもの)を治すな』は、必ずしも絶対に守らなければならないルールではなく、今どきはリファクタリングという名称がついた、定常作業では? それに、入力した数値の範囲チェックがなく、発行株数をはるかに上回る数の株を、値幅制限のルールを逸脱する値段で売り注文できてしまったというのは、バグどころの話ではないです。
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:1, すばらしい洞察)
発行株数をはるかに上回る数の株を、値幅制限のルールを逸脱する値段で売り注文できてしまったというのは、バグどころの話ではないです。
>発行株数をはるかに上回る数の株
空売りとか良くある
>値幅制限のルールを逸脱する値段
初値だったから、値幅制限なんて存在しない
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:1)
東証が、壊れている事かもしれない事を認識しつつ、
「まだ壊れてないから改修するリスクは踏みたくないなぁ」
と考えてたとしたら、それがまさに重過失とやらになるんじゃないの?
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:1)
壊れる頃には手のつけられないものになってたり。
Re: (スコア:0)
> 壊れてないものを直すな。
> 重複があろうと完全分離したほうが安心じゃないのかな?
仕様変更が無い限りにおいては、全く正しいとは思います。
でも、重複部分は時限爆弾みたいなもので、
重複部分が仕様変更対象となったときは、
全部見直しをしなければいけないのですが、
往々にして、直し忘れとか、別処理にしなきゃいけないのに他の箇所と同じコードをつっこんだとかで、
無数のバグに悩まされることになります。
# まあ重複の排除って、
# 関数のポインタとか、抽象クラスとか、高階関数とかの支援がある言語でないと、
# 事実上無理ですよね。
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:1)
リファクタリングってことばがあるわけで
Re: (スコア:0)
リファクタリング信奉者は実務を知らない
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:1)
と、言う人がたまにいるが、多くは「実務」とは何かを考えたことはない。
「実務はリファクタリングではない」「リファクタリングは実務ではない」というトートロジーに陥っているだけである。
「実務」とは、開発者とは別の顧客がいて、開発者の生産物(成果)を渡すことで顧客から対価を受けとる事を前提とした作業とするならば、たとえば、
1.開発を行う
2.機能的な評価をする
3.機能以外の要件(性能、保守性)を満たすためにリファクタリングする
というプロセスに顧客と合意がとれているのであれば、それは「実務」である。
「リファクタリング信奉者は実務を知らない」という人はそういうプロセスの「実務」を想像できないだけである。
対価が取れる作業であれば、リファクタリングは「実務」である。
対価が取れない作業はやるべきではないという経験則があるような気がするだけ。
#具体的な対価はなくても、やったほうがいいだろうという作業はあると思う
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:1)
実際は程度の問題であり、ひどすぎるコードの場合は一個一個バグを潰していくより、根本的に作りなおした方が良い場合もあるわけで…
実際はそこまで極端な例は少ないでしょうけど、少なくとも完全否定するものではありません。
Re: (スコア:0)
そう思うならそうすればいいんじゃないの
Re: (スコア:0)
ところがね…
一体いつから───────壊れていないと錯覚していた?
ってぐらい、明らかにまずい箇所があるコードが使い続けられてることも多々あったりして。
Re: (スコア:0)
「壊れてないものを直すな」といっても、ソフトウェアをジェンガにしちゃいけませんけどね。