（そして、更新後にアドバイスが機能することをやめない第一人者にならない方法）
「アプリはパブリックAPIのみを使用する場合があり、現在配送されているOSで実行する必要があります。」 Appleアプリのレビューガイドライン
新しいフレームワークの作業を開始して、「今、私はすべてを理解します、ドキュメントはボアのためのものです」と考えているなら、あなたは間違いなく一人ではありません。多くの開発者には自然な本能があります。最初に試してみるだけです – 読んでください。これで問題ありません。
しかし、この段階では、正しい道を簡単にオフにして、コードが機能する状況にいることに気付くことができます…しかし、今日だけ、「私は持っています」。
なぜ「把握する」のが簡単なのはなぜですか？それだけでは不十分ですか？
Freimvorkiは、特に閉じた独自のもので、複雑で多層です。彼らは多くの隠されたロジック、最適化、および実装機能を持っています。
*文書化されていません。
*保証されていません。
*いつでも変更できます。
*商業的な秘密であり、特許によって保護できます
*フレームワークの開発者にのみ知られているバグ、欠陥が含まれています。
「Hunchで」行動すると、明確に記載されているルールをサポートする代わりに、ランダムな観測でアーキテクチャを簡単に構築できます。これは、コードが更新やエッジケースに対して脆弱になるという事実につながります。
ドキュメントは制限ではありませんが、サポート
フレームワークの開発者は、理由でマニュアルを作成します – これはあなたとそれらの間の合意です。あなたがドキュメントの一部として行動している間、彼らは約束します：
* 安定性;
* サポート;
*予測可能な動作。
あなたがこのフレームワークを超えているなら、次に起こるすべてがあなたの責任のみになります。
実験？確かに。しかし、ルールのフレームワークでは。
好奇心は開発者のスーパービアです。探索、標準以外のテスト境界を試してください – これはすべて必要です。しかし、重要な「しかし」があります：
ドキュメントとベストプラクティスのフレームワークで実験する必要があります。
文書は刑務所ではなく、カードです。彼女は、どのような機会が本当に計画され、サポートされているかを示しています。有用であるだけでなく、安全なのはそのような実験です。
注意：第一人者
時々あなたは本当の「専門家」に出会うかもしれません：
*彼らはコースを実施します
*会議で演奏する、
*本やブログを書く、
*フレームワークに「彼らのアプローチ」を共有しました。
しかし、たとえ彼らが説得力があるように聞こえたとしても、覚えておくことが重要です：
彼らのアプローチがドキュメントに反している場合、彼らは不安定です。
このような「経験的パターン」は次のとおりです。
*フレームワークの特定のバージョンでのみ動作します。
*更新に対して脆弱になります。
*予測不可能な状況で壊れます。
グルはマニュアルを尊重するときはかっこいいです。それ以外の場合、彼らのヒントは公式の文書を通してフィルタリングする必要があります。
少し固体
堅実な原則からの3つのアイデアがここで特に関連しています：
*オープン/クローズド原理：パブリックAPIを介して動作を拡張し、内側に入らないでください。
* Liskov Sustitionの原則：実装に依存せず、契約に依存してください。障害 – 実装を交換すると、すべてが破壊されます。
*依存関係の反転：高レベルのモジュールは、低レベルモジュールに依存してはなりません。両方のタイプは抽象化に依存する必要があります。抽象化は詳細に依存してはなりません。詳細は抽象化に依存する必要があります。
これは実際にはどういう意味ですか？フレームワークを使用し、その内部の詳細に直接結び付けられている場合、この原則に違反します。
代わりに、フレームワークが公式にサポートするパブリックインターフェイス、プロトコル、契約への依存を構築する必要があります。これは次のとおりです。
*フレームワークの変更からのコードの最良の分離。
*依存関係を簡単にテストして置き換える機能。
*アーキテクチャの予測可能な動作と安定性。
コードが抽象化ではなく詳細に依存している場合、いつでも消えたり変更されたりする可能性のある特定の実装に文字通り自分自身を埋め込みました。
そしてバグの場合は？
あなたがすべてを正しくしたことが起こることもありますが、それは間違って動作します。これは起こります – フレームワークは完璧ではありません。この場合：
*最小の複製例を収集します。
*ドキュメントされたAPIのみを使用していることを確認してください。
*バグポートを送る – 彼らは間違いなくあなたを理解し、おそらく助けになるでしょう。
この例がハッキングまたはバイパスに基づいて構築されている場合、開発者はそれをサポートする必要はなく、おそらくあなたのケースは単に見逃します。
フレームワークから最大を絞る方法
*ドキュメントをお読みください。真剣に。
*著者からのガイドと推奨事項に従ってください。
*実験 – ただし、説明されています。
*マニュアルからヒント（最も有名なスピーカーでさえ！）を確認してください。
*最小限のケースと契約の尊重でバグを折ります。
結論
Freimvorkiはブラックボックスではなく、使用規則を備えたツールです。それらを無視するということは、「ランダムに」コードを書くことを意味します。しかし、私たちはコードを長い間生き、ユーザーを喜ばせ、マイナーなアップデートから脱却しないようにしたいと考えています。
だから：信頼しますが、チェックしてください。そして、はい、マニュアルを読んでください。彼らはあなたの超大国です。
ソース
https://developer.apple.com/app-store/review/guidelines/
https://en.wikipedia.org/wiki/SOLID
https://en.wikipedia.org/wiki/API
https://en.wikipedia.org/wiki/RTFM
