(und wie man L\u00f6sungen erstellt, die auch nach Updates weiterhin funktionieren)<\/p>\n
\u201eApps d\u00fcrfen nur \u00f6ffentliche APIs verwenden und m\u00fcssen auf dem aktuell ausgelieferten Betriebssystem ausgef\u00fchrt werden.\u201c Richtlinien zur \u00dcberpr\u00fcfung von Apple-Apps<\/p>\n
Wenn Sie jemals angefangen haben, mit einem neuen Framework zu arbeiten, und sich dabei ertappt haben, dass Sie denken: \u201eJetzt verstehe ich alles selbst, das Lesen der Dokumentation ist zu lang\u201c, dann sind Sie definitiv nicht allein. Viele von uns haben einen nat\u00fcrlichen Forscherinstinkt: Erst ausprobieren und erst dann die Anleitung anschauen. Und das ist v\u00f6llig normal.<\/p>\n
In diesem Stadium kann es jedoch leicht passieren, dass man sich \u00fcbertreibt und in eine Situation ger\u00e4t, in der der Code zwar gut funktioniert, sich aber m\u00f6glicherweise auf nicht offensichtliche Funktionen des Systems verl\u00e4sst.<\/p>\n
Frameworks, insbesondere geschlossene, sind komplexe und vielschichtige Systeme. Sie verbergen oft interne Logik und Optimierungen, die:<\/p>\n
* sind nicht in der \u00f6ffentlichen Dokumentation beschrieben;
\n* garantieren nicht, dass das Verhalten auch in Zukunft beibehalten wird;
\n* kann sich mit der Ver\u00f6ffentlichung neuer Versionen \u00e4ndern;
\n* kann den Entwicklern bekannte Funktionen enthalten, die noch nicht behoben wurden.<\/p>\n
Wenn wir intuitiv handeln, besteht die Gefahr, dass Architektur auf zuf\u00e4lligen Beobachtungen und nicht auf dokumentierten Regeln basiert. Dadurch kann der Code empfindlicher auf Aktualisierungen reagieren.<\/p>\n
Framework-Entwickler erstellen Handb\u00fccher, um uns zu helfen. Wenn wir innerhalb der Dokumentation handeln, erhalten wir:<\/p>\n
* Stabilit\u00e4t;
\n* Unterst\u00fctzung;
\n* vorhersehbares Systemverhalten.<\/p>\n
Wenn wir \u00fcber diese Grenzen hinausgehen, gehen wir zus\u00e4tzliche Risiken ein und die Pflege dieses Codes wird schwieriger.<\/p>\n
Experimente? Sicherlich. Aber mit einem Verst\u00e4ndnis f\u00fcr Grenzen.
\nNeugier ist eine gro\u00dfartige Eigenschaft eines Entwicklers. Das Erkunden und Ausprobieren neuer Dinge ist absolut unerl\u00e4sslich. Aber hier ist ein kleiner Wunsch:<\/p>\n
Die bequemste Art zu experimentieren besteht darin, sich auf Best Practices zu verlassen.<\/p>\n
Bei der Dokumentation handelt es sich um eine Karte, die zeigt, welche Pfade am sichersten sind und von den Erstellern unterst\u00fctzt werden.<\/p>\n
Wir lernen oft von erfahrenen Kollegen:<\/p>\n
* sie f\u00fchren n\u00fctzliche Kurse durch,
\n* auf Konferenzen sprechen,
\n* wunderbare B\u00fccher und Blogs schreiben,
\n* ihre einzigartige Vision teilen.<\/p>\n
Viele von ihnen teilen wirklich wertvolle Erfahrungen. Aber es sei daran erinnert: Wenn die Ans\u00e4tze des Autors im Widerspruch zur offiziellen Dokumentation stehen, k\u00f6nnen sie sich als fragil erweisen.<\/p>\n
Solche \u201eempirischen Muster\u201c manchmal:<\/p>\n
* nur mit einer bestimmten Version des Frameworks arbeiten;
\n* empfindlich gegen\u00fcber Updates;
\n* kann sich in ungew\u00f6hnlichen Situationen unvorhersehbar verhalten.<\/p>\n
Von der Community zu lernen ist gro\u00dfartig und lohnend. Aber jeder Rat, selbst der ma\u00dfgeblichste, sollte immer sorgf\u00e4ltig anhand offizieller Handb\u00fccher \u00fcberpr\u00fcft werden.<\/p>\n
Drei Ideen aus den SOLID-Prinzipien erg\u00e4nzen diesen Ansatz perfekt:<\/p>\n
* Offenes\/geschlossenes Prinzip: Versuchen Sie, das Verhalten \u00fcber \u00f6ffentliche APIs zu erweitern und verlassen Sie sich nach M\u00f6glichkeit nicht auf eine versteckte Implementierung.
\n* Liskov-Substitutionsprinzip: Verlassen Sie sich auf den Vertrag, nicht auf die konkrete Umsetzung. Andernfalls k\u00f6nnen \u00c4nderungen unter der Haube zu unerwarteten Schwierigkeiten f\u00fchren.
\n* Abh\u00e4ngigkeitsumkehr: Erstellen Sie Abh\u00e4ngigkeiten auf Abstraktionen, nicht auf Details.<\/p>\n
In der Praxis bedeutet dies, dass die Bindung an interne, nicht dokumentierte Details des Frameworks das System spr\u00f6de macht.
\nBasierend auf \u00f6ffentlichen Schnittstellen und Vertr\u00e4gen erhalten wir:<\/p>\n
* bessere Isolierung des Codes von \u00c4nderungen im Framework;
\n* einfache Pr\u00fcfung;
\n* Vorhersehbarkeit und Zuverl\u00e4ssigkeit der Architektur.<\/p>\n
Es kommt auch vor, dass alles nach den Regeln gemacht wird, das Ergebnis aber nicht den Erwartungen entspricht. Rahmenbedingungen entwickeln sich weiter und sind nicht immer perfekt. In solchen F\u00e4llen:<\/p>\n
* Erstellen Sie ein Minimalbeispiel, das das Problem reproduziert.
\n* Stellen Sie sicher, dass nur dokumentierte APIs verwendet werden.
\n* Senden Sie einen Fehlerbericht \u2013 das Entwicklungsteam wird Ihre Arbeit sicherlich zu sch\u00e4tzen wissen und versuchen zu helfen.<\/p>\n
Wenn das Beispiel auf Workarounds setzt, wird es f\u00fcr Entwickler deutlich schwieriger, Support zu leisten.<\/p>\n
*Siehe Dokumentation.
\n* Befolgen Sie die Anleitungen und Empfehlungen der Autoren.
\n* Experimentieren Sie innerhalb der beschriebenen Funktionalit\u00e4t.
\n* \u00dcberpr\u00fcfen Sie die Ratschl\u00e4ge im Internet mit offiziellen Quellen.
\n* Lokalisieren Sie Fehler unter Einhaltung der Rahmenvertr\u00e4ge.<\/p>\n
Frameworks sind m\u00e4chtige Werkzeuge mit eigenen Spielregeln. Wenn wir sie vergessen, besteht die Gefahr, dass unser Code \u00fcberm\u00e4\u00dfig anf\u00e4llig wird. Aber wir alle m\u00f6chten, dass die erstellten Produkte lange leben und nicht nach jedem kleinen Update dringende Korrekturen erfordern.<\/p>\n
Handb\u00fccher und Dokumentationen sind eine hervorragende Unterst\u00fctzung, die dabei hilft, wirklich zuverl\u00e4ssige L\u00f6sungen zu schaffen.<\/p>\n
https:\/\/developer.apple.com\/app-store\/review\/guidelines\/<\/a> (und wie man L\u00f6sungen erstellt, die auch nach Updates weiterhin funktionieren) \u201eApps d\u00fcrfen nur \u00f6ffentliche APIs verwenden und m\u00fcssen auf dem aktuell ausgelieferten Betriebssystem ausgef\u00fchrt werden.\u201c Richtlinien zur \u00dcberpr\u00fcfung von Apple-Apps Wenn Sie jemals angefangen haben, mit einem neuen Framework zu arbeiten, und sich dabei ertappt haben, dass Sie denken: \u201eJetzt verstehe ich alles selbst, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8],"tags":[],"class_list":["post-102","post","type-post","status-publish","format-standard","hentry","category-notes"],"translation":{"provider":"WPGlobus","version":"3.0.5","language":"de","enabled_languages":["en","ru","zh","de","ja","fr","es","pt","hi"],"languages":{"en":{"title":true,"content":true,"excerpt":false},"ru":{"title":true,"content":true,"excerpt":false},"zh":{"title":true,"content":true,"excerpt":false},"de":{"title":true,"content":true,"excerpt":false},"ja":{"title":true,"content":true,"excerpt":false},"fr":{"title":true,"content":true,"excerpt":false},"es":{"title":false,"content":false,"excerpt":false},"pt":{"title":true,"content":true,"excerpt":false},"hi":{"title":true,"content":true,"excerpt":false}}},"_links":{"self":[{"href":"https:\/\/demensdeum.com\/blog\/de\/wp-json\/wp\/v2\/posts\/102","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/demensdeum.com\/blog\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/demensdeum.com\/blog\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/demensdeum.com\/blog\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/demensdeum.com\/blog\/de\/wp-json\/wp\/v2\/comments?post=102"}],"version-history":[{"count":0,"href":"https:\/\/demensdeum.com\/blog\/de\/wp-json\/wp\/v2\/posts\/102\/revisions"}],"wp:attachment":[{"href":"https:\/\/demensdeum.com\/blog\/de\/wp-json\/wp\/v2\/media?parent=102"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/demensdeum.com\/blog\/de\/wp-json\/wp\/v2\/categories?post=102"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/demensdeum.com\/blog\/de\/wp-json\/wp\/v2\/tags?post=102"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nhttps:\/\/en.wikipedia.org\/wiki\/SOLID<\/a>
\nhttps:\/\/en.wikipedia.org\/wiki\/API<\/a>
\nhttps:\/\/en.wikipedia.org\/wiki\/RTFM<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"