私はマルチプラットフォームアプリケーションがどのように開発されているのだろうかと思っていました。 MAC/Windows用のMicrosoft Office、MAC/Windows/Linux用のFireFoxなどのアプリケーションマルチプラットフォームアプリケーションの開発方法は？
異なるプラットフォーム用のコードを作成する必要がある場合は、管理が難しく、複雑な作業がたくさんあります。
Q：開発チームは、複数のプラットフォームの開発の複雑さをどのように管理しますか？
Microsoft Officeはマルチプラットフォームアプリケーションではありません。あなたがMac版を使ったことがあるなら、あなたは知っているだろう。最後のマルチプラットフォームバージョンのOfficeは、1998年に悪名をつけたOffice 6.0のようなものでした。何が起こったのか、ユーザーは見た目と感触に震え、「移植」の考え方を告発しました。
Mac版のOfficeは、異なるチームによって作成されただけでなく、まったく異なる部門によって書かれています.Macビジネスユニット（MacBUとも呼ばれます）。部門の異なるヘッド、異なるマネージャーと私は異なる販売とマーケティングの人々も信じています。
それはそれを行う方法の1つです。 Macユーザーの間で「正しい方法」としても知られています。
もちろん、誰もがMicrosoftの規模ではなく、Macユーザー（Linuxユーザーの数がはるかに少ない）をサポートするために完全に異なる子会社を作る余裕があります。それをやや正気なやり方で行うのは、wxWidgetsやQTやGTKのようなGUI用のクロスプラットフォームライブラリを使うことです。結局のところ、あなたのコアCコードのほとんどは、GUIやファイル管理のようなプロプライエタリなものだけで多くのプラットフォームを変更するつもりはありません。ちょっと、あなたはファイル管理とクロスプラットフォーム性のためのネットワークのPOSIX関数呼び出しに固執することさえできます。しかし、Macユーザーが（MS Office 6.0に起こったような）最終結果を嫌う可能性が高いことに注意してください。
第3の方法は途中です。共通のコアアプリケーションコードを独自のGUIのものとは別にしておいてください（メンテナンス性に関しては良い考えです）。 MVCデザインパターンはこれを行う良い方法です。 MVCフレームワークのViewコンポーネントとControllerコンポーネントを切り替える方法（#defineまたは別のビルドスクリプト/ makefileを使用）があります。これはGoogleがChromeで行うことです。 Mac版はネイティブのMacグラフィックスを使用し、Windows/Linux版はSkiaというグラフィックエンジンを使用します。 Chromeのコアは、WebKitとV8の両方がクロスプラットフォームです。
おそらく、これにはマルチプラットフォームアプリケーションほど多くのアプローチがあります。一般的に、彼らはいくつかの異なる戦略を煮詰めるます：
ポータブルランタイムでの言語使用 - より少ない程度、または無数異なる解釈スクリプト言語のいずれかに、例えば.NETをJavaの。
プラットフォームの違いを非表示にするには、クロスプラットフォームのツールキット（例：QT）を使用します。
さまざまなプラットフォームのコードベースを変更するには、CやC++などの言語で条件付きコンパイルを使用します。これは＃2と似ていますが、アプリ内に独自のクロスプラットフォームツールキットを構築している点が異なります。
あなたがコンパイルされたC++を話している場合は、コード内のいくつかの場所で#IFDEF WIN32のようないくつかの条件定義、で終わります。クロスプラットフォームコードを書くときは、クロスプラットフォームをテストする必要があります。チェックイン時にすべてのプラットフォームでコードをビルドできるHudsonのようなビルドシステムが役立ちます。
GUIの場合は、QTのような優れたクロスプラットフォームライブラリを使用することが非常に役立ちます。それは多かれ少なかれ同じ方法であなたのGUIコードを書くことができますが、それがコンパイルされているどのようなシステムにもネイティブ感を保ちます。
希望すると便利です。
マルチプラットフォームコードの主なアプローチは、マルチプラットフォームベースです。例えば、ブーストライブラリ（ファイルアクセス、スレッド同期プリミティブなど）を自由に使用するC++コードは、マルチプラットフォーム設定で動作します。同様に、.net（管理対象）コードを作成すると、.net実行時（Windowsの場合）またはMono（Linuxシステムの場合）によってクロスプラットフォーム機能が実現します。
これ以上の問題がありますが、これが最大です。他の問題には、C++の場合、GUIの処理方法が含まれます。 WxWidgetsやQtを使用するなど、クロスプラットフォームコードを使用する意図的な選択が再び重要です。
cross-platform buildプロセスを使用すると便利です。
1つの方法は、ハードウェア/オペレーティングシステムの抽象化レイヤーを作成することです。スタンダードCライブラリまたはターゲットとするプラットフォームに依存しない同等のコードを使用して、CまたはC++でアプリケーションを作成します。
OSやハードウェア固有のインターフェイス（ロード/保存ダイアログ、印刷、ツールバー、通知など）の場合は、アプリケーションで使用する汎用APIを作成し、各ターゲットプラットフォーム
ファイル形式やネットワークプロトコルを扱う場合、マルチバイト値をホストのバイトオーダー（ビッグエンディアンまたはリトルエンディアンの間で変換可能）と、エンディアンの間で変換するためのコードを組み込む必要があります。ファイル/ネットワークプロトコル。
Q：開発チームは、複数のプラットフォームの開発の複雑さをどのように管理しますか？
A：良い回帰テスト。
1つのアプローチは、プラットフォーム固有の機能ごとに別々のクラスを用意し、特定のプラットフォームに必要なすべてのクラスを一緒にコンパイルすることです。こうすることで、コードがより洗練され、不必要な抽象化も回避されます。ここでは例を示します"Upload XML data to MySQL or NoSQL" 青色はNoSQL用、ピンク色はSQL用、カーキ色は共通コード用、グレーは言語サポート用です。
何が質問ですか？ –