Oracle Databaseコードの狂気と成功

今週、Hacker Newsユーザーは、「あなたが見た悪い-しかし、まだ動作しているコードの最大量は？ 」という質問について議論することにしました（後のRedditユーザーも参加しました ）。 コメントでは、私たちが時々出くわすものについて多くの「面白い」物語が語られました。 しかし、「ほとんどのFortune 100企業で使用されている高度なDBMS」コードに関する話が最も注目を集めました。



Lovecraft Horrorノミネートの勝者は、バージョン12.2の開発中にOracle Databaseで働いていた元Oracle開発者の話に値します 。 当時のDBMSコードベースのボリュームはCで2500万行でした。これらの行の1つだけを変更すると、以前に作成された何千ものテストが中断しました。



長年にわたり、厳しい締め切りを定期的に追求してきた数世代のプログラマーがコードの処理に成功しました。これにより、コードは真の悪夢に変わる可能性がありました。 今日では、ロジック、メモリ管理、コンテキストスイッチングなどを担当する複雑な「断片」コードで構成されています。 それらは数千の異なるフラグを使用して互いに接続されています。 すべてのコードは、ノートブックに頼らずに解読できない神秘的なマクロによって相互接続されています。ノートブックでは、マクロの関連部分が何をするかを書き留める必要があります。 その結果、開発者はマクロが実際に何をするのかを把握するために1〜2日かかることがあります。



特定のケースでコードの動作を予測するには、20（または100）のフラグが持つ可能性のある値と結果を理解し、覚えておく必要があります。 状況は、さまざまな開発者が独自のタイプを使用したという事実によって悪化しますが、これは本質的に同じもの（たとえば、int32）であり、誰もそのようなレガシーに敢えて触れることはほとんどありません（確かにそうであると言えます） Oracle 8iコードベース）。



問題が発生します。これだけで、Oracle Databaseはどのように立ち続けられるのでしょうか。 その秘密は何百万ものテストにあります。 完全な実装には20〜30時間かかります（同時に、100〜200台のサーバーのテストクラスターに分散して実行されます）。



90年代後半にこの製品に取り組み、TDD（テスト駆動開発）のアイデアを固守したチームは、次の意見がありました。「自動テストとは、理解できるコードを書く必要がないことです。代わりに、テストを考えます。」 将来、開発者は彼らが定めた原則を順守することを余儀なくされ、今では、このアイデアが長期的にどのようなものになったかを実際に目撃しています-長所と短所があります。



今日、Oracle Databaseの新しいバグを修正するプロセスには、数週間から数か月かかります。 最初は、開発者は必要なフラグを整理するだけで数日を費やさなければならず（その不思議な相互作用によりバグが発生します）、その後、しばしばバグを引き起こした特定のスクリプトの処理を担当する独自のフラグを追加する必要があります。



その後、テスト用のコードを送信し、翌日、静かに別のタスクに切り替えて、テストクラスターが新しいOracle DBアセンブリをアセンブルし、すべてのテストを実行するのを待ちます。 開発者が幸運であれば、約100のテストが「赤面」します。 そうでない場合（およびこのオプションがより頻繁に発生する場合）-約1000。既存のコードの操作に関する彼の仮定のどれが間違っていることが判明したかを確認する必要があります。 彼は、彼が変更したコードの作業に自明な形で参加した、数十の異なるフラグを研究する必要があることに気付く可能性は十分にあります。



彼は運が最終的に彼に微笑んで、すべてのテストが最終的に合格するまで、数週間このプロセスを繰り返す必要があります。 その後、彼自身が数十のテストを作成する必要があります-将来コードを邪魔する開発者が「修正」を破らないようにするためです。 その後、改善はレビューに送られます。レビューには数週間から数か月かかることがあります。その後、バグは最終的にメインの作業ブランチにマージされます。



DBMSの構築とテストの実行には少なくとも1日かかるため、各開発者は2〜3個のバグを同時に処理し、テスト結果を待っている間にそれらを切り替えます。



DBMSに新しい機能を追加する開発者の方が簡単だと思っているなら、あなたは無駄です。 新しい認証モードなどの小さな新機能を追加する場合でも、6か月から1年、特に高度な場合では最大2年かかります。



説明したケースでは、TDDを使用すると、「スパゲッティ」コードを崩すことができません。このコードでは、何かを理解するのがすでに非常に難しく、出力に動作する製品があります。 同時に、コストは増大し続けており、新しいコードの品質は多くの場合、望まれるものを残しています。 米国の開発者チームだけでなく、インドのチームもDBMSに取り組んでいるため、確立された伝統によると、一部のOracle開発者はコードの品質を非難しています。 他の人はそれらに同意せず、変更ログに基づいて、コードの品質はチームの地理に依存せず、悪いコードは両方のチームから定期的に「飛ぶ」と言います。 製品にとって本当に深刻な問題は、プロジェクトを「業界に参入する」と認識し、1〜2年以内にDBMSに取り組んでいる開発者です。 この間、プロジェクトの複雑さを大幅に理解することは不可能です。



90年代後半にOracle 8iコードベースをUnixバージョンの1つに移植していた別の開発者によると、その当時のコードは「スパゲッティ」のボールであり、完全に理解することはまったく不可能でした。 80年代後半にDBMSコードを使用した別の開発者は、コードベースは膨大なCソースとアセンブリ用のメイクファイルのセットであり、その多くはカーネルコード自体よりもはるかに複雑だったと主張しています。 もちろん、現実的であることは価値があります。数十年にわたって開発されてきた業界のリーダーである同様の製品で状況が良くなることはまずありません。