これまで見た中で最悪の Bad Code は何ですか？

 (news.ycombinator.com)
21 ポイント 投稿者 xguru 2020-09-21 | 8件のコメント | WhatsAppで共有

"2500万行の Oracle Database 12.2 のコードです"

HN に投稿された質問に、元 Oracle 勤務者が残した回答。

"想像を絶する恐怖です。既存の 1000 個のテストを通さない限り、1 行のコードも書けません。

手でノートに書き出して解かないと分からない謎めいたマクロがあって、マクロの機能を実際に理解するのに 1 日から 2 日ほどかかります。

時には、コードが異なる状況でどう動くかを予測するために、20 種類のフラグの値と効果を理解しなければなりません。

たまに 100 個を超えることもあります。誇張ではありません。

この製品がいまだに生き残って動いている唯一の理由は、文字どおり数百万のテストがあるからです。"

Oracle DB 開発者の人生。

  1. 新しいバグ対応を開始

  2. このバグを引き起こしている、謎めいた方法で相互作用する 20 個の異なるフラグを理解するのに 2 週間かかる

  3. 新しい特殊シナリオに対応するため、フラグを 1 つ追加。このフラグをチェックするためのコードを数行書き、問題状況を解決してバグを防ぐためのコードを数行追加

  4. コード変更を、100～200 台で構成されたテストファームにサブミット。すると新しい Oracle DB をビルドし、数百万のテストを分散実行

  5. 帰宅。翌日来て別の作業を開始。テスト完了には 20～30 時間必要

  6. 帰宅。翌日来てテスト結果を確認。良い日なら失敗したテストが 100 個くらい。悪い日なら 1000 個くらい失敗。このテストのうちいくつかを選んで、自分の仮定のどこが間違っていたかを調べる。おそらく、バグの本質を知るために考慮すべきフラグがさらに 10 個ほどあるはず

  7. このイシューを解決するためにフラグをいくつか追加。再び変更をテストファームにサブミット。また 20～30 時間待つ

  8. 2 週間にわたり、このフラグの組み合わせが正しく動くように修正と反復を続ける

  9. ついに「ある良き日」に、すべてのテストが失敗しなくなる

  10. 自分が行った変更について 100 個以上のテストを追加し、運の悪い次の開発者がこの修正を壊せないようにする

  11. 最終テストのために再度サブミット。そしてレビューのためにサブミット。レビューにはさらに 2 週間から 2 か月ほどかかることがあるので、別のバグに移って作業開始

  12. 2 週間から 2 か月後、すべてが終わるとコードがメインブランチにマージされる

これがバグを修正する Oracle プログラマーの人生です。誇張ではありません。

では、新機能を開発することがどれほどの恐怖か想像してみてください。

小さな機能を 1 つ開発するのに 6 か月から 1 年、時には 2 年までかかります。（Active Directory 認証のような新しい認証を追加する場合など）

この製品が動いていること自体が奇跡です。

私はもう Oracle では働いておらず、二度と Oracle で働くことはないでしょう。

関連記事

8件のコメント

 
neocoin 2020-09-28

今まで見た中で、いちばんひどい Bad Code は何ですか？

Test Cycle は

  1. Write Code

  2. Write Test

  3. Refactor Code , go to 1

ですが、1 と 2 に時間がかかりすぎるため、3 が継続的に抜け落ちてしまった結果の積み重ねですね。
 
kunggom 2020-09-21

ここで改めて見直すマーティン・ファウラーの講演。Oracle Database は「内部品質」(Internal Quality) があまり良くないようですね。

https://ja.news.hada.io/topic?id=2752
 
kbumsik 2020-09-21

まあ、Oracle の立場からすると何か当然に見えるし、むしろそのソフトウェアはやはりエンタープライズ向けなんだな……と思えるくらいには信頼感がありますね。

でも、あの文章のように、そこで働きたいとは思いませんね。
 
exitmusic 2020-09-21

むしろ、テスト中心の開発文化のせいで開発プロセスが壊れてしまったのではないか、という気がします。

どんなやり方でもテストさえ通ればいい、という形で開発が進められていて……おそらくああいう環境では、リファクタリングなんて夢のまた夢でしょうね。
 
sduck4 2020-09-22

問題はテストというより、機能の修正・追加のために20〜100個のフラグを考慮しなければならないようにした設計上の問題のほうが大きいのではないでしょうか？

DBMSの複雑さのせいで、やむを得ない面もありそうですが。
 
kunggom 2020-09-21

テストも結局は開発者が書くコードですからね。思い出したついでに、テストに関する文章をひとつ紹介しました。

https://ja.news.hada.io/topic?id=2883
 
ffdd270 2020-09-21

プロジェクトがあの程度でなければ、テストがインターフェースを大きく書き換えても以前と同じであることを継続的に保証してくれるので、むしろリファクタリングする勇気が湧く気がします。最近、私が作っているエミュレーターで、パラメータを BYTE 値から Enum 値へ大きく変更する作業をしたのですが、ビルドは成功するのにテストは失敗して、テストがなかったらどうなっていただろうと、一度ひやりとしたことがありました。

あの程度のコードベースだと、リファクタリングしようか……と悩んでも巨大すぎて諦めることになり、コードはさらに積み上がっていき……たぶん、そういう無限ループに陥っているのではないかと慎重に推測しています。
 
xguru 2020-09-21

あの方が大変だったのも理解できますが、

逆説的に「テストはこれほど重要なのだな」と考えさせられる文章だったので、訳してみました。

この回答の元の質問投稿には、全部で578件の返信が付いています。

Ask HN: What's the largest amount of bad code you have ever seen work?

https://news.ycombinator.com/item?id=18442637

1レベルの返信を見るだけでも面白いです。人の営みはどこも同じだな、という気がします..