アカウント名:
パスワード:
銀行の勘定系なんてコピペの嵐だろうに。JCLとか。今後、みずほがシステム停止とかした時に大量のコードクローンが見つかったら、「重複する記述を含むプログラムは品質が極めて低い」という指摘を甘んじて受けるつもりなんだろうか。
内情はしらんですけど大手銀行さんはたいていシステム開発子会社を持ってるし経験も豊富なんで、それなりの経験と技術の蓄積はあるんでは。
# それでもコピペはあるでしょうけど
都市銀が統合再編される前（20年くらい前）の話ですが、某都市銀の開発を請けおってた大手電気メーカーでは、ドキュメントやソースコードは「原本」「複製」「テスト用」をプリントアウトした状態で管理してました。
「原本」は実機（銀行）で動いてるソースで鍵付きの棚に補完。実機にパッチあてたりしてソースを変更した場合、上司の承認＆バージョン管理履歴残して赤書き。赤書きってのは元のソースを赤ペンで修正すること。
「複製」は実機を書きかえる前の「実機修正予定」ソース。原本が鍵付きなので、原本と同じソースをいつでも見れるようにするために用意した模様。
「テスト用」は文字どおり工場で再現・修正したソース。赤書きではなく、200ページ1版、200ページ2版みたいな管理でした。修正箇所が多いと差し込みが多く、かつ旧版を残しておくため、ページ増えすぎてカオス。
＃数年後にはデジタル管理（ファイル共有）になりましたけど、＃アナログだろうとデジタルだろうと、コーディング終了＝ドキュメント不要はありえないなあ。
8月28日富士銀行でオンラインが停止した。当時新人だった私はプリントアウトをえっちらおっちら運んだな。
RDSがハードウエア障害によりNull上書きされてしまい、あとはもうどうしようもならなくなったことはあまり知られていない。
その後、ポケプシーから設計者の大先生がお土産に干しアプリコットを持参して、何度も実験して成果を担いで帰っていった。
美味しい思い出である
数年前、某大手M社で作業したときのこと。
「これこれというソフトウェアをこういうふうに修正してください」「分かりました。ドキュメントはいついただけますか」「ありません」「は？」「以前のドキュメントはありませんし、新しいドキュメントも作りません。 口頭で変更を説明しますので、コーディングをお願いします」「ドキュメント無しでの作業は問題があると思いますが？」「そんな時間は割り振っていませんし、その方が効率がいいので」「はぁ……」
案の定、後から仕様通知漏れが二、三度発生して数日の徹夜が発生したことも、責任が自分に降りかかってきたことも、いい思い出だ。
あの後、だれかドキュメント書いたのかなぁ……
15年ほど昔の話。 その頃の私は極めて遅れたものの、いい年であることを自覚しつつプログラマに転身しようと心に決めて、とある小さな会社に入ったのですが。 入社後すぐに、とある下請けプロジェクトの打ち合わせ会議に業界の雰囲気に慣れる為にも参加しました。 どうやら通信ログから料金を計算するプログラムらしいのですが、コードの一部を見せてもらったらVBで殆ど同じ内容のIF文が延々と続いていて・・・。 絶句して『コレなんですか！？』と聞いたら料金計算の例外処理の追加が多すぎて、アルゴリズムでエレガントに処理出来ないとの事。 追記が楽なIF文は最強らしい。 小手先の技工に拘るのは仕事として愚かでしょうけど、当時の私にはとてもじゃないけど受け付けられない現実でした。 今でも厳しいですけど。
でも大手生え抜きであれ中小下請けであれ、技術ってそんなに差はないよね？
それは技術の差というより、メンテの頻度・方針の差、というものだと思う。会社規模の大小じゃなく、仕事のスタンスの差は、積み重なると、大きな実績の差にはなるね。そして、誰もやってないから自分もやらないというのは言い訳に過ぎない訳で、最初は小さくても大きな改善に繋がる一歩はいつでも可能だったりする。
ps.直接じゃなく間接に、とか手段の引き出しは多いとやれることは多くなるね。
なるほど、経験の蓄積から「品質が極めて低い」ということが分かるんですね。そして低品質の検証を続けているのでしょうか……涙ぐましいですね
# 何はともあれテストした結果が残ってねぇってのはアウトだろ……
経験がどうこうの前に、静的解析でもすれば客観的に品質が分かるよね。
COBOLは雛型を作ってモジュールごとに当てはめましたね。言語の仕様上共通化するのが難しく、似たようなコードが何度もでてくるので。入金と出金は別モジュールだけど、足すか引くかの違い、だからコピー、みたいな。
ここでVocjuとかLyeeってキーワード出したら消されますか！？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
みずほの主張は自分の首を絞めてるようにしか思えない (スコア:5, 興味深い)
銀行の勘定系なんてコピペの嵐だろうに。JCLとか。
今後、みずほがシステム停止とかした時に大量のコードクローンが見つかったら、
「重複する記述を含むプログラムは品質が極めて低い」
という指摘を甘んじて受けるつもりなんだろうか。
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)
ちょっとだけちがうけどこれと同じだよね？みたいなのがわんさか。
言語仕様上融通が利かなくて仕方ない部分があるような気がします。
大規模なものは汎用ｘｘみたいに共通化されますが、やっぱり融通が利かないのでひどく使いにくそうなインターフェースでした。
# まぁ汎用ｘｘみたいな名前が付く時点で汎用的なものを作るのが大変なんだろうなって思いますが。
Re:みずほの主張は自分の首を絞めてるようにしか思えない (スコア:1)
COBOLは雛型を作ってモジュールごとに当てはめましたね。
言語の仕様上共通化するのが難しく、似たようなコードが何度もでてくるので。
入金と出金は別モジュールだけど、足すか引くかの違い、だからコピー、みたいな。
Re: (スコア:0)
ここでVocjuとかLyeeってキーワード出したら消されますか！？