(Und wie nicht ein Guru sein kann, dessen Rat nach dem Update nicht mehr funktioniert)
“Apps dürfen nur öffentliche APIs verwenden und müssen auf dem derzeit Versandbetrieb ausgeführt werden.” Apple App Review -Richtlinien
Wenn Sie jemals mit einem neuen Framework gearbeitet haben und sich erwischt haben: “Jetzt verstehe ich alles, Dokumentation ist für Bohrungen”-Sie sind definitiv nicht allein. Viele Entwickler haben einen natürlichen Instinkt: zuerst versuchen und nur dann – lesen. Das ist in Ordnung.
Aber zu diesem Zeitpunkt können Sie leicht den richtigen Weg ausschalten und sich in einer Situation befinden, in der der Code funktioniert … aber erst heute und nur “ich habe”.
Warum ist es einfach, es herauszufinden – ist es nicht genug?
Freiimvorki, insbesondere geschlossen und proprietär, sind komplex und mehrfach. Sie haben eine Menge versteckter Logik-, Optimierungs- und Implementierungsfunktionen, die:
* nicht dokumentiert;
* nicht garantiert;
* kann sich jederzeit ändern;
* sind ein kommerzielles Geheimnis und können durch Patente geschützt werden
* Enthält Fehler, Fehler, die nur den Entwicklern des Frameworks bekannt sind.
Wenn Sie “auf eine Ahnung” handeln, können Sie leicht Architektur in zufälligen Beobachtungen aufbauen, anstatt die klar beschriebenen Regeln zu unterstützen. Dies führt dazu, dass der Code anfällig für Aktualisierungen und Kantenfälle wird.
Dokumentation ist keine Einschränkung, sondern Unterstützung
Die Entwickler von Frameworks erstellen aus einem bestimmten Grund Handbücher – dies ist eine Vereinbarung zwischen Ihnen und ihnen. Während Sie als Teil der Dokumentation fungieren, versprechen sie:
* Stabilität;
* Unterstützung;
* vorhersehbares Verhalten.
Wenn Sie über diesen Framework hinausgehen, wird alles, was als nächstes passiert, ausschließlich zu Ihrer Verantwortung.
Experimente? Sicherlich. Aber im Rahmen der Regeln.
Neugier ist die Super -VIA des Entwicklers. Erforschen Sie, versuchen Sie, nicht standardmäßige, Testgrenzen – all dies ist notwendig. Aber es gibt ein wichtiges “aber”: “:
Sie müssen im Rahmen der Dokumentation und der Best Practices experimentieren.
Dokumentation ist kein Gefängnis, sondern eine Karte. Sie zeigt, welche Möglichkeiten wirklich geplant und unterstützt werden. Es sind solche Experimente, die nicht nur nützlich, sondern auch sicher sind.
Vorsicht: Guru
Manchmal können Sie echte “Experten” begegnen:
* Sie führen Kurse durch
* Auf Konferenzen aufführen,
* Bücher und Blogs schreiben,
* teilte “ihren Ansatz” zum Framework.
Aber selbst wenn sie überzeugend klingen, ist es wichtig, sich zu erinnern:
Wenn ihre Ansätze der Dokumentation widersprechen, sind sie instabil.
Solche “empirischen Muster” können:
* Arbeit nur an einer bestimmten Version des Frameworks;
* Seien Sie anfällig für Aktualisierungen;
* In unvorhersehbaren Situationen brechen.
Guru ist cool, wenn sie die Handbücher respektieren. Andernfalls müssen ihre Tipps durch offizielle Dokumentation gefiltert werden.
ein wenig solide
Drei Ideen aus soliden Prinzipien sind hier besonders relevant:
* Öffnen/geschlossenes Prinzip: Erweitern Sie das Verhalten durch eine öffentliche API, gehen Sie nicht in die Innenseiten.
* Liskov Substitionsprinzip: Verlassen Sie sich nicht auf die Umsetzung, verlassen Sie sich auf den Vertrag. Erkrankungen – Alles wird brechen, wenn die Implementierung ersetzt wird.
* Abhängigkeitsinversion: Hoch -Level -Module sollten nicht von Modulen mit niedrigem Level abhängen. Beide Typen sollten von Abstraktionen abhängen. Die Abstraktion sollte nicht von den Details abhängen. Details sollten von Abstraktionen abhängen.
Was bedeutet das in der Praxis? Wenn Sie ein Framework verwenden und direkt an seine internen Details gebunden sind, verstoßen Sie gegen dieses Prinzip.
Stattdessen müssen Sie die Abhängigkeit von öffentlichen Schnittstellen, Protokollen und Verträgen aufbauen, die der Rahmen offiziell unterstützt. Das gibt:
* Die beste Isolation Ihres Codes aus Änderungen im Framework;
* Die Fähigkeit, Abhängigkeiten einfach zu testen und zu ersetzen;
* Vorhersehbares Verhalten und Stabilität der Architektur.
Wenn Ihr Code von den Details und nicht von Abstraktionen abhängt, werden Sie buchstäblich in eine bestimmte Implementierung einbettet, die jederzeit verschwinden oder sich ändern kann.
Und wenn der Fehler?
Manchmal kommt es vor, dass Sie alles richtig gemacht haben, aber es funktioniert falsch. Dies passiert – Frameworks sind nicht perfekt. In diesem Fall:
* Sammeln Sie ein minimal reproduziertes Beispiel.
* Stellen Sie sicher, dass Sie nur dokumentierte API verwenden.
* Senden Sie einen Fehlerport-sie werden Sie definitiv verstehen und höchstwahrscheinlich helfen.
Wenn das Beispiel auf Hacks oder Bypass basiert, müssen die Entwickler es nicht unterstützen, und höchstwahrscheinlich wird Ihr Fall einfach vermissen.
wie man das Maximum aus dem Framework drückt
* Lesen Sie die Dokumentation. Ernsthaft.
* Befolgen Sie die Anleitungen und Empfehlungen der Autoren.
* Experiment – aber innerhalb des beschriebenen.
* Überprüfen Sie die Tipps (sogar die berühmtesten Lautsprecher!) Durch das Handbuch.
* Falten Sie Fehler mit minimalen Fällen und Respekt vor dem Vertrag.
Schlussfolgerung
Freiimvorki sind keine schwarzen Kisten, sondern Werkzeuge, die die Nutzungsregeln haben. Sie zu ignorieren bedeutet, den Code “nach zufällig” zu schreiben. Aber wir möchten, dass unser Code lange Zeit lebt, Benutzer begeistert und nicht vom kleinen Update abbricht.
Also: Vertrauen, aber überprüfen Sie. Und ja, lesen Sie die Handbücher. Sie sind Ihre Supermacht.
Quellen
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
