私の職業人生のほとんどで、プロトコルバッファの使用に反対しています。 それらはアマチュアによって明確に書かれており、非常に専門性が高く、多くの落とし穴に苦しみ、コンパイルするのが難しく、Google以外の誰も実際に抱えていない問題を解決します。 プロトバッファのこれらの問題がシリアル化の抽象化の検疫に残っていれば、私の苦情はそこで終わります。 しかし、残念なことに、Protobuffersの貧弱な設計は非常に邪魔なため、これらの問題がコードに漏れることがあります。



アマチュアによる狭い専門化と開発



やめて メールクライアントを閉じます。「世界で最も優れたエンジニアはGoogleで働いています」、「その開発は定義上、アマチュアによって作成することはできません」という手紙を既に書いています。 私はそれを聞きたくありません。



このトピックについては説明しません。 完全な開示：私は以前Googleで働いていました。 これは、私がProtobuffersを使用した最初の（しかし、残念ながら最後ではない）場所でした。 話したい問題はすべてGoogleコードベースに存在します。 「プロトバッファの誤用」などだけではありません。



Protobuffersの最大の問題は、ひどい型システムです。 Javaファンはここでくつろいでいるはずですが、残念ながら文字通り、誰もJavaが適切に設計された型システムであるとは考えていません。 動的型付けキャンプの人たちは不必要な制限について不満を述べていますが、静的型付けキャンプの代表者たちは、私のような不必要な制限と、型システムに本当に必要なものすべての欠如について不満を言っています。 どちらの場合も負け。



アマチュアによる狭い専門化と開発は密接に関連しています。 仕様の多くは、最後の瞬間にボルトで固定されているように見えた-そして最後の瞬間に明らかにボルトで固定された。 いくつかの制限は、あなたを止めさせ、頭を掻き、「一体何だ？」と尋ねさせます。しかし、これらはより深い問題の症状です。



明らかに、プロトバッファはアマチュアによって作成されます。これは、よく知られた既に解決済みの問題に対する貧弱なソリューションを提供するためです。

構成の欠如

プロトバッファーは、互いに機能しないいくつかの機能を提供します。 たとえば、直交のリストを見てください。同時に、ドキュメントで見つけたタイピング機能が制限されています。

• フィールドの1つをrepeated
  
  
  
  ことはできません。
• フィールドmap<k,v>
  
  
  
  はキーと値の特別な構文がありますが、他のタイプでは使用されません。
• map
  
  
  
  フィールドはパラメーター化できますが、ユーザー定義タイプは使用できなくなりました。 これは、一般的なデータ構造で独自の専門化を手動で指定することに固執していることを意味します。
• map
  
  
  
  フィールドをrepeated
  
  
  
  ことはできません。
• map
  
  
  
  キーは string
  
  
  
  にすることができ bytes
  
  
  
  が、 bytes
  
  
  
  することはでき ません 。 Enumも禁止されていますが、後者はProtobuffers仕様の他のすべての部分の整数と同等と見なされます。
• map
  
  
  
  値を他のmap
  
  
  
  することはできません。

このクレイジーな制限のリストは、最後の瞬間に設計とねじ込み機能を無原則に選択した結果です。 たとえば、サイドタイプではなく、コードジェネレーターが相互に排他的なオプションフィールドを生成するため、 oneof



フィールドをrepeated



ことはできません。 このような変換は、特異なフィールドに対してのみ有効です（後で説明するように、それでも機能しません）。



repeated



ことのできないmap



フィールドの制限は、ほぼ同じオペラからのものですが、型システムの異なる制限を示しています。 舞台裏では、 map<k,v>



はrepeated Pair<k,v>



似たものに変換されます。 そして、 repeated



は言語の魔法のキーワードであり、通常の型ではないため、それ自体と結合しません。



enum



の問題についてのあなたの推測は、私のように真実です。



これらすべてについてとてもイライラしているのは、現代の型システムがどのように機能するかについての不十分な理解です。 この理解はProtobuffers の仕様を劇的に簡素化し、同時にすべての任意の制限を取り除くでしょう。



解決策は次のとおりです。

• required
  
  
  
  メッセージのすべてのフィールドを作成します。 これにより、各メッセージが製品タイプになります。
