# 原則 {#principles}

このページでは、Tuistの設計と開発の柱となる原則について説明する。これらの原則はプロジェクトとともに進化し、プロジェクトの基盤に沿った持続可能な成長を保証するものである。

## 規約のデフォルト{#default-to-conventions}。

Tuistが存在する理由のひとつは、Xcodeが規約に弱く、それが複雑なプロジェクトにつながり、スケールアップやメンテナンスが難しいからである。そのため、Tuistはシンプルで徹底的に設計された規約をデフォルトとすることで、異なるアプローチをとっている。**開発者は規約からオプトアウトすることができるが、それは意識的な決断であり、自然には感じられない。**

例えば、提供されるパブリック・インターフェースを使用してターゲット間の依存関係を定義するための規約がある。そうすることで、Tuistは、リンクが機能するための正しい設定でプロジェクトが生成されることを保証する。開発者には、ビルド設定を通じて依存関係を定義するオプションがあるが、暗黙的にそれを行うことになるため、`tuist
graph` や`tuist cache` のような、いくつかの規約が守られていることに依存しているTuistの機能を壊してしまうことになる。

規約をデフォルトとする理由は、開発者に代わってより多くの決定を下すことができれば、開発者はより集中してアプリの機能を作ることができるからだ。多くのプロジェクトがそうであるように、規約がないままだと、他の決定と一貫性のない決定を下さなければならなくなり、その結果、管理しにくい偶発的な複雑さが生じることになる。

## マニフェストは真実の源{#manifests-are-the-source-of-truth}である。

何層ものコンフィギュレーションと、その間のコントラクトを持つことは、プロジェクトのセットアップを推論し、維持することを難しくする。平均的なプロジェクトについて少し考えてみよう。プロジェクトの定義は`.xcodeproj`
ディレクトリにあり、CLIはスクリプト（例えば`Fastfiles`
）にあり、CIロジックはパイプラインにある。これら3つのレイヤーの間には、維持しなければならない契約がある。*プロジェクトで何かを変更した後、1週間後にリリーススクリプトが壊れていることに気づいたという状況に、どれくらいの頻度で陥ったことがあるだろうか？*

マニフェストファイルという単一の真実のソースを持つことで、これを単純化することができます。これらのファイルは、開発者がファイルを編集するために使用できるXcodeプロジェクトを生成するために必要な情報をTuistに提供します。さらに、ローカルまたはCI環境からプロジェクトをビルドするための標準コマンドを持つことができます。

**Tuistは複雑さを所有し、シンプルで安全で楽しいインターフェイスを公開し、可能な限り明示的にプロジェクトを記述すべきである。**

## 暗黙の了解を明示的にする {#make-the-implicit-explicit}

Xcodeは暗黙的な設定をサポートしています。その良い例が、暗黙的に定義された依存関係を推測することです。暗黙的な設定は、構成が単純な小さなプロジェクトでは問題ありませんが、プロジェクトが大きくなるにつれて、遅さや奇妙な動作を引き起こすかもしれません。

Tuistは暗黙的なXcodeの動作に対して明示的なAPIを提供すべきである。また、Xcodeの暗黙的な定義もサポートすべきであるが、開発者が明示的なアプローチを選ぶように促すような方法で実装すべきである。Xcodeの暗黙性と複雑さをサポートすることで、Tuistの採用が促進され、その後チームは暗黙性を取り除くのに時間をかけることができる。

依存関係の定義はその良い例だ。開発者はビルド設定やフェーズを通じて依存関係を定義できるが、Tuistはその採用を促す美しいAPIを提供している。

**APIを明示的に設計することで、Tuistは、そうでなければ不可能ないくつかのチェックや最適化をプロジェクト上で実行することができる。**
さらに、依存関係グラフの表現をエクスポートする`tuist graph` や、すべてのターゲットをバイナリとしてキャッシュする`tuist cache`
のような機能も可能になる。

::: チップ
<!-- -->
私たちは、Xcodeから機能を移植するリクエストの一つ一つを、シンプルで明示的なAPIで概念を単純化する機会として扱うべきです。
<!-- -->
:::

## シンプルに保つ{#keep-it-simple}。

Xcode プロジェクトをスケーリングするときの主な課題の 1 つは、**Xcode が多くの複雑さをユーザにさらすという事実から来る。**
そのため、チームはバス要素が高く、チーム内の数人だけがプロジェクトとビルドシステムが投げるエラーを理解しています。チームが数人に依存しているため、これは悪い状況だ。

