アカウント名:
パスワード:
銀行の勘定系なんてコピペの嵐だろうに。JCLとか。今後、みずほがシステム停止とかした時に大量のコードクローンが見つかったら、「重複する記述を含むプログラムは品質が極めて低い」という指摘を甘んじて受けるつもりなんだろうか。
ワインバーグの工学の第一法則 壊れてないものを直すな。
機能追加で動いている物に手を付けて綺麗に作りなおすのは担当者のエゴだと思う。重複があろうと完全分離したほうが安心じゃないのかな?株って株式取引所で人手の売買立会での誤発注も取り消しできない厳しい世界じゃなかったのか?一瞬の判断ミスで破産する世界だろ。
明らかな誤発注の場合には、取り消せますよ。だからこそ、取り消し機能があったのですし。ついでに言えば、株の売買契約が成立する前なら、誤発注でなくても取り消せます。ジェイコムの場合、誤発注に気がついて、『まだ、買い手が気がついていない、契約も成立していない』状態、すなわち取り消すことができるのは当たり前の状態で、取り消しコマンドが機能しないという、株の売買をするソフトとして絶対にあってはならないバグだったのです。で、みずほの誤発注者は、数回取り消しのコマンドを実行しようとしてうまくいかないので、東証にも連絡し、それでもらちがあかないので、非常手段として、本来は禁止されている『自分が出した売り注文に、自分で買い注文を入れて買い戻す』というやり方で、契約が成立していなかった残りの株を回収しています。最小からそうすれば、被害はもっと小さくなったかもしれませんが、自分で同時に売りと買いの出すのは、相場操縦を目的とした自作自演の不正行為と見なされる禁止事項なので、普通は『発注の取消』を実行します。
ところで、『壊れていないもの(正確に言えば不具合がまだ見つかっていないもの)を治すな』は、必ずしも絶対に守らなければならないルールではなく、今どきはリファクタリングという名称がついた、定常作業では? それに、入力した数値の範囲チェックがなく、発行株数をはるかに上回る数の株を、値幅制限のルールを逸脱する値段で売り注文できてしまったというのは、バグどころの話ではないです。
発行株数をはるかに上回る数の株を、値幅制限のルールを逸脱する値段で売り注文できてしまったというのは、バグどころの話ではないです。
>発行株数をはるかに上回る数の株
空売りとか良くある
>値幅制限のルールを逸脱する値段
初値だったから、値幅制限なんて存在しない
東証が、壊れている事かもしれない事を認識しつつ、「まだ壊れてないから改修するリスクは踏みたくないなぁ」と考えてたとしたら、それがまさに重過失とやらになるんじゃないの?
> 壊れてないものを直すな。> 重複があろうと完全分離したほうが安心じゃないのかな?
仕様変更が無い限りにおいては、全く正しいとは思います。
でも、重複部分は時限爆弾みたいなもので、重複部分が仕様変更対象となったときは、全部見直しをしなければいけないのですが、往々にして、直し忘れとか、別処理にしなきゃいけないのに他の箇所と同じコードをつっこんだとかで、無数のバグに悩まされることになります。
# まあ重複の排除って、# 関数のポインタとか、抽象クラスとか、高階関数とかの支援がある言語でないと、# 事実上無理ですよね。
リファクタリングってことばがあるわけで
リファクタリング信奉者は実務を知らない
と、言う人がたまにいるが、多くは「実務」とは何かを考えたことはない。「実務はリファクタリングではない」「リファクタリングは実務ではない」というトートロジーに陥っているだけである。
「実務」とは、開発者とは別の顧客がいて、開発者の生産物(成果)を渡すことで顧客から対価を受けとる事を前提とした作業とするならば、たとえば、
1.開発を行う2.機能的な評価をする3.機能以外の要件(性能、保守性)を満たすためにリファクタリングするというプロセスに顧客と合意がとれているのであれば、それは「実務」である。
「リファクタリング信奉者は実務を知らない」という人はそういうプロセスの「実務」を想像できないだけである。
対価が取れる作業であれば、リファクタリングは「実務」である。対価が取れない作業はやるべきではないという経験則があるような気がするだけ。#具体的な対価はなくても、やったほうがいいだろうという作業はあると思う
実際は程度の問題であり、ひどすぎるコードの場合は一個一個バグを潰していくより、根本的に作りなおした方が良い場合もあるわけで…
実際はそこまで極端な例は少ないでしょうけど、少なくとも完全否定するものではありません。
そう思うならそうすればいいんじゃないの
ところがね…
一体いつから───────壊れていないと錯覚していた?
ってぐらい、明らかにまずい箇所があるコードが使い続けられてることも多々あったりして。
「壊れてないものを直すな」といっても、ソフトウェアをジェンガにしちゃいけませんけどね。
内情はしらんですけど大手銀行さんはたいていシステム開発子会社を持ってるし経験も豊富なんで、それなりの経験と技術の蓄積はあるんでは。
# それでもコピペはあるでしょうけど
都市銀が統合再編される前(20年くらい前)の話ですが、某都市銀の開発を請けおってた大手電気メーカーでは、ドキュメントやソースコードは「原本」「複製」「テスト用」をプリントアウトした状態で管理してました。
「原本」は実機(銀行)で動いてるソースで鍵付きの棚に補完。実機にパッチあてたりしてソースを変更した場合、上司の承認&バージョン管理履歴残して赤書き。赤書きってのは元のソースを赤ペンで修正すること。
「複製」は実機を書きかえる前の「実機修正予定」ソース。原本が鍵付きなので、原本と同じソースをいつでも見れるようにするために用意した模様。
「テスト用」は文字どおり工場で再現・修正したソース。赤書きではなく、200ページ1版、200ページ2版みたいな管理でした。修正箇所が多いと差し込みが多く、かつ旧版を残しておくため、ページ増えすぎてカオス。
#数年後にはデジタル管理(ファイル共有)になりましたけど、#アナログだろうとデジタルだろうと、コーディング終了=ドキュメント不要はありえないなあ。
8月28日富士銀行でオンラインが停止した。当時新人だった私はプリントアウトをえっちらおっちら運んだな。
RDSがハードウエア障害によりNull上書きされてしまい、あとはもうどうしようもならなくなったことはあまり知られていない。
その後、ポケプシーから設計者の大先生がお土産に干しアプリコットを持参して、何度も実験して成果を担いで帰っていった。
美味しい思い出である
数年前、某大手M社で作業したときのこと。
「これこれというソフトウェアをこういうふうに修正してください」「分かりました。ドキュメントはいついただけますか」「ありません」「は?」「以前のドキュメントはありませんし、新しいドキュメントも作りません。 口頭で変更を説明しますので、コーディングをお願いします」「ドキュメント無しでの作業は問題があると思いますが?」「そんな時間は割り振っていませんし、その方が効率がいいので」「はぁ……」
案の定、後から仕様通知漏れが二、三度発生して数日の徹夜が発生したことも、責任が自分に降りかかってきたことも、いい思い出だ。
あの後、だれかドキュメント書いたのかなぁ……
15年ほど昔の話。 その頃の私は極めて遅れたものの、いい年であることを自覚しつつプログラマに転身しようと心に決めて、とある小さな会社に入ったのですが。 入社後すぐに、とある下請けプロジェクトの打ち合わせ会議に業界の雰囲気に慣れる為にも参加しました。 どうやら通信ログから料金を計算するプログラムらしいのですが、コードの一部を見せてもらったらVBで殆ど同じ内容のIF文が延々と続いていて・・・。 絶句して『コレなんですか!?』と聞いたら料金計算の例外処理の追加が多すぎて、アルゴリズムでエレガントに処理出来ないとの事。 追記が楽なIF文は最強らしい。 小手先の技工に拘るのは仕事として愚かでしょうけど、当時の私にはとてもじゃないけど受け付けられない現実でした。 今でも厳しいですけど。
でも大手生え抜きであれ中小下請けであれ、技術ってそんなに差はないよね?
それは技術の差というより、メンテの頻度・方針の差、というものだと思う。会社規模の大小じゃなく、仕事のスタンスの差は、積み重なると、大きな実績の差にはなるね。そして、誰もやってないから自分もやらないというのは言い訳に過ぎない訳で、最初は小さくても大きな改善に繋がる一歩はいつでも可能だったりする。
ps.直接じゃなく間接に、とか手段の引き出しは多いとやれることは多くなるね。
なるほど、経験の蓄積から「品質が極めて低い」ということが分かるんですね。そして低品質の検証を続けているのでしょうか……涙ぐましいですね
# 何はともあれテストした結果が残ってねぇってのはアウトだろ……
経験がどうこうの前に、静的解析でもすれば客観的に品質が分かるよね。
COBOLは雛型を作ってモジュールごとに当てはめましたね。言語の仕様上共通化するのが難しく、似たようなコードが何度もでてくるので。入金と出金は別モジュールだけど、足すか引くかの違い、だからコピー、みたいな。
ここでVocjuとかLyeeってキーワード出したら消されますか!?
COBOLでコードクローン減らせとか……
#COBOLで開発したことないけどさ。
> システム停止とかした時に大量のコードクローンが見つかったら、(略)> 指摘を甘んじて受けるつもりなんだろうか。
そこに異論はないけど、しかしみずほ銀行じゃなくて証券だしなぁコレ(同じグループではあるが)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
みずほの主張は自分の首を絞めてるようにしか思えない (スコア: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)
「壊れてないものを直すな」といっても、ソフトウェアをジェンガにしちゃいけませんけどね。
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:2)
内情はしらんですけど大手銀行さんはたいていシステム開発子会社を持ってるし
経験も豊富なんで、それなりの経験と技術の蓄積はあるんでは。
# それでもコピペはあるでしょうけど
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:5, 参考になる)
都市銀が統合再編される前(20年くらい前)の話ですが、
某都市銀の開発を請けおってた大手電気メーカーでは、
ドキュメントやソースコードは「原本」「複製」「テスト用」をプリントアウトした状態で管理してました。
「原本」は実機(銀行)で動いてるソースで鍵付きの棚に補完。
実機にパッチあてたりしてソースを変更した場合、上司の承認&バージョン管理履歴残して赤書き。
赤書きってのは元のソースを赤ペンで修正すること。
「複製」は実機を書きかえる前の「実機修正予定」ソース。
原本が鍵付きなので、原本と同じソースをいつでも見れるようにするために用意した模様。
「テスト用」は文字どおり工場で再現・修正したソース。
赤書きではなく、200ページ1版、200ページ2版みたいな管理でした。
修正箇所が多いと差し込みが多く、かつ旧版を残しておくため、ページ増えすぎてカオス。
#数年後にはデジタル管理(ファイル共有)になりましたけど、
#アナログだろうとデジタルだろうと、コーディング終了=ドキュメント不要はありえないなあ。
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:5, 参考になる)
8月28日富士銀行でオンラインが停止した。当時新人だった私はプリントアウトをえっちらおっちら運んだな。
RDSがハードウエア障害によりNull上書きされてしまい、あとはもうどうしようもならなくなったことはあまり知られていない。
その後、ポケプシーから設計者の大先生がお土産に干しアプリコットを持参して、何度も実験して成果を担いで帰っていった。
美味しい思い出である
Re: (スコア:0)
数年前、某大手M社で作業したときのこと。
「これこれというソフトウェアをこういうふうに修正してください」
「分かりました。ドキュメントはいついただけますか」
「ありません」
「は?」
「以前のドキュメントはありませんし、新しいドキュメントも作りません。
口頭で変更を説明しますので、コーディングをお願いします」
「ドキュメント無しでの作業は問題があると思いますが?」
「そんな時間は割り振っていませんし、その方が効率がいいので」
「はぁ……」
案の定、後から仕様通知漏れが二、三度発生して数日の徹夜が発生したことも、
責任が自分に降りかかってきたことも、いい思い出だ。
あの後、だれかドキュメント書いたのかなぁ……
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:3, おもしろおかしい)
15年ほど昔の話。
その頃の私は極めて遅れたものの、いい年であることを自覚
しつつプログラマに転身しようと心に決めて、とある小さな会社に入ったのですが。
入社後すぐに、とある下請けプロジェクトの打ち合わせ会議に
業界の雰囲気に慣れる為にも参加しました。
どうやら通信ログから料金を計算するプログラムらしいのですが、
コードの一部を見せてもらったらVBで殆ど同じ内容のIF文が延々と続いていて・・・。
絶句して『コレなんですか!?』と聞いたら料金計算の例外処理の
追加が多すぎて、アルゴリズムでエレガントに処理出来ないとの事。
追記が楽なIF文は最強らしい。
小手先の技工に拘るのは仕事として愚かでしょうけど、当時の
私にはとてもじゃないけど受け付けられない現実でした。 今でも厳しいですけど。
でも大手生え抜きであれ中小下請けであれ、技術ってそんなに差はないよね?
Re: (スコア:0)
それは技術の差というより、メンテの頻度・方針の差、というものだと思う。会社規模の大小じゃなく、仕事のスタンスの差は、積み重なると、大きな実績の差にはなるね。そして、誰もやってないから自分もやらないというのは言い訳に過ぎない訳で、最初は小さくても大きな改善に繋がる一歩はいつでも可能だったりする。
ps.直接じゃなく間接に、とか手段の引き出しは多いとやれることは多くなるね。
Re: (スコア:0)
なるほど、経験の蓄積から
「品質が極めて低い」ということが分かるんですね。
そして低品質の検証を続けているのでしょうか……涙ぐましいですね
# 何はともあれテストした結果が残ってねぇってのはアウトだろ……
Re: (スコア:0)
経験がどうこうの前に、静的解析でもすれば客観的に品質が分かるよね。
Re: (スコア:0)
ちょっとだけちがうけどこれと同じだよね?みたいなのがわんさか。
言語仕様上融通が利かなくて仕方ない部分があるような気がします。
大規模なものは汎用xxみたいに共通化されますが、やっぱり融通が利かないのでひどく使いにくそうなインターフェースでした。
# まぁ汎用xxみたいな名前が付く時点で汎用的なものを作るのが大変なんだろうなって思いますが。
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:1)
COBOLは雛型を作ってモジュールごとに当てはめましたね。
言語の仕様上共通化するのが難しく、似たようなコードが何度もでてくるので。
入金と出金は別モジュールだけど、足すか引くかの違い、だからコピー、みたいな。
Re: (スコア:0)
ここでVocjuとかLyeeってキーワード出したら消されますか!?
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:1)
COBOLでコードクローン減らせとか……
#COBOLで開発したことないけどさ。
Re: (スコア:0)
> システム停止とかした時に大量のコードクローンが見つかったら、
(略)
> 指摘を甘んじて受けるつもりなんだろうか。
そこに異論はないけど、しかしみずほ銀行じゃなくて証券だしなぁコレ(同じグループではあるが)
Re: (スコア:0)