• oneof
  
  
  
  フィールドの値をスタンドアロンデータ型に上げます。 これは、連産品タイプになります。
• 製品のタイプと他のタイプの連産品のパラメーター化を有効にします。

以上です！ これらの3つの変更は、可能なデータを決定するために必要なすべてです。 このシンプルなシステムでは、他のすべてのProtobuffers仕様をやり直すことができます。



たとえば、 optional



フィールドをやり直すことができます。

 product Unit { // no fields } coproduct Optional<t> { t value = 0; Unit unset = 1; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

repeated



フィールドの作成も簡単です。

 coproduct List<t> { Unit empty = 0; Pair<t, List<t>> cons = 1; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、シリアル化の実際のロジックを使用すると、リンクリストをネットワーク経由でプッシュするよりも賢明なことができます。結局、 実装とセマンティクスは互いに対応する必要はありません 。

疑わしい選択

Javaスタイルのプロトバッファは、 スカラータイプとメッセージタイプを区別します。 スカラーは、ほぼint32



、 bool



、 string



などのマシンプリミティブに対応していstring



。 一方、メッセージタイプはすべて残りです。 すべてのライブラリおよびユーザータイプはメッセージです。



もちろん、2種類のタイプのセマンティクスはまったく異なります。



スカラー型のフィールドは常に存在します。 それらをインストールしなかった場合でも。 私はすでに言った（少なくともproto3 ^1で ）プロトバッファは、データがまったくない場合でもゼロに初期化されていますか？ スカラーフィールドは偽の値を取得します。たとえば、 uint32



0



に初期化され、 string



""



初期化されます。



デフォルト値が割り当てられているフィールドとプロトバッファにないフィールドを区別することはできません。 おそらく、この決定は、スカラーのデフォルトを転送しないように最適化のために行われたものです。 ドキュメントではこの最適化について言及していないため、これは単なる仮定です。したがって、あなたの仮定は私のものより悪くなることはありません。



Protobuffersの下位および将来のAPI互換性の理想的なソリューションの主張を議論するとき、未定義の値とデフォルトの値を区別できないことは悪夢であることがわかります。 特に、フィールド用に1ビット（設定するかどうか）を保存するという意識的な決定である場合。



この動作をメッセージタイプと比較します。 スカラーフィールドは「ダム」ですが、メッセージフィールドの動作は完全に狂っています。 内部的には、メッセージフィールドは存在するかしないかのどちらかですが、動作はおかしいです。 アクセサ用の小さな擬似コードは、千語に値します。 これをJavaまたは他の場所で想像してください。

 private Foo m_foo; public Foo foo { // only if `foo` is used as an expression get { if (m_foo != null) return m_foo; else return new Foo(); } // instead if `foo` is used as an lvalue mutable get { if (m_foo = null) m_foo = new Foo(); return m_foo; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

理論的には、 foo



フィールドが設定されていない場合、デフォルトで初期化されたコピーが表示されますが、それを尋ねるかどうかはわかりませんが、コンテナを変更することはできません。 しかし、 foo



を変更すると、その親も変更されます！ これは、未定義の値が何を意味するのかを理解するために、 Maybe Foo



タイプとそれに関連する「頭痛」の使用を避けるためです。



このような行動は、法律に違反するため、特に悪質です。 ジョブmsg.foo = msg.foo;



動作しません。 代わりに、実装は実際にmsg



をfoo



コピーに静かに変更しますmsg



が以前に存在していなかった場合は、ゼロで初期化します。



スカラーフィールドとは異なり、少なくともメッセージフィールドが設定されていないと判断できます。 プロトバッファの言語バインディングは、生成されたbool has_foo()



メソッドのようなものを提供します。 存在する場合、あるプロトバッファから別のプロトバッファにメッセージフィールドを頻繁にコピーする場合、次のコードを記述する必要があります。

 if (src.has_foo(src)) { dst.set_foo(src.foo()); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

少なくとも静的型付けの言語では、 foo()



、 set_foo()



およびhas_foo()



間の名目上の関係のため、このテンプレートを抽象化できないことに注意してください。 これらの関数はすべて独自の識別子であるため、プリプロセッサマクロを除き、プログラムで生成する手段はありません。

 #define COPY_IFF_SET(src, dst, field) \ if (src.has_##field(src)) { \ dst.set_##field(src.field()); \ }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（ただし、プリプロセッサマクロはGoogleスタイルガイドで禁止されています）。



代わりに、すべての追加フィールドがMaybe



として実装された場合、抽象化されたダイヤルピアを安全に配置できます。



主題を変えるために、別の疑わしい決定について話しましょう。 oneof



フィールドの1つを定義できますが、それらのセマンティクスは連産品のタイプに対応していません ！ 初心者間違いだよ！ 代わりに、各セッターのオプションフィールドとセッターのマジックコードを取得します。これは、設定されている場合、他のフィールドを元に戻すだけです。



一見、これは正しいタイプのユニオンと意味的に同等であるように思われます。 しかし、代わりに、うんざりするような言葉で表せないエラーの原因になります！ この動作が不正な実装と組み合わされた場合msg.foo = msg.foo;



、このような一見正常な割り当ては、任意の量のデータを静かに削除します！



その結果、これは、フィールドの1つoneof



法律を遵守するPrism



形成せず、メッセージが法律を遵守するLens



形成しないことを意味します。 バグなしで重要なプロトバッファ操作を記述しようとするあなたの幸運を祈ります。 protobuffersに、普遍的でエラーのない多態性コードを書くことは、文字通り不可能です 。



これは、特に正反対のことを約束するパラメトリック多型を愛する私たちにとっては、聞くのはあまり楽しいことではありません。

下位互換性と将来の互換性

Protobuffersでよく言われる「キラー機能」の1つは、「下位互換性と上位互換性のあるAPIを作成するためのトラブルのない機能」です。 この声明は真実を曖昧にするためにあなたの目の前に掛けられました。



そのprotobuffersは寛容です。 彼らは、あなたのデータがどのように見えるかについて全く約束しないので、過去または未来からのメッセージに対処することができます。 すべてがオプションです！ しかし、それが必要な場合、Protobuffersは、それが理にかなっているかどうかに関係なく、タイプチェックで何かを準備し、あなたに喜んで提供します。



これは、Protobuffersが約束された「タイムトラベル」を実行し、 デフォルトで静かに間違ったことを実行することを意味します 。 もちろん、慎重なプログラマーは、受け取ったプロトバッファーの正確さをチェックするコードを書くことができます（そしてそうすべきです）。 しかし、すべてのサイトで保護の正当性チェックを記述した場合、逆シリアル化手順が許容範囲を超えていたことを意味しているだけかもしれません。 検証のロジックを明確に定義された境界から分散させ、コードベース全体にスマッジするだけでした。



考えられる引数の1つは、protobuffersがメッセージで理解できない情報を保存することです。 これは、原則として、このバージョンのスキームを理解していない仲介者を介したメッセージの非破壊的な送信を意味します。 これは明らかな勝利ですよね？



もちろん、紙の上ではこれは素晴らしい機能です。 しかし、このプロパティが実際に保存されているアプリケーションを見たことはありません。 ルーティングソフトウェアを除き、プログラムはメッセージの特定のビットのみをチェックし、変更せずに転送することを望みません。 プロトバッファ上のプログラムの大部分は、メッセージをデコードし、別のメッセージに変換して、別の場所に送信します。 残念ながら、これらの変換は注文に応じて行われ、手動でエンコードされます。 また、あるプロトバッファから別のプロトバッファへの手動変換では、文字通り意味がないため、未知のフィールドは保持されません。



普遍的に互換性があるプロトバッファに対するこの遍在的な態度は、他の見苦しい方法で現れます。 Protobuffersのスタイルガイドは、DRYに積極的に反対し、可能な限りコードに定義を埋め込むことを提案しています。 彼らは、これにより、定義が異なる場合、将来的に別のメッセージを使用できるようになると主張しています。 私は、 万が一のために 、良いプログラミングの60年の実践を放棄することを申し出ていることを強調します。突然、将来、何かを変更する必要があります。



問題の根本は、Googleがデータの意味とその物理的表現を組み合わせていることです。 Google規模の場合、それは理にかなっています。 最終的には、ネットワークを使用したプログラマの時間給、Xバイトを保存するコストなどを比較する内部ツールがあります。 ほとんどのテクノロジー企業とは異なり、プログラマーの給与はGoogleの最小の費用項目の1つです。 財政的には、プログラマーが数バイトを節約するために時間を費やすことは理にかなっています。



大手テクノロジー企業5社に加えて、Googleの5桁以内にいる人は誰もいません。 スタートアップは、エンジニアリング時間を費やしてバイトを節約する余裕はありません 。 しかし、プロセスのバイト数を節約し、プログラマーの時間を浪費することは、Protobuffersがまさに最適化されているものです。



それに直面しましょう。 Googleの規模に適合しないため、適合しません。 「Googleが使用している」という理由だけでなく、「これらは業界のベストプラクティスである」という理由だけで、テクノロジーのカーゴカルトの使用をやめます。

Protobuffersはコードベースを汚染します

Protobuffersの使用をネットワークのみに制限することが可能であれば、このテクノロジーについてそれほど厳しくは語りません。 残念ながら、原則としていくつかのソリューションがありますが、実際のソフトウェアで実際に使用するのに十分なソリューションはありません。



プロトバッファは、通信チャネルを介して送信するデータに対応しています。 多くの場合、アプリケーションが実際に使用したい実際のデータと一致していますが、 同一ではありません。 これにより、私たちは不快な立場に置かれます。次の3つの悪いオプションのいずれかを選択する必要があります。

1. 本当に必要なデータを記述する別のタイプを維持し、両方のタイプが同時にサポートされるようにします。
2. アプリケーションが送信および使用するための形式で完全なデータをパックします。
3. 送信するために短い形式から必要なたびに完全なデータを取得します。

オプション1は明らかに「正しい」ソリューションですが、Protobuffersには適していません。 この言語は、2つの形式で二重に機能するタイプをエンコードするほど強力ではありません。 つまり、完全に独立したデータ型を記述し、Protobuffersと同期して開発し、 具体的にはそれらのシリアル化コードを記述する必要があります 。 ただし、ほとんどの人はProtobuffersを使用してシリアル化コードを記述しないように見えるため、このオプションは明らかに実装されていません。



代わりに、プロトバッファーを使用するコードにより、コードベース全体にプロトバッファーを配布できます。 それは現実です。 Googleでの私の主なプロジェクトは、1つのバリエーションのProtobuffersで記述された「プログラム」を受け取り、別のバリエーションで同等の「プログラム」を作成するコンパイラーでした。 入力形式と出力形式はまったく異なっていたため、C ++の正しい並列バージョンは機能しませんでした。 その結果、Protobuffersデータ（および生成されたコード）が非常に難しく、興味深い処理を行うことができなかったため、私のコードではリッチコンパイラーの記述手法を使用できませんでした。



その結果、50行の再帰スキームではなく、10,000行の特別なバッファシャッフルが使用されました。 私が書きたかったコードは、プロトバッファでは文字通り不可能でした。



これは1つのケースですが、一意ではありません。 コード生成の厳しい性質により、言語のプロトバッファの症状は決して慣用的ではなく、コードジェネレータを書き直さない限りそうすることはできません。



しかし、それでも、ターゲット言語に安っぽい型システムを埋め込む問題はまだあります。 Protobuffersのほとんどの機能は十分に考慮されていないため、これらの疑わしいプロパティはコードベースに漏れます。 これは、実装するだけでなく、Protobuffersとやり取りしたいプロジェクトでこれらの悪いアイデアを使用せざるを得ないことを意味します。



堅実な基盤では、意味のないことを実現するのは簡単ですが、別の方向に進むと、せいぜい困難に直面し、最悪の場合、本当の古代の恐怖に遭遇します。



一般に、プロジェクトにProtobuffersを実装する人には希望をあきらめます。

---

1.今日まで、proto2と、フィールドをrequired



としてマークするrequired



があるかどうかについて、Googleで激しい議論がrequired



ます。 マニフェスト「 optional



は有害と見なされoptional



」 と 「 required



有害と見なされます」が同時に配布されます。 頑張ってください。 ↑