「タグ編集を許可」「まとめ編集を許可」機能を終了し、新たな「共同編集」機能を追加しました。
2022年2月13日

旧システムから新システムに移行する時、もし旧システムにバグがあって、新システムで直ってると、新システムにバグをわざわざ実装するという話。→「寝た子は起こすな」

これを機に…というのもある
60
ナオツ@フリーランス×フルリモート推進派エンジニア @NaotsuguSomeya

SIer時代にCOBOL→Javaのリプレイスやったんだけど、必ず登場するテストが「現新比較」。 旧システムと新システムで同じデータ食わせて、同じ結果が返ってくればOK。 もし旧システムにバグがあって、新システムで直ってると、テストはNG。 どうするか? 新システムでバグを実装します(実話)

2022-02-12 19:05:57

感想

StarQ5002 @SQ5002

@NaotsuguSomeya 僕もシステムリプレイス時に、やった経験あります。

2022-02-12 22:04:15
mania3bb @mania3bb2007

@NaotsuguSomeya うっかりバグを直すと、他の全然関係ないところに影響が出る可能性もあるし、実は政治的な理由や、当時のなんらかの事情の結果として、そうなっている可能性も考えられます。 直したところでお金がもらえるわけではないのに、面倒なことになる可能性だけはあって、デメリットしかないんですよね・・・

2022-02-13 12:27:34
すすすC++++ (SususuCSharp) @eieio81810

@NaotsuguSomeya すごく笑顔になりました。 あ、これバグだ!って思いながら実装するときの心の荒廃感が思い浮かぶようです。

2022-02-13 12:44:00
HISA @hisaeagle

@NaotsuguSomeya まぁ元請けやPMのスタンスにもよると思いますよ 自分も現新突合しましたが 新側で差異が出る レポート書いて比較結果と合わせて提出して 新は旧の変なロジック組み込まずそのままでしたよ

2022-02-13 12:52:17
avocado @avocado_tw

@NaotsuguSomeya @ATM_09_TD 現新比較中にバグに遭遇する事はあるあるデスね😊。 システムリプレイスは保守とスコープが違うので、システムリプレイスチー厶ではそのままにしておいて、保守チームでfixしているはずですよ。

2022-02-13 13:13:22
AKG@2月は逃げる3月は猿🐒 @akgamgakg

@NaotsuguSomeya 同じく、経験あり大手食品業 四捨五入の丸誤差のバグ 右と左が合わないはずだよ、、仕様書も正しいとはいえないからCOBOLのソースが正 なんだかなぁーと思いながらJava側を合わせたました。

2022-02-13 13:30:30
hideki@鉄分多め @yossy52

@NaotsuguSomeya 同じようにバグを実装したことあります。 例外発生するところまで同じように。。。

2022-02-13 13:44:56
luke yuzo @togoshicom

@NaotsuguSomeya そうなるとバグというよりも仕様と言った方が近い。 真面目な話で。

2022-02-13 13:54:26
MURAKAMI Ken@Ubuntu初心者 @kizetubutter

@NaotsuguSomeya 連携先がバグ前提で動いてるから直せなかったりする。シンプルなものだと単純にフラグの0/1が逆転してるとか。他だと素直に考えてバグと判断できるけどホントにバグかどうかは誰にも確定できないとか。よって現新比較のみが判断基準になる。

2022-02-13 14:06:25
カピバラ社畜 @SyatikuCapibara

@NaotsuguSomeya ただ現行互換を考えればこうなるしかなくて、正しい仕様がわからない以上、逆に結果を変えることはできない。下手に変えてどこかで処理結果異常や差分が出て業務止まったらこっちの全責任になるからこうなるしかない。

2022-02-13 14:18:32
GHENSAN@流れの侍アジャイルコーチ @GHEN_HANDYMEN

@NaotsuguSomeya 現新比較でそんなの見つけたら絶好の機会と喜ぶのに… その背景に興味があります。 推測ですが、「バブル時代に、建物建てる時に遺跡見つけたら黙って埋めてた」のと同じ心理な気がする

2022-02-13 14:32:30
健太 @Nessie_75

@NaotsuguSomeya それはモヤモヤしますね、そこは臨機応変に気づいた点として記録に残して修正したいですね笑

2022-02-13 15:43:16
横田洋人 @attoi

@NaotsuguSomeya テスト範囲の外側のシステムに、バクをひっくり返す処理が入っている可能性も否定できないので、判断が難しいところですね。

2022-02-13 17:01:56
rero @rero_carnelian

@GHEN_HANDYMEN @NaotsuguSomeya そのバグ直して終わりならいいけど、バグ直した結果生じた非互換性で他のシステムとの結合で不具合が出るかもしれんし、出ないことを保証するための検証もやりきれんからじゃね?

2022-02-13 15:01:23
T.Sax@組み込みエンジニア @T_SaX_From_Tp

現行と同じにするためのバグの実装やったことありますよ。 ぇ?これ普通ですよね?🤔 twitter.com/NaotsuguSomeya…

2022-02-13 17:09:31

中でどう繋がってるかわからないから

Youma. @UiMS_

あるあるなんだけど、 新システムにバグを搭載させるのが吉。 よかれと思ってもダメ。 リプレイスはリプレイスで区切って、 改善改修は改善改修で行う。 切り分けなきゃダメ。 twitter.com/NaotsuguSomeya…

2022-02-13 17:02:06
ほえほえ@DX塾 @hoehoe1234

その時点ではそのようにすると思います。そしてリプレイス後の次期開発で影響範囲を調査してから直すような問題なんだと思います。これは業務に限らず、MSの製品などでもそうなっています。リプレイス時とその後の開発を分けて考えるのが定石かと。 twitter.com/NaotsuguSomeya…

2022-02-13 16:57:50
火星人 @dispelmagic

出来るところなら一旦、バグありで仕上げて承認貰って改善で追加発注かな。 マイグレーション中に修正しちゃうと検証に時間がかかるんだよなあ。 一辺に出来るもんじゃあ無いのよね。 twitter.com/NaotsuguSomeya…

2022-02-13 16:51:42
すみ@エンジニア迷走中 @sumi35_s

この手のリプレースはよくやりました😅 バグ直すとなると設計から始めないといけないからスケジュール収まらないんですよね... 「俺が設計書だ!」みたいな人がいないと絶対納品間に合わない twitter.com/NaotsuguSomeya…

2022-02-13 16:47:56
残りを読む(13)

コメント

RGB000 @19666_61 2022年2月13日
簡単に再現できるバグならいいが、出現条件が面倒なバグだったら大変そう
8
ヒロセジロウ ✏️ @denjiro13 2022年2月13日
あくまで外野としては、シンプルに頭おかしい
31
spin_out @spin_over 2022年2月13日
種類にもよるけども。金額とかの内部の処理では済まないアウトプットだったら、いずれにせよ直すな。何かのフラグを手てているような処理だと、仕様書と違っても現状優先。他の仕様書見るとその違うフラグ前提の処理が書いてあったりするので、まあいろいろ。cobolだと変数の初期値に何を入れるかというのは次の処理でその変数の値を比較判定で使ったりするので現状優先にしないとデータが違う処理に乗ったりする。
0
杢丸 @mokumaru_NOP 2022年2月13日
NECの8080互換CPUのμPD8080A→μPD8080AFの流れを思い出すなぁ。バク修正版が不評で後から完全互換版を出したのだ。
5
okwae @okwae858 2022年2月13日
そのバグをなんとかするための処理が遥か彼方で行われてるとそっちでエラー出そうだな 仕方がないのか
7
シロネコ @straypas 2022年2月13日
「〇〇な時に××をする」ってプログラムや仕様書に書いてるのに、実装は逆の挙動。でも逆の挙動のまま運用が使ってるから、間違ったまま実装して、仕様書にもそのまま書かなきゃいけないってのが時折ある。やる方はすごく気持ち悪い
3
シロネコ @straypas 2022年2月13日
これ仕様書を正しく書くと、運用が勘違いのまま利用するスクリプト(エクセル上の何か?)を動かしてバグるから、仕様書直しちゃっても良くないってのがあったんだわ
1
RAIYA@提督 @RAIYASB 2022年2月13日
バグを逆用した設計になってたりするからねぇ 昔は処理できるコード数に制限があったりしたから、あえてバグを残して別の処理で補正するとかもあり得たという
6
i-MUNE @subutyuu 2022年2月13日
ゲームでもなぞのばしょとかバニシュデスとか消えてると寂しくなるもんね
6
ばしにぃ @hiro_orso_viola 2022年2月13日
「結果が変わらないようにする」のが要件だからデグレ確認はそれでよいのですよ。 仕様や要件の刷新は別の話なのだから劣後するかフェーズ2でやるべき。
8
SAKURA87🌸多摩停督 @Sakura87_net 2022年2月13日
例えばバグを直すのに1行コードを修正すればOKだけどそのバグがある前提でプログラムが組まれている所が1万行ある場合、バグは夜更け過ぎに仕様へと変わるだろう。
34
SAKURA87🌸多摩停督 @Sakura87_net 2022年2月13日
まぁ古いシステムの仕様書とか、実はコードが正常で仕様書の方が間違っている(組んでるコードのコメントと出力結果は一致していて他のプログラムが前提としている処理もバグの通りに動いている)みたいなパターンもあるから移植の時に都合が良い方に合わせる方が良いよね。ちゃんと検討した履歴が残るなら。
4
_ @readonly6582 2022年2月13日
まぁ、バグ直すんでしたら別に工数は頂かなぁやれませんわなぁ
6
えーし @A__shi 2022年2月13日
「直したければ "直した旧" をまず持ってこい」になるやつ
5
trycatch777 @trycatch777 2022年2月13日
「直さないことは絶対ない」というわけではない。ケースバイケース。プログラムを直して、移行時にデータを修正する場合もある。
15
代​理​ち​ゃ​ん @surrogatepair 2022年2月13日
ExcelにもLotus1-2-3との互換性の関係でわざわざバグが仕込まれてるという……(1900年2月29日という存在しない日が存在するバグ)
8
くろねこ @kazuaka1234 2022年2月13日
VB→.NETへ移行した時もそうでした。 ただ勝手にそう判断したわけではなく、顧客ともその旨合意をとっています。 また、見つけたバグや改善した方が良さそうな点は全て資料にまとめて報告、必要な箇所は別料金で対応としました。
11
まっきち @mackichi 2022年2月13日
それなんてバタフライエフェクト
0
飛達磨 @tobidaruma 2022年2月13日
Sakura87_net さいでんなー♪ ほーでんなー♪
2
さとうあきひろ @akihirosato1975 2022年2月14日
surrogatepair 伝説の「1901年から計算する」オプションはそれのために存在してたんでしたっけ
4
佐渡丸樹 @sademarquis1 2022年2月14日
「旧システムと同じ結果を出すこと」という仕様なら当然では。旧システムではバグだったとしても新システムではそれは仕様だ。
21
aqp1 @aqp114 2022年2月14日
普通に客に確認しろよ。
0
鼻毛山 @yamadataro25252 2022年2月14日
ファミコンのエミュレーター実装時にファミコンのバグを直したら、バグを利用してたFF2が移植できなくなったという話
1
volshichi @volshichi 2022年2月14日
昔アーケードゲームから家庭用への移植でコレあったなあ
3
サクラアイル🐉 @sakura_aisle 2022年2月14日
これわかる。旧環境側でそのバグの原因解析を担当したんだけど、解析する理由が「新環境側で同じバグを再現するため」だった。当時は「えぇ…」と思ったけど、今考えるとまあそれが正解だったんだなと思う。
1
まーくんZ/FF11Retysia@ラグ鯖 @machan43 2022年2月14日
これ顧客側がシステムの正しくあるべき姿を実はわかってないって証左ですよね。
0
もうたぽ @moutapo 2022年2月14日
ゲームはバグありきの戦法が前提になってたりするので、移植時には忠実にバグを再現するために気を使ってるんだろうなぁ。ストIIの「打撃数で真空波動が全弾ヒットするか決まる」なんていうバグは、弱キャラ・ケンの強キャラ・リュウに対する少ない反撃チャンス、なんていうこともあるし
0
キャンプ中毒のドライさん(Drydog(乾)) @drydog_jp 2022年2月14日
電気のプラスマイナスも未だに直せないからなぁ
2
富士山麓ωナックル @Mqzer9ltQN2nxiE 2022年2月14日
あるモノは全部引っ越しさせて、引っ越し先での取捨選択はまた別の人の仕事だよね。
1
太田拓也 @ef510df200 2022年2月14日
Windowsの新バージョンで使えなくなる周辺機器やアプリが出てくるのもバグだろ、おい聞いてるのかマイクロソフト!
0
だっしゅ @mumerexe 2022年2月14日
関係ありそうで関係ない話だけど、ゲームの移植、リメイクとかでプレイヤーが有利になるバグだけが残ってたりすることがあるね(TOD2の称号バグとか)
0
ettolrahc @ettolrahc2015 2022年2月15日
旧システムがそれで正しく運用できていたというなら、それはバグではなく仕様なんよ(白目
1
⛩️ の​ー​み​ん丁 ⛩️ @nouminT 2022年2月15日
例えば旧システムで出ていたバグに対応する形で動いている別のシステムが隠されているケースを考えると分かりやすい。バグ含め同じ結果を出すようにすれば問題ないが、直してしまうとそこで不整合が生じ、場合によっては重大アクシデントになる。
1
ISSY @issy1080 2022年2月15日
セキュリティホールとかの致命的なバグならともかく、初期仕様的にはバグだけど問題視されずに安定運用してたものは仕様の一部と考えた方がいいと思う。安定運用第一でっせ。
1
佐渡丸樹 @sademarquis1 2022年2月15日
この手の話では、初代ストIIの「必殺技による通常技キャンセル」がもともとはバグだったという事例が有名かな。
3
布団王『白子』 @WBmfmf 2022年2月15日
一見不誠実なようだが問題はそれほど単純ではなく、下手に直すと別な問題が発生した歴史を知っていれば安易にそのようなことを言えないわけだ。やるなら別途に修正による波及箇所の検証を別環境で行った上で実行しないと。慎重さを求められない単純なものであれば、バグ修正ありきのマイグレになるはず
0
うさこ丸 @usakomaru08 2022年2月15日
「バグでは無く仕様です」ってつまりこういうことなんやな
0