# 利便性の代償{#the-cost-of-convenience}」。 ** 小規模なプロジェクトから大規模なプロジェクトまで、**が使用できるコードエディタを設計することは、難しい課題である。多くのツールは、ソリューションを階層化し、拡張性を提供することでこの問題にアプローチしている。一番下のレイヤーは非常に低レベルで基本的なビルドシステムに近く、一番上のレイヤーは高レベルの抽象化で、使うには便利だが柔軟性は低い。そうすることで、彼らは単純なことを簡単にし、それ以外のすべてを可能にするのだ。 しかし、**[Apple](https://www.apple.com)は、Xcode** で異なるアプローチを取ることにした。理由は不明だが、大規模プロジェクトの課題に最適化することが彼らの目標ではなかったのだろう。小規模プロジェクト向けの利便性に過剰投資し、柔軟性をほとんど提供せず、ツールを基盤となるビルドシステムと強く結合させた。利便性を実現するために、簡単に置き換えることができる賢明なデフォルトを提供し、多くの暗黙のビルド時間解決動作を追加した。 ## 明示性と規模 {#explicitness-and-scale}. 大規模で作業する場合、**Explicitness が鍵となる** 。それはビルドシステムが前もってプロジェクトの構造と依存関係を分析し理解し、そうでなければ不可能な最適化を実行することを可能にします。SwiftUIのプレビュー](https://developer.apple.com/documentation/swiftui/previews-in-xcode)や[Swiftマクロ](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/macros/)のようなエディタ機能が確実に予測通りに動作することを保証する上でも、同じような明確さが鍵となります。XcodeとXcodeプロジェクトは、Swiftパッケージマネージャが継承している原則である利便性を達成するための有効な設計上の選択として、暗黙の了解を受け入れているため、Xcodeを使用することの難しさは、Swiftパッケージマネージャにも存在します。 トゥイストの役割 Tuistの役割を要約すると、暗黙的に定義されたプロジェクトを防ぎ、より良い開発者体験（検証や最適化など）を提供するために明示性を活用するツールである。Bazel](https://bazel.build)のようなツールは、これをビルドシステムレベルにまで落とし込むことでさらに進化させている。 ::: これはコミュニティでほとんど議論されていない問題だが、重要な問題だ。Tuistに取り組んでいる間、私たちは多くの組織や開発者が、彼らが直面している現在の課題は[Swift Package Manager](https://www.swift.org/documentation/package-manager/)によって解決されるだろうと考えていることに気づきましたが、彼らが気づいていないのは、それが同じ原則に基づいて構築されているため、非常によく知られているGitの競合を緩和するとしても、他の分野では開発者の経験を低下させ、プロジェクトを最適化できないものにし続けるということです。 以下のセクションでは、どのように暗黙の了解が開発者の経験とプロジェクトの健全性に影響を与えるかのいくつかの実例について説明します。リストは網羅的ではありませんが、Xcode プロジェクトや Swift パッケージで作業するときに直面するかもしれない課題の良いアイデアを与えるはずです。 ## 便利さが邪魔をする{#convenience-getting-in-your-way}」。 ### 共有構築済み製品ディレクトリ {#shared-built-products-directory}。 Xcode は、各製品の派生データディレクトリ内のディレクトリを使用します。その中には、コンパイルされたバイナリ、dSYM ファイル、ログなどのビルドアーティファクトが格納されます。プロジェクトの全製品が同じディレクトリに入り、デフォルトで他のターゲットからリンクすることができるため、**、暗黙のうちに互いに依存しているターゲットが存在することになるかもしれません。** ターゲットが少数であれば問題にならないかもしれませんが、プロジェクトが大きくなると、デバッグしにくいビルドの失敗という形で現れるかもしれません。 この設計上の決断の結果、多くのプロジェクトが誤って定義が不十分なグラフでコンパイルしてしまう。 > [!TIP] > **インプリシット・ディペンデンスのtuist検出** > > Tuistは暗黙の依存関係を検出するためのコマンドを提供します。このコマンドを使えば、すべての依存関係が明示的であることをCIで検証できる。 ### スキーム内の暗黙の依存関係を見つける {#find-implicit-dependencies-in-schemes}. Xcodeでの依存関係グラフの定義と維持は、プロジェクトが大きくなるにつれて難しくなります。それは、ビルドフェーズとビルド設定として、`.pbxproj` ファイルでコード化されているため、グラフを視覚化して作業するツールがなく、グラフの変更（例えば、新しい動的なプリコンパイルされたフレームワークを追加する）には、上流での設定の変更（例えば、フレームワークをバンドルにコピーするために新しいビルドフェーズを追加する）が必要になるかもしれないからです。 アップルはある時点で、グラフモデルをより管理しやすいものに進化させる代わりに、ビルド時に暗黙の依存関係を解決するオプションを追加する方が理にかなっていると判断した。なぜなら、ビルド時間が遅くなったり、ビルドが予測不能になったりするからだ。例えば、[singleton](https://en.wikipedia.org/wiki/Singleton_pattern)として動作するderiveデータの状態があるため、ビルドはローカルではパスするかもしれないが、CIでは状態が異なるためコンパイルに失敗するかもしれない。 > [!TIP] > プロジェクトのスキームでこれを無効にし、依存関係グラフの管理を容易にするTuistのようなものを使うことをお勧めする。 ### SwiftUIのプレビューと静的ライブラリ/フレームワーク {#swiftui-previews-and-static-librariesframeworks}. SwiftUIプレビューやSwiftマクロのようないくつかのエディター機能は、編集されているファイルからの依存関係グラフのコンパイルを必要とします。エディター間のこの統合は、ビルドシステムが暗黙性を解決し、これらの機能が動作するために必要な正しい成果物を出力することを必要とします。ご想像の通り、**グラフが暗黙的であればあるほど、ビルドシステム** にとってはより困難なタスクとなります。したがって、これらの機能の多くが確実に動作しないことは驚くことではありません。開発者から、SwiftUIのプレビューは信頼性が低すぎるため、かなり前に使うのをやめたという話をよく聞きます。その代わりに、彼らはサンプルアプリを使うか、静的ライブラリの使用やスクリプトのビルドフェーズのような特定のことを避けています。 ### マージ可能なライブラリ {#mergeable-libraries}. ダイナミック・フレームワークは、より柔軟で扱いやすい反面、アプリの起動時間に悪影響を及ぼす。一方、スタティック・ライブラリは起動が速いものの、コンパイルに時間がかかり、特に複雑なグラフ・シナリオでは少し扱いにくい。*コンフィギュレーションによって、どちらか一方に変更できれば素晴らしいと思いませんか？* アップルがマージ可能なライブラリに取り組むことを決めたとき、そう考えたに違いない。しかしまたしても、彼らはビルド時の推論をビルド時に移してしまった。依存グラフについて推論するなら、ターゲットの静的または動的な性質が、いくつかのターゲットのいくつかのビルド設定に基づいてビルド時に解決されるときに、そうしなければならないことを想像してほしい。SwiftUIのプレビューのような機能が壊れないことを保証しながら、確実に動作するように頑張ってください。 **多くのユーザーがマージ可能なライブラリを使いたいとTuistにやってきますが、私たちの答えはいつも同じです。その必要はありません。** 生成時にターゲットの静的または動的な性質を制御することができ、コンパイル前にグラフが既知のプロジェクトにつながります。ビルド時に変数を解決する必要はない。 ```bash # The value of TUIST_DYNAMIC can be read from the project {#the-value-of-tuist_dynamic-can-be-read-from-the-project} # to set the product as static or dynamic based on the value. {#to-set-the-product-as-static-or-dynamic-based-on-the-value} TUIST_DYNAMIC=1 tuist generate ``` ## 明示的、明示的、明示的{#explicit-explicit-and-explicit}。 Xcodeを使った開発をスケールさせたいと考えているすべての開発者や組織に推奨する、文章以外の重要な原則があるとすれば、それはexplicitnessを受け入れるべきだということです。そして、もしエクスプリシットネスが生のXcodeプロジェクトで管理するのが難しいのであれば、[Tuist](https://tuist.io)か[Bazel](https://bazel.build)のどちらか他のものを検討すべきである。**そうして初めて、信頼性、予測可能性、最適化が可能になる。** ## 未来 アップルが上記の問題すべてを防ぐために何かをするかどうかは未知数だ。XcodeとSwiftパッケージマネージャに組み込まれた彼らの継続的な決定は、彼らがそうすることを示唆していない。一度、暗黙的な設定を有効な状態として許可してしまうと、**、そこから破壊的な変更を導入することなく移動することは難しい。** 最初の原則に戻り、ツールの設計を再考することは、何年も偶然にコンパイルされた多くのXcodeプロジェクトを壊すことにつながるかもしれない。もしそうなったら、コミュニティは大騒ぎになるだろう。 アップルは鶏と卵の問題に直面している。利便性こそが、デベロッパーが素早く開発に取り掛かり、エコシステムのためにより多くのアプリを開発するのに役立つ。しかし、その規模での体験を便利にするという決断が、Xcodeの機能のいくつかを確実に動作させることを難しくしている。 将来は未知であるため、私たちは**業界標準と Xcode プロジェクト** にできる限り近づけるように努めています。私たちは、上記の問題を防ぎ、より良い開発者体験を提供するために持っている知識を活用します。理想的には、そのためにプロジェクト生成に頼る必要はありませんが、XcodeとSwiftパッケージマネージャの拡張性の欠如は、それが唯一の実行可能な選択肢になります。また、Tuistプロジェクトを壊すためにXcodeプロジェクトを壊さなければならないので、安全な選択肢でもある。 理想を言えば、**ビルド・システムがより拡張可能であること** 、しかし、暗黙の世界と契約するプラグイン／エクステンションを持つことは悪い考えではないだろうか？良いアイデアとは思えない。というわけで、より良い開発者体験を提供するためには、Tuistや[Bazel](https://bazel.build)のような外部ツールが必要になりそうだ。あるいはAppleが私たちを驚かせて、Xcodeをより拡張可能で明示的なものにするかもしれない...。 それが実現するまでは、Xcodeを受け入れ、それに伴う負債を背負うか、より良い開発者体験を提供するために私たちを信頼するか、どちらかを選択しなければなりません。私たちはあなたを失望させません。