Xcodeは素晴らしいツールだが、長年の改良、新しいプラットフォーム、プログラミング言語がその表面に反映されており、シンプルさを保つのに苦労した。

Tuistは、物事をシンプルに保つ機会を取るべきだ。なぜなら、シンプルなことに取り組むことは楽しく、私たちのモチベーションを高めてくれるからだ。コンパイルプロセスの一番最後に起こるエラーをデバッグしたり、自分のデバイスでアプリを実行できない理由を理解したりすることに時間を費やしたいと思う人はいない。Xcodeは、その基礎となるビルド・システムにタスクを委譲し、場合によっては、エラーを実用的な項目に変換するのが非常に下手なのだ。*"framework
X not found"*
エラーが表示され、どうすればいいかわからなかったことはないだろうか？もしバグの潜在的な根本原因のリストがあったらと想像してみてほしい。

## 開発者の経験から始める{#start-from-the-developers-experience}。

Xcode周辺にイノベーションがない、あるいは別の言い方をすれば、他のプログラミング環境ほどイノベーションがない理由の一つは、**、私たちはしばしば既存のソリューションから問題を分析し始めるからです。**
その結果、現在私たちが見つけるソリューションのほとんどは、同じアイデアやワークフローを中心に回っています。既存の解決策を方程式に取り入れるのは良いことだが、それによって創造性が制約されるようなことがあってはならない。

私たちは、[トム・プレストン](https://tom.preston-werner.com/)が[このポッドキャスト](https://tom.preston-werner.com/)で言っているように考えたい：*「たいていのことは実現できる。頭の中にあることは何でも、宇宙の制約の中で可能な限り、コードで実現できるだろう」。*
もし、**、開発者の経験をどのようにしたいかを想像すれば、**
、それを実現するのは時間の問題だ。開発者の経験から問題を分析し始めることで、ユニークな視点が得られ、ユーザーに喜んで使ってもらえる解決策を導き出すことができる。

たとえそれが、みんなが文句を言い続けるような不便さを我慢することであったとしても。それはやめよう。自分のアプリをアーカイブするにはどうしたらいいだろうか？コード署名をどうしたいだろうか？Tuistでどんなプロセスを効率化できるだろうか？例えば、[Fastlane](https://fastlane.tools/)のサポートを追加することは、まず理解する必要がある問題に対する解決策だ。なぜ」という質問をすることで、問題の根源にたどり着くことができる。動機がどこから来るのかを絞り込めば、Tuistがどのように彼らを助けることができるかを考えることができる。もしかしたら、その解決策はファストレーンとの統合かもしれないが、トレードオフをする前に、同じように有効な他の解決策を無視しないことが重要だ。

## エラーは起こりうるし、起こるだろう{#errors-can-and-will-happen}。

私たち開発者は、エラーが起こりうることを軽視する誘惑を内在している。その結果、私たちは理想的なシナリオだけを考えてソフトウェアを設計し、テストします。

Swift、その型システム、そしてよく設計されたコードは、いくつかのエラーを防ぐのに役立つかもしれませんが、いくつかは私たちのコントロールの外にあるため、すべてではありません。我々は、ユーザーが常にインターネットに接続していると仮定することはできないし、システムコマンドが正常に戻るとも仮定できない。Tuistが実行される環境は我々がコントロールするサンドボックスではないので、それらがどのように変化してTuistに影響を与えるかを理解する努力をする必要がある。

エラーの扱いが悪いとユーザーエクスペリエンスが悪くなり、ユーザーはプロジェクトに対する信頼を失うかもしれません。私たちは、ユーザーにエラーを提示する方法まで含めて、Tuistのあらゆる部分を楽しんでもらいたいと思っています。

ユーザーの立場になって、エラーが何を教えてくれるのか想像してみよう。プログラミング言語がエラーを伝播させる通信チャネルであり、ユーザーがエラーの送信先であるならば、エラーはターゲット（ユーザー）が話すのと同じ言語で書かれるべきである。何が起こったかを知るのに十分な情報を含み、関連性のない情報は隠すべきである。また、ユーザーがエラーから回復するためにどのようなステップを踏むことができるかを伝えることで、実行可能であるべきである。

そして最後に、テストケースは失敗するシナリオを想定しておかなければならない。エラーを想定通りに処理していることを保証するだけでなく、将来の開発者がそのロジックを壊してしまうのを防ぐためでもある。