Blog

Unerwartete schlechte Praktiken	https://cleverlance.de/de/blog/Seiten/unexpected-bad-practices.aspx	Unerwartete schlechte Praktiken	<p>Einige Programmierpraktiken sind uns so vertraut, dass wir sie automatisch und ohne großes Nachdenken anwenden. Manchmal sind diese Techniken veraltet, manchmal werden sie im falschen Kontext angewendet. Das Ansprechen solch schlecht eingespielter Gewohnheiten stößt oft auf Ablehnung. Vor allem von denjenigen, die sie nutzen und das Thema als nützlich empfinden, also lasst uns genau das tun!</p><h3>Marks<br></h3><p>Programmier-IDEs erkennen oft bestimmte Arten von Kommentaren, um die Navigation in der Codebasis zu erleichtern. Die <em>FIXME</em>-Funktion von Xcode lässt andere Entwickler wissen, dass ein Teil des Codes mehr Aufmerksamkeit verdient. <em>TODO</em> ist hilfreich, wenn etwas, nun ja, erledigt werden soll. <em>MARK</em> unterscheidet sich von den vorherigen Fällen; es dient der Dokumentation. Die gleiche Funktion wird in IntelliJ IDEA/Android Studio als Region bezeichnet.</p><p>Markierungen unterteilen den Quellcode in mehrere Teile, indem sie Überschriften verwenden. Das kann dazu führen, dass der Code in logische Einheiten unterteilt erscheint. Wenn Sie ein Leser sind, der mit der früheren Objective-C-Ära der iOS-Entwicklung vertraut ist, wissen Sie, dass dies nur eine aktualisierte <em>#pragma mark</em>-Anweisung ist.</p><p>Typisch ist die Verwendung in Dateien mit einer großen Anzahl von Zeilen. Zeichen schaffen die Illusion von Klarheit, indem sie in vermeintlich zusammengehörende Teile zerlegt werden.</p><p>Die Verwendung von Zeichen in solchen Fällen ist eine schlechte Praxis. Entwickler missbrauchen sie oft, um eine zu große Datei zu rechtfertigen. Man sollte sich nicht auf Xcode verlassen, um den Code verständlich und lesbar zu machen. Kleine und gut komponierte Klassen sind ohne IDE-Funktionen einfacher zu verstehen und zu navigieren. Vor allem für die Überprüfer von Pull-Anfragen, die die Weboberfläche benutzen, wo diese Funktionen nicht vorhanden sind.</p><h3>Erweiterungen</h3><p>Moderne Programmiersprachen wie Kotlin oder Swift ermöglichen die Erweiterung von Klassen, Schnittstellen/Protokollen, Structs oder Enums, um eine zusätzliche Implementierung bereitzustellen. Sie können Ihren Code in mehrere Teile aufteilen, indem Sie Erweiterungen verwenden, um festzulegen, was näher zusammengehört. Eine andere Möglichkeit besteht darin, eine Erweiterung für einen anderen Typ zu erstellen, den Sie vielleicht nicht einmal besitzen, um seine Verwendung intuitiver zu gestalten. Die Möglichkeiten sind nahezu grenzenlos. Das ist nicht immer eine gute Sache, aber zunächst ein Blick in die Geschichte. </p><p>Erweiterungen gab es auch schon in Objective-C. Wenn Sie keine Erfahrung mit der Programmierung in einer solchen Sprache haben und den Namen für Erweiterungen erraten müssten, würden Sie wahrscheinlich überrascht sein. Es sind Kategorien! Eine weitere Überraschung ist, dass es auch in Objective-C Erweiterungen gibt, die jedoch anderen Zwecken dienen. Interessant ist der Unterschied zwischen den beiden Sprachen. Kategorien in Objective-C zwangen den Entwickler, sich den Namen auszudenken. Aus diesem Grund werden Dateien mit dem Namen Class+CategoryName.swift oft auch für Swift-Erweiterungen verwendet. Und noch wichtiger: Um Kategorien zu verwenden, mussten sie explizit importiert werden.</p><p>Erweiterungen in Swift sind ein unbenannter Teil des Codes. Ein solcher Code kann für den Leser komplizierter zu verstehen sein. Wenn es mehrere Erweiterungen desselben Typs gibt, kann das Hinzufügen eines Namens zum Code und die Einbettung in einen Typ die Lesbarkeit erheblich verbessern.</p><p>Die unsachgemäße Erweiterung von weit verbreiteten Typen führt zu einer Verschmutzung des Namensraums. Es ist wichtig, sich vor der Erstellung von Erweiterungen zu fragen, ob alle Instanzen des Typs eine solche Fähigkeit haben sollen. Sollten alle UIViews Zugang zu einer Blinkmethode haben? Macht eine bestimmte Unterklasse von UIView mehr Sinn?</p><p>Einige Entwickler verwenden Erweiterungen, um die Implementierung mehrerer Protokolle aufzuschlüsseln, was ebenfalls ein Warnzeichen sein kann. Wenn eine Klasse viele Protokolle implementiert, ist es vielleicht an der Zeit, sie in kleinere Klassen aufzuteilen.</p><p>Für Trolle da draußen: Sie können Ihre Kollegen wütend machen, indem Sie <em>UIView</em> mit <em>translatesAutoresizingMasksIntoConstraints</em> erweitern und beobachten, wie sie es mit <em>translatesAutoresizingMaskIntoConstraints vergleichen.</em></p><p>Aber tun Sie es nicht.</p><h3>Kommentare</h3><p>Die Möglichkeit, Kommentare zu schreiben, könnte undisziplinierte Programmierer dazu verleiten, einen Code von schlechter Qualität zu erstellen. Leider ist es einfacher, eine Variable nicht zu benennen und mit einem komplizierten, aber nicht so klaren Kommentar zu beschreiben, was in meinem Kopf vor sich geht. Leichtigkeit sollte nicht unser Ziel sein. Knappheit und Klarheit sollten es sein.</p><p>Ein guter Kommentar für einen schlecht geschriebenen Code ist immer noch ein Codegeruch. Nehmen Sie nicht nur mich beim Wort. Robert Martin erklärt: „Ein Kommentar ist ein Versäumnis, sich in einem Code auszudrücken. Wenn Sie scheitern, dann schreiben Sie einen Kommentar; aber versuchen Sie nicht zu scheitern.“</p><p>Ein weiterer Grund ist, dass sich das Verhalten des Codes ändern kann, wenn er im Repository lebt, geändert und überarbeitet wird, und dass sein Name dies überall, wo er aufgerufen wird, zum Ausdruck bringen kann. Der Kommentar wird jedoch selten aktualisiert und kann mehr verwirren als helfen.</p><p>Dokumentationskommentare erfüllen ihren Zweck sehr gut, wenn Sie eine API entwerfen, die andere verwenden sollen. Denken Sie daran, dass die API für sich selbst stehen muss, und dass Klarheit Vorrang hat. Benutzen Sie die Kommentare in der Dokumentation nicht als Entschuldigung für ein miserables Design.</p><h3>Struktur</h3><p>Die Struktur eines Projekts ist eines der ersten Dinge, die man sieht, wenn man sich eine Codebasis ansieht, und sie sollte auf den ersten Blick den Zweck der Anwendung umreißen. Es ist jedoch keine Ausnahme, dass einige Projekte Ordnerstrukturen haben, die von den Schichten der Architektur inspiriert sind, z. B. View, ViewModel, Model.</p><p>Eine Projektstruktur auf der Grundlage von Architekturschichten ist eine schlechte Praxis. Dies macht die Wiederverwendbarkeit praktisch unmöglich. Die Navigation durch eine solche Struktur ist unnötig kompliziert und wird mit zunehmendem Umfang immer schwieriger zu pflegen. Sie ist nicht skalierbar. Von der Architektur inspirierte Ordner könnten ihren Platz haben, nicht nur auf der obersten Ebene. Es sollte nicht das erste sein, was Sie sehen.<br></p><p><img src="/de/blog/PublishingImages/Articles/MobileIt/unexpected-bad-practices-01-01.png" data-themekey="#" alt="" style="margin:5px;" /><br></p><p>Überzeugen Sie sich selbst, welche Struktur Ihnen mehr über die Anwendung verrät</p><h3>Abhängigkeiten</h3><p>Open Source bietet viele Bibliotheken, die das Leben vereinfachen, von UI-Komponenten über Netzwerke bis hin zu Lösungen für die Injektion von Abhängigkeiten. Dies kann oft viel Zeit und Mühe sparen. Andererseits birgt dies verschiedene Gefahren und Einschränkungen; die Verwendung von Bibliotheken Dritter erfordert Disziplin, Ordnung und Ausgewogenheit.</p><p>Zufällig verstreute Abhängigkeiten von Dritten verringern die Robustheit erheblich. Die Abschirmung des Kerns der Anwendung und die Verwendung der Bibliotheken von den äußeren Teilen der Architektur helfen, das Risiko zu mindern. Die Abstraktion erleichtert den Prozess des Ersetzens einer Bibliothek durch eine andere.</p><p>Es ist in Ordnung, Abhängigkeiten von Drittanbietern zu verwenden, aber mit Vorsicht. Fragen Sie sich selbst: Wie viel Zeit werde ich dadurch sparen? Wie hoch ist der Aufwand für den Ersatz? Kann ich genügend Schutzmechanismen installieren, um die Anwendung zu schützen? </p><p>Der Königsweg zum Schutz Ihrer Anwendung, auch wenn dies manchmal schwierig oder unpraktisch ist, besteht darin, die Abhängigkeit nur an einer Stelle zu importieren.</p><p>Wir hatten bereits das Vergnügen, mehrere Anwendungen zu übernehmen, die aufgrund dieses Problems nicht mehr zu warten waren. Ohne Abstraktion, nicht mehr unterstützte (oder Closed-Source-) Bibliotheken haben die Codebase zersetzt. Externe Abhängigkeiten sollten Ihr Produkt niemals als Geisel halten.</p><h3>Tests</h3><p>Testgetriebene Entwicklung ist die gute Kinderstube eines Programmierers, eine Disziplin mit vielen Vorteilen. Die technischen Auswirkungen sind ein eigener Blogbeitrag, wenn nicht sogar eine ganze Serie. Nicht-technische Auswirkungen wie etwa die einfache Einarbeitung neuer Teammitglieder und eine ausführbare Dokumentation, die nicht veralten kann, sprechen für sich.</p><p>Dennoch werden sie oft vernachlässigt. Das völlige Fehlen von Tests ist der offensichtlich erste und häufigste Verstoß, gefolgt vom Schreiben von Tests nach dem Produktionscode, was alle Vorteile abschwächt und andere Hindernisse mit sich bringt.</p><p>Sie müssen zuerst Unit-Tests schreiben - vor dem Produktionscode. Wenn Sie zuerst testen, verhindern Sie, dass Sie einen zu komplexen Code erstellen. Er führt Sie durch den Bau von Bauteilen in der richtigen Größe. Die großen Klassen sind schwierig zu testen, und die Tests werden Sie anweisen, sie in kleinere Klassen zu zerlegen.</p><p>Tests, die nach dem Produktionscode geschrieben werden, sind von Natur aus von geringerer Qualität und können sogar irreführend sein. Solange Sie den Produktionscode nicht als Beweis für den ersten fehlgeschlagenen Test schreiben, ist es unmöglich zu sagen, ob die Tests das behaupten, was sie deklarieren. Es ist dann fraglich, wie gut solche Tests das zu prüfende System schützen.</p><p>Wenn Sie Tests erst nach der Implementierung schreiben, kann es sein, dass eine Komponente schwierig zu testen ist, was bei einem Test-first-Ansatz unmöglich ist. Sie können keinen untestbaren Code erstellen!</p><h3>Der Teufel steckt im Detail</h3><p>Selbst das Alltägliche kann schädlich sein, wenn wir etwas zu automatisch und mit weniger Aufmerksamkeit tun. Stellen Sie das Gewöhnliche in Frage und suchen Sie nach schlechten Praktiken, die Sie nicht erwarten würden.<br></p>
Apple denkt an die Sicherheit seiner Benutzer	https://cleverlance.de/de/blog/Seiten/apple-account-deletion.aspx	Apple denkt an die Sicherheit seiner Benutzer	<p>Mobile Apps werden bei den Benutzern immer beliebter. Jeden Tag werden von <strong>Google Play</strong> und <strong>Apple App Store</strong> tausende heruntergeladen. Allerdings sind nicht alle Apps für ihre Benutzer völlig sicher und nicht alle verwalten die persönlichen Daten der Benutzer korrekt. Die oben genannten Unternehmen versuchen zu überwachen, dass nur solche Apps in ihre Stores gelangen, die mit den Benutzern "fair spielen".</p><p>Um die Privatsphäre der Benutzer von iOS-Apps zu schützen, hat Apple eine <a href="https://developer.apple.com/support/offering-account-deletion-in-your-app" target="_blank">Verordnung erlassen</a>, dass "ab dem 30. Juni 2022 alle mobilen Apps im App Store, die die Erstellung von Konten unterstützen, den Benutzern auch die Möglichkeit geben müssen, ihre Konten zu löschen".</p><p>Ursprünglich sollte diese Richtlinie bereits ab Ende Januar 2022 gelten, aber die Frist wurde auf Druck von Entwicklern und Gesellschaften, die Applikationen betreiben, um fünf Monate verschoben. Dies ist nämlich nicht immer ein einfaches Verfahren. Apple hat klare Regeln für das Löschen Ihres Kontos: </p><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px;"><p>• Das Verfahren zum Löschen eines Kontos muss klar, intuitiv und transparent und in der Applikation leicht zu finden (z. B. eine Schaltfläche im Benutzerprofil oder in der Kontoverwaltung) sein.</p><p>• Wir müssen anbieten, den gesamten Kontodatensatz, einschließlich der damit verbundenen personenbezogenen Daten, vollständig zu löschen. Das bloße Angebot, das Konto zu deaktivieren (vorübergehend abzuschalten), reicht nicht aus. </p><p>• Wenn Benutzer die Website besuchen müssen, um die Löschung ihres Kontos abzuschließen, sollten wir einen direkten Link zu einer Seite auf der Website hinzufügen, auf der sie den Vorgang abschließen können. </p><p>• Die Benutzer müssen gut informiert sein. Wenn die Bearbeitung des Löschantrags länger dauert, müssen wir sie darüber informieren. </p><p>• Wenn die App Einkäufe in der Applikation unterstützt, müssen wir den Benutzern klar machen, wie spätere Abrechnungen und Auflösungen des Kontos ablaufen werden. </p><p>• Alle Apps müssen einen leicht zugänglichen Link zu den Datenschutzrichtlinien in der Beschreibung auf App Store Connect innerhalb der Applikation enthalten. </p><p>• Und nicht zuletzt sind die geltenden gesetzlichen Anforderungen an die Verarbeitung und Speicherung der personenbezogenen Daten des Kunden einzuhalten. Und auch für das Löschen. Dazu gehört auch die Einhaltung lokaler Gesetze - in unserem Fall der geltenden GDPR-Richtlinie.</p></blockquote><p><a href="/de/" target="_blank">Cleverlance</a> als Technologieunternehmen hilft ihren Kunden, diese Anforderungen zu erfüllen. Als Anbieter von mobilen Applikationen haben wir dieses Problem erfolgreich gelöst, zum Beispiel bei der mobilen Applikation <a href="https://apps.apple.com/cz/app/my%C5%A1koda/id1161648654?l=cs" target="_blank">MyŠkoda</a> der Gesellschaft ŠKODA AUTO a.s. Genau nach der GDPR-Richtlinie kann der Kunde hier in seinem Profil sein Konto vollständig löschen, einschließlich seiner personenbezogenen Daten. Allerdings muss er zunächst seine Fahrzeuge abschalten, die er über die App steuert. </p><p>Im Bankwesen ist die Situation ein wenig anders. Obwohl der Benutzer sein Konto und den Zugang zur mobilen App löschen kann, bleiben seine Produkte in der Bank unberührt. Ebenso wie personenbezogene Daten, die aufgrund des berechtigten Interesses an der Verarbeitung personenbezogener Daten und der Erfüllung einer legislativen Pflicht in den Systemen verbleiben müssen. Der Benutzer kann so sein Konto in der App löschen und somit die Nutzung der App einstellen. Aber er bleibt ein vollwertiger Kunde der Bank.</p><h3>Was sagt Google dazu?</h3><p>Und was sagt ein anderer Gigant, Google, dazu? Die Regeln für die Ausstellung von Apps bei Google Play besagen, dass die App transparent sein und den Benutzer darüber informieren muss, wie sie seine personenbezogenen Daten verarbeitet. Sie verbieten ein offenkundig betrügerisches oder unehrliches Verhalten. Google hat sich jedoch noch nicht dazu durchgerungen, vorzuschreiben, dass jede Applikation, die ein Benutzerkonto einrichtet, auch die Löschung dieses Kontos zulassen muss. </p><p>Dieser Schritt von Apple wird sicherlich die Transparenz und Fairness von Apps gegenüber ihren Benutzern verbessern. Es ist ein positiver Schritt in Richtung einer ehrlicheren elektronischen Welt. </p><h3>Empfehlungen für Entwickler </h3><p>Für die Implementierung der neuen Kontolöschungsfunktion empfehle ich, eine separate Freigabe nach diesem Datum zu planen. Apple wird wahrscheinlich die Funktionalität gründlich überprüfen und es könnte so passieren, dass sich die Veröffentlichung der neuen Version verzögern wird. Dies könnte sich nachteilig auf andere wichtige neue Funktionen der App auswirken, wenn sie gleichzeitig mit dieser Freigabe veröffentlicht würden. Und die Benutzer warten nicht gern.<br></p>
Entwicklung von Multiplattform-Mobil- und Webanwendungen	https://cleverlance.de/de/blog/Seiten/Multiplatform.aspx	Entwicklung von Multiplattform-Mobil- und Webanwendungen	<p>Möchten Sie Ihre eigene mobile Anwendung? Es ist jedem klar, dass man sowohl an die Android- als auch an die iOS-Plattform denken muss, eine davon reicht nicht aus. Und oft kommen wir nicht ohne eine Webschnittstelle aus. Praktisch seit dem Aufkommen der mobilen Geräte auf dem Markt hört man jedoch, dass es teuer ist, für jede Plattform separat zu entwickeln. Aus diesem Grund haben verschiedene Unternehmen versucht, Alternativen in Form von Multiplattform-Lösungen anzubieten, aber keine von ihnen hat sich wirklich durchgesetzt. Sie hatten ihre Tücken, waren unnötig komplex und hielten ein Unternehmen, das seine mobilen Anwendungen flexibel entwickeln will, in einem imaginären „Käfig“ begrenzter Möglichkeiten. Aus diesem Grund wird für B2C-Anwendungen oft die native Entwicklung bevorzugt, da sie nicht durch UX, Animationsmöglichkeiten und andere Details eingeschränkt sind, die für diese Zielgruppe sehr wichtig sind</p><p>In den letzten Jahren haben sich jedoch mobile Unternehmensanwendungen herausgebildet, bei denen nicht die perfekte Benutzeroberfläche und das Design im Vordergrund stehen, sondern die Funktionalität, die Benutzerfreundlichkeit und vor allem die Geschwindigkeit der Bereitstellung und die Flexibilität der Anpassung. Und hier zeigte sich Spielraum für den Einsatz ausgewählter Technologien, die eine plattformübergreifende Nutzung ermöglichen. Natürlich unter Einhaltung bestimmter Regeln.<br></p><p>Bei Cleverlance haben sich drei Arten der Implementierung bewährt. Wenn wir es stark vereinfachen, müssen wir gleich zu Beginn entscheiden, wie robust das Back-End mit MOA (Microservice Oriented Architecture) ist oder ob wir es erstellen müssen, und dann, ob die Anwendung nicht zu viel Geschäftslogik haben wird, sondern eher eine reine Präsentationsebene sein wird. In diesem Fall ist es vorteilhaft, Flutter zu verwenden. Wenn wir Warteschlangen für die Synchronisation, Geschäftslogik und die Einführung einer gewissen Komplexität außerhalb von Formularen in unserer Anwendung benötigen, ist Kotlin Multiplatform eine gute Lösung. Oder es gibt einen dritten Player = PWA (Progressive Web Applications), der die starke Basis moderner Browser nutzt.<br></p><h2>Flutter<br><br></h2><p>Wir betrachten Flutter als eine echte Multi-Channel-Display-Ebene, mit der wir mobile, Web- und Desktop-Anwendungen erstellen können. Es handelt sich um eine flexible Lösung, mit der sich B2B- und unter bestimmten Voraussetzungen auch B2C-Anwendungen effizient gestalten lassen. Ein Beispiel ist eine mobile Anwendung für BMW. Aber wenn Sie keine Probleme lösen wollen, ist es besser, sich auf das Backend zu verlassen und ihm das „Denken“ zu überlassen.<br></p><h2>Kotlin Multiplattform<br></h2><p>Eine weitere Option ist die Multiplattformsprache Kotlin. Der Vorteil ist, dass Sie eine „native App“ für Android programmieren, von der ein Teil auch für iOS verwendet werden kann. Meistens sprechen wir über die Geschäftslogik und die Integrationsebene, was uns später in der QA-Phase eine Menge Zeit erspart. Die Visualisierungsebene ist nativ für iOS und Android programmiert, so dass es möglich ist, das „Look & Feel“ der jeweiligen Plattform zu erreichen und die „One Code Base“ für die unsichtbaren Teile der App zu übernehmen. Bei einigen Projekten können bis zu 70-80 % des Codes auf diese Weise verwendet werden.<br></p><h2>PWA<br></h2><p>Progressive Web Applications gehören zu einem der neuesten Trends in der Entwicklung von Webanwendungen. Bis zu einem gewissen Grad verwischen sie die Grenzen zwischen webbasierten und nativen mobilen Anwendungen, indem sie Offline-Arbeit, den Zugriff auf die Gerätehardware und die Möglichkeit, Push-Benachrichtigungen zu empfangen, ermöglichen. Sie vereinen das Beste aus beiden Welten, nur begrenzt durch die Einschränkungen des Browsers. Dies eröffnet eine breite Palette von Funktionalitäten, zum Beispiel können bereits eine Kamera oder einen Fingerabdruckleser in der Basis verwendet werden. Das Erfordernis, tiefer gehende Gerätefunktionen zu nutzen, kann mit einer nativen „Hülle“, der sie verfügbar macht, effizient erfüllt werden. PWA-Apps können in allen gängigen App-Stores (Google Play, Apple Store, Huawei AppGallery und Microsoft Store) platziert werden und auf Android-, iOS- und Windows-Geräten laufen.<br></p><h2>Wo funktioniert es?<br></h2><p>Als Anbieter wollen wir natürlich neben den Standard-Entwicklungstechnologien auch „neue“ Technologien anbieten, und es freut uns umso mehr, dass unsere Kunden, die von Anfang an nach Kotlin Multiplatform gefragt haben, zu uns kommen. Als Beispiel sei hier das amerikanische Unternehmen Globstar genannt, für das die Aricoma-Gruppe eine mobile Anwendung für die Konfiguration und Verwaltung von Satellitenmodems für den Internetanschluss liefert. Der Einsatz von Kotlin Multiplatform war in diesem Fall wirklich erfolgreich, da es sich um eine Anwendung handelte, die in Bezug auf Integration und Datentransfer anspruchsvoll war. Darüber hinaus erfolgt die Integration über BLE (Bluetooth Low Energy), das Dutzende von Geräten gleichzeitig bedienen und beispielsweise deren Firmware aktualisieren kann. Die Technologie hat sowohl den Kunden als auch uns als Anbieter überzeugt, und es ist uns gelungen, eine partnerschaftliche Zusammenarbeit bei der Entwicklung der Anwendung aufzubauen.<br></p><p>Wir haben die PWA-Technologie zum Beispiel im Online-Service für SAZKAmobil-Kunden erfolgreich eingesetzt. Ihr Hauptvorteil ist die extrem verkürzte Time-To-Market (die Zeit, die benötigt wird, um neue Funktionen auf den Markt zu bringen) und die große Zahl von Entwicklern, die diese Technologie beherrschen. Darüber hinaus eignen sich PWAs am besten für Anwendungen, bei denen die Nutzung der Komponenten des Geräts selbst wenig im Vordergrund steht, z. B. für interne Unternehmensanwendungen, die von Außendienstmitarbeitern oder Produktionsmitarbeitern genutzt werden.<br></p><p>Wenn Sie an technischen Details interessiert sind, lesen Sie diesen Artikel in unserem Blog mobile it, in dem Sie auch erfahren, worauf Sie bei der Auswahl einer Technologie für die Entwicklung einer mobilen Anwendung achten sollten.<br></p>
Entwicklungsregeln für mehr Produktivität	https://cleverlance.de/de/blog/Seiten/development_rules_for_better_productivity.aspx	Entwicklungsregeln für mehr Produktivität	<p>Jedes Projekt hat seine eigenen Regeln für die Entwicklung. Meistens beschreiben diese Regeln Entwicklungspraktiken und die Arbeit mit einem Versionskontrollsystem (VCS), das die Art und Weise des Testens und der Bereitstellung des Produkts, die Struktur, die Architektur des Projekts und den Codestil umreißt, aber die Regeln können auch die Grundlagen der sicheren Entwicklung und mehr umfassen.</p><p>Diese Regeln können ungeschrieben sein, werden aber in der Regel in einem gemeinsamen Raum definiert und festgehalten, wo sie für alle zugänglich sind. Noch wichtiger ist jedoch, wie diese Regeln in der Praxis angewendet und durchgesetzt werden.</p><h3>Die Weisen wissen es am besten</h3><p>Manche Leute glauben, dass Programmieren in Paaren oder Code Review eine geeignete Plattform für die Überarbeitung von Regeln ist. Die Teilnehmer können sich auf die Anwendung der Regeln einigen oder sie je nach Kontext ändern. Wenn Entwickler dies gewissenhaft angehen, kann das Ergebnis ein Projekt sein, das vielleicht nicht konsequent ist, aber dessen einzelne Teile in bestmöglicher Verfassung sind.</p><p>Dieser Ansatz kann zu Beginn eines Projekts für kurze Zeit zu besseren Ergebnissen führen, aber seine Unzulänglichkeiten werden mit der Zeit zum Vorschein kommen. Auch erfahrene Entwickler und technische Leiter sind nur Menschen. Sie können gelegentlich müde werden oder einfach etwas übersehen. So häufen sich kleinere Abweichungen von den vereinbarten Regeln und bilden die so genannten technischen Schulden.</p><h3>Zeitfahren</h3><p>Der nächste Aspekt, der sich in der Zeit widerspiegelt, ist die Ausweitung des Projekts, und zwar auf zwei Ebenen.</p><p>Der erste ist die Erweiterung des Produkts selbst. Wenn das Produkt erfolgreich wird, erhält es neue und anspruchsvollere Funktionen, die beginnen, zuvor einfachere und unabhängige Funktionen zu verbinden. Hier begannen die kleinen Abweichungen und Inkonsistenzen aufzutauchen, die zunächst für die Funktionalität gut schienen. Das Problem ist, dass jetzt mehr dieser Funktionen miteinander kompatibel sein müssen, aber sie sind noch nicht bereit dafür.</p><p>Dies ist nicht nur ein Problem der Inkompatibilität von Funktionen. Oft versuchen Entwickler in guter Absicht, vorhandene Komponenten so weit wie möglich wiederzuverwenden, um Code-Duplikationen zu vermeiden. Sie vergessen die Regel, dass wir eine Komponente wiederverwenden können, wenn wir das gleiche Verhalten erwarten, aber auch die gleichen Gründe für eine Änderung haben. Wenn diese Bedingung nicht erfüllt ist, wird das Prinzip der einzigen Verantwortung Single Responsibility Principle verletzt und das Projekt hat eine geringe Flexibilität für zukünftige Entwicklungen.</p><p>Die zweite Ebene der Projekterweiterung ist das Entwicklungsteam selbst. Sobald das Produkt erfolgreich wird, führt dies früher oder später zur Erweiterung des Entwicklungsteams. Die neuen Teammitglieder kennen nicht die gesamte Entstehungsgeschichte des Projekts und haben daher nicht das gleiche Verständnis für die Regeln wie die älteren Mitglieder, die die Regeln selbst aufgestellt haben. Dies führt zu Missverständnissen und einer weiteren geringfügigen Abweichung von den vereinbarten Regeln, was wiederum die technische Schuld erhöht. Ein Nebeneffekt ist ein erhöhter Kommunikationsbedarf bei der Paarprogrammierung und der Codeüberprüfung, was die Gesamtproduktivität des Teams verringert.</p><p>Diese Probleme bei der Projekterweiterung sind nicht auf große Entwicklungsteams beschränkt, sondern treten auch bei kleineren Teams auf. Wenn z. B. ein Zweierteam zwei neue Entwickler einführt, ändert sich die Produktivität des Teams möglicherweise kaum. Und all dies ist auf die oben beschriebenen Umstände zurückzuführen. Ohne die Ursache des Problems zu kennen, kann dies zu einer weiteren blinden „Verstärkung“ des Teams führen und es noch schlimmer machen.</p><h3>Nach dem Stolpern kommt der Sturz</h3><p>Wenn ein Entwicklungsteam wiederholt vereinbarte Funktionen nicht fertig stellt oder aus technischen Gründen nicht in der Lage ist, eine neue Version eines Produkts zu veröffentlichen, tritt eines der kritischen Szenarien ein. An diesem Punkt werden Personen außerhalb des Standardentwicklungsteams in die Suche nach der Ursache und die Lösung des Problems einbezogen. Gemeinsam arbeiten sie unter Stress und mit viel menschlichem Einsatz daran, die Entwicklung wieder in den Griff zu bekommen. Erst zu diesem Zeitpunkt findet eine rückblickende Analyse statt, um die wahren Ursachen der Probleme aufzudecken.</p><p>Die Begleitsymptome und die Quelle dieser Probleme haben sich jedoch schon lange im Voraus manifestiert. Ein paar subtile Situationen als Beispiele:</p><ul><li>Ein Entwickler erhält bei der Codeüberprüfung wiederholt Rückmeldungen über falsche Benennungen.<br></li><li>Ein Ticket im Fehlerverfolgungssystem Issue Tracker des Projekts enthält aufgrund eines Tippfehlers im Quellcode des Projekts keinen Verweis auf die Implementierung.<br></li><li>Eine Funktion, die sich noch in der Entwicklung befindet, ist in der Testversion der Anwendung aktiviert.<br></li></ul><p>Oft sehen sie nur wie kleine Unklarheiten, individuelle Fehler oder Unfälle aus, die manchmal während der Entwicklung passieren. Wenn sich diese Situationen wiederholen, nehmen die negativen Auswirkungen auf die Produktivität des Teams und die Fehlerquote des Projekts schnell zu. Aber wenn wir sie genau betrachten, können wir Leerstellen in unserer Arbeitsweise erkennen, die eigentlich leicht zu füllen sind und das Problem ein für alle Mal lösen.</p><h3>Live-Regeln</h3><p>Um die oben genannten Probleme zu vermeiden, brauchen wir klar definierte Entwicklungsregeln. Ihr Inhalt sollte die individuellen Bedürfnisse eines jeden Projekts widerspiegeln. Für einige Projekte wird es entscheidend sein, die Zusammenarbeit mit dem QA-Team klar zu definieren und das Release-Management des Produkts zu beschreiben, während andere Teams sich mehr auf die Zusammenarbeit zwischen den Entwicklern innerhalb der Entwicklung selbst konzentrieren werden.</p><p>Je detaillierter und spezifischer die Regeln sind, desto besser werden sie sich auf die Arbeit des Teams auswirken. Es ist daher nicht möglich, von einer allgemeinen Vorlage auszugehen, sondern jedes Team muss diese Regeln selbst festlegen.</p><p>Manchmal kommt es vor, dass ein Team zu Beginn eines Projekts einige grundlegende Regeln allgemeiner Art festlegt, diese aber im Laufe der Zeit nicht weiterentwickelt. Auf diese Weise geben die Regeln nie genau wieder, wie das Team arbeitet, und selbst das wenige, was sie enthalten, wird mit der Zeit bedeutungslos.</p><p>Nichts ist in Stein gemeißelt, und selbst ein etabliertes Team ändert im Laufe der Zeit die verwendeten Tools oder entdeckt neue Arbeitsweisen. All diese natürlichen Veränderungen haben Auswirkungen auf die Teamregeln. Sie bleiben lebendig und gültig.</p><h3>Alles automatisieren</h3><p>In der Einleitung haben wir kurz erörtert, wie die Regeln aussehen können und welche Möglichkeiten es gibt, sie anzuwenden. Um möglichst effektiv zu sein, müssen die Regeln automatisch angewendet werden, ohne dass eine manuelle Kontrolle erforderlich ist. Ebenso müssen wir über die Produktivität des Teams nachdenken, die durch den Einfluss einer großen Anzahl von repressiven Regeln verringert werden kann. Daher sind Werkzeuge, die Teammitgliedern helfen, bestimmte Schritte zu automatisieren, ein wesentlicher Bestandteil dieses Prozesses. Diese Werkzeuge sind zeitsparend und ihr Output entspricht natürlich den festgelegten Regeln.</p><p>In der Praxis ist es so üblich, dass der Code-Stil oder die Projektarchitektur durch automatisierte Regeln durchgesetzt wird, aber gleichzeitig gibt es Code-Vorlagen und Formatierungswerkzeuge, die den Entwicklern die meiste Arbeit abnehmen, ohne dass sie sich dessen bewusst sind.</p><p>Die meisten Problemverfolgungswerkzeuge bieten eine programmatische Schnittstelle, so dass es einfach ist, die Erstellung eines neuen Entwicklungszweigs im VCS zu automatisieren, so dass der neue Code mit einem bestimmten Problem verknüpft wird. Ebenso ist es möglich, einen VCS-Hook zu erstellen, der prüft, ob ein entsprechendes Issue für einen bestimmten Branch oder Commit existiert, wenn der Entwickler den neuen Entwicklungszweig manuell erstellt hat.</p><p>Das Freigabemanagement ist ein ganz eigenes Kapitel. Bei der Freigabe einer neuen Version eines Produkts sind in der Regel routinemäßige und klar definierte Schritte erforderlich. Hier gibt uns die Automatisierung nicht nur die Gewissheit, dass die Freigabe einer neuen Version ordnungsgemäß und fehlerfrei erfolgt, sondern sie beschleunigt auch den Prozess und ermöglicht einen einfachen Wissensaustausch zwischen den Teammitgliedern. Ein Bonus ist die einfache Automatisierung der Erstellung von Versionshinweisen, auch wenn diese nur für interne Tester bestimmt sind.</p><p>Prüfer werden auch die Möglichkeit zu schätzen wissen, das Produkt für interne Tests zu konfigurieren. Sie können ein Funktionskennzeichen umschalten, die Umgebung konfigurieren, in der die Anwendung ausgeführt wird, oder Szenarien simulieren, die manuell nur schwer zu realisieren sind. Neben dem unbestreitbaren Nutzen dieser Testwerkzeuge für die Tester haben sie auch Vorteile für die Entwickler selbst. Sie müssen nicht mehr Versionen des Produkts als unbedingt nötig pflegen, was ihnen Zeit spart, da die Build-Logik grundlegend vereinfacht wird.</p><p>Dies ist nur eine kleine Auswahl der Regeln, die wir bei Projekten häufig antreffen. Die Möglichkeiten sind jedoch bei weitem nicht erschöpfend, sei es in Bezug auf die Menge, die Tiefe oder die Ausgereiftheit.</p><h3>Wie weit soll es gehen?</h3><p>Einige Regeln mögen so streng erscheinen, dass sie Ihre Arbeitsfreiheit einschränken. Andere können so vage erscheinen, dass sie nicht die gewünschte Wirkung haben. Das ist in Ordnung. Jedes Team und jedes Mitglied hat andere Bedürfnisse und ein anderes Risikoverständnis. All dies hat Auswirkungen auf die Form der Vorschriften.</p><p>In unseren Projekten versuchen wir, die Regeln strikt nach Vorgabe zu definieren. Wenn wir mit der Zeit feststellen, dass sie uns zu sehr einschränken, ist es leicht, die Regel zu verallgemeinern oder sie in eine Empfehlung oder Warnung umzuwandeln. Der umgekehrte Weg ist wesentlich komplizierter, weil sich das Team und seine Arbeitsweise bereits an die allgemeinere Regel gewöhnt haben, so dass eine Änderung möglicherweise nicht über Nacht möglich ist.</p><h3>Nachhaltigkeit des Projekts</h3><p>Bei der Entwicklung eines Produkts berücksichtigen wir neben den kurzfristigen Zielen, die notwendigen Funktionen zu schaffen, immer auch die Idee der langfristigen Nachhaltigkeit und Lebensfähigkeit des Projekts. Gerade in der mobilen Entwicklung ist die Meinung, dass ein Projekt alle 2-3 Jahre verworfen und von Grund auf neu entwickelt werden sollte, keine Ausnahme. Dies ist eine echte Katastrophe für die Produktivität.</p><p>In unserem Portfolio haben wir Anwendungen, die mehr als 7 Jahre alt sind und im Laufe ihrer Lebensdauer mehrere größere Änderungen erfahren haben. Auf geschäftlicher Ebene hat sich die Ausrichtung auf einen anderen Nutzerkreis geändert und wurde mit Änderungen bei Markenbildung und Design in Einklang gebracht. Auf technischer Ebene würde ich den Wechsel von der Programmiersprache Java zu Kotlin erwähnen, oder den Übergang der asynchronen Arbeit von einer benutzerdefinierten imperativen Lösung zu einem reaktiven Ansatz über RxJava und später Kotlin Coroutines. Trotzdem besteht das Entwicklungsteam immer noch aus nur zwei Personen (während sie sich ständig verändern) und liefert in gleichem Tempo neue Funktionalitäten entsprechend den Geschäftsanforderungen.</p><p>Klar definierte Entwicklungsregeln und die durch sie erzwungene Konsistenz haben in jeder Hinsicht einen großen Einfluss auf die Qualität des Endprodukts.</p><p>Nächstes Mal werden wir uns genauer ansehen, wie einige Regeln umgesetzt werden können und welche Werkzeuge uns dafür zur Verfügung stehen.<br></p>
SwiftUI und Architektur: Zustand	https://cleverlance.de/de/blog/Seiten/swift-ui-and-architecture-state.aspx	SwiftUI und Architektur: Zustand	<p>In der mobilen Welt ist eine neue Ära angebrochen. Zumindest im Kontext von UI-Frameworks. Was bedeutet das für Ihr Projekt? Wird Ihre Architektur standhalten und eine schrittweise Einführung ermöglichen? Oder werden Sie Ihr Projekt komplett neu schreiben müssen?<br></p><h1>Willkommen in der neuen alten Welt</h1><p>Der Eckpfeiler der Entwicklung von Benutzeroberflächen für iOS ist seit den Anfängen UIKit (oder AppKit für macOS). Es bietet einen Mechanismus zum Definieren von Fenster- und Ansichtshierarchien, zum Navigieren zwischen Szenen, zum Rendern von Inhalten auf dem Bildschirm und verfügt über Tools für die Handhabung von Benutzerinteraktionen. UIKit wurde vor über einem Jahrzehnt in der Objective-C-Welt entwickelt und nutzt Prinzipien, die damals üblich waren, wie Delegaten und Vererbung. Funktionale Elemente moderner Sprachen wie Swift führen natürlich zu einem deklarativen Programmierparadigma, und genau hier setzt SwiftUI an.</p><p>Das SwiftUI-Framework wurde auf der WWDC 2019 angekündigt und führt den oben erwähnten deklarativen Ansatz zum Schreiben von UI-Code ein, bevorzugt Komposition, verwendet Wertetypen in großem Umfang und bietet Optimierungen unter der Haube. Es ändert komplett die Art und Weise, wie wir über die Benutzeroberfläche nachdenken und wie wir den UI-Code schreiben. Die Prinzipien und das Design von SwiftUI sind von React aus der Javascript-Welt inspiriert, das auf das Jahr 2013 zurückgeht. Unser Dank und Applaus gebührt daher der JS-Community für die Ausarbeitung der Macken! <br></p><p>In SwiftUI geschriebener Code ist plattformübergreifend und kann auf den Plattformen tvOS, macOS und watchOS bereitgestellt werden. Die Interoperabilität mit UIKit und AppKit erleichtert den Übergang noch weiter.<br></p><p>Interessanterweise wurde ein sehr ähnlicher Ansatz auch in der Android-Welt eingeführt, bekannt als Jetpack Compose. Wenn Sie sich mehr dafür interessieren, ist es in den Beiträgen „Jetpack Compose: Was Sie wissen müssen“, <a href="https://www.mobileit.cz/Blog/Pages/compose-1.aspx">Teil 1</a> und <a href="https://www.mobileit.cz/Blog/Pages/compose-2.aspx">Teil 2</a>, gut beschrieben, obwohl sich seitdem zwangsläufig einige Dinge geändert haben.<br></p><p>Beide Technologien sind für den produktiven Einsatz bereit. Konzentrieren wir uns darauf, was die Ankunft von SwiftUI aus architektonischer Sicht bedeutet, insbesondere in Bezug auf den Zustand. <br></p><h1>SwiftUI und Zustand</h1><p>In SwiftUI ist eine Ansicht eine Funktion eines Zustands, nicht einer Folge von Ereignissen, die einen internen, gekapselten Zustand verändern. Was bedeutet das in der Praxis?</p><p>SwiftUI beobachtet den Zustand der Benutzeroberfläche und löst bei jeder Änderung ein neues Rendering der Ansicht aus (mit einigen intelligenten Optimierungen unter der Haube). Dies geschieht durch Property-Wrapper, die UI-Statusobjekte und/oder Combine-Publisher annotieren. Es liegt nur an Ihnen, den Zustand zu modellieren, zu halten, zu transformieren, zu komponieren und zu verteilen. <br></p><p>Der Zustand kann aus vielen verschiedenen Blickwinkeln wahrgenommen werden, zum Beispiel: <br></p><div><ul><li><p>was auf dem Bildschirm gerendert wird, </p></li><li><p>Daten, die im Speicher gehalten werden,</p></li><li><p>Zustände, die über mehrere Bildschirme oder Funktionen verteilt sind. </p></li></ul></div><p>Es ist von entscheidender Bedeutung, diese Arten von Zuständen korrekt voneinander zu trennen, da einige eine begrenzte Rolle in einem lediglich gekapselten Kontext spielen, während andere sich über mehrere Kontexte erstrecken und als Quelle der Wahrheit dienen können.</p><p>Eine solche Quelle der Wahrheit muss eindeutig definiert und gemeinsam genutzt werden. Werfen wir einen Blick darauf, wie die derzeit meist diskutierten Architekturen dies angehen.<br></p><h3>MVx-Architekturen<br></h3><p>MVC wurde früher am häufigsten in iOS-Anwendungen verwendet. Mit dem Aufkommen der funktionalen reaktiven Programmierung geriet es ins Abseits und wurde durch MVVM und dessen Derivat MVVM-C ersetzt, das eine zusätzliche Schicht für die Navigation vorsieht. Der Platz für View- und Präsentationslogik ist in diesen Fällen klar, aber die Modellschicht hat zu viele Verantwortlichkeiten, was zu großen Komponenten führen kann, die zu viele Belange haben. In einem anderen Fall kann die Modellschicht nur Domänenobjekte enthalten, während die Präsentationsschicht sich mit der Vernetzung, der Speicherung, der Geschäftslogik und der Umwandlung von Domänenobjekten in renderbare Objekte für den View auf der einen Seite sowie der Verarbeitung von Aktionen des Views auf der anderen Seite befasst. Riesige ViewController mit vielen Verantwortlichkeiten führten zu dem Scherz, dass MVC die Abkürzung für Massive-View-Controller ist.<br></p><p>MVx-Architekturen sind ihrer Definition nach nicht ausreichend, um das gesamte System zu entwerfen. Sie sind lediglich ein Muster für den Präsentationsteil des Systems. Saubere und robuste Anwendungen können mit MVVM als einzigem Architekturwerkzeug in Ihrem Werkzeugkasten geschrieben werden, aber es erfordert strenge Disziplin und eine angemessene Dekomposition. Die verwendete Architektur verzweigt sich oft in etwas Anspruchsvolleres als eine 3-Schichten-Architektur, aber ohne klare Grenzen, die irgendwo zwischen den Zeilen definiert sind.<br></p><h3>Redux<br></h3><p>Da die SwiftUI von React aus der Javascript-Welt inspiriert ist, wo React und Redux oft Hand in Hand gehen, liegt es nahe, darüber nachzudenken, wie sich dies in der Entwicklung mobiler Anwendungen widerspiegelt.<br></p><p>Redux ist ein Mechanismus zum Aktualisieren und Verteilen von Zuständen. Es kann nicht als „Architektur“ betrachtet werden, da es keine Antworten auf die wichtigen Fragen gibt.<br></p><div><ul><li><p>Wie kann die Anwendung vor der Außenwelt geschützt werden?</p></li><li><p>Wie lassen sich Technologien und Abhängigkeiten von Drittanbietern einfach austauschen?</p></li><li><p>Wie definiert man strikte Grenzen zur Isolierung von Funktionen? </p></li><li><p>Wo sind die Geschäftsregeln definiert?</p></li><li><p>Welche Teile befassen sich mit der Navigation, der Präsentation, der Vernetzung, der Speicherung, der Benutzereingabe und so weiter?</p></li></ul></div><p>Diese diskutierten Architekturen gehen nicht vollständig auf die Modellierung und die gemeinsame Nutzung von Zuständen ein. Sie werden oft entweder auf eine schlechte Art und Weise verwendet, die nicht sehr lesbar und nachhaltig ist, oder auf eine Art und Weise, die von Natur aus zu einer komplexeren Architektur mit einer lockeren Definition der Verantwortlichkeiten führt.</p><p>Obwohl SwiftUI ein neuer Spieler auf dem mobilen Spielplatz ist, ist die Verwaltung von Zuständen definitiv nicht neu. Wir werden sehen, ob die alten und traditionellen Prinzipien in dieser neuen Welt noch etwas zu bieten haben.<br></p><h1>Lektionen aus der Geschichte</h1><p>Es gibt viele Muster und Prinzipien, die zeitlos sind, nämlich zwei, die es ermöglichen, den Zustand auf transparente Weise zu speichern und zu verteilen.</p><h3>Repository-Muster<br></h3><p>Ein Repository ist ein Entwurfsmuster, das die Datenzugriffslogik von der Geschäftszugriffslogik abstrahiert, indem es eine sammlungsartige Schnittstelle für den Zugriff auf Geschäftseinheiten bereitstellt. Die eigentliche Implementierung der Schnittstelle kann mit der Datenbank, der REST-API und anderen Anforderungen Ihres Projekts kommunizieren, solange ihre Details nicht an die Schnittstelle der Geschäftsdomäne weitergegeben werden.<br></p><p>Ein solches Repository könnte leicht die Quelle der Wahrheit für jede Funktion sein. Repositories halten natürlich den Status, aber sehen wir uns an, wie man denselben Status auf mehrere Teile der Anwendung verteilt.<br></p><h3>Injektion von Abhängigkeiten<br></h3><p>Die gemeinsame Nutzung des Zustands von Funktionen ist so einfach wie die gemeinsame Nutzung derselben Repository-Instanz. Frameworks für Dependency Injection helfen bei der Organisation des Abhängigkeitsgraphen. Einige verwenden Service-Locator-Muster, die die Instanzauflösung hinter einer Abstraktionsschicht abstrahieren. Dadurch wird der Boilerplate-Code reduziert, der sonst bei manueller Dependency Injection erforderlich wäre. Die Auflösung kann zu Laufzeitabstürzen führen, wenn einige angeforderte Instanzen nicht registriert sind. Das ist ein Nachteil, den man aber mit Unit-Tests in den Griff bekommen kann. <br></p><p><br></p><p>Sie können ein gemeinsames Repository auch mit reiner Sprache ohne Abhängigkeits-Frameworks implementieren. Das Prinzip bleibt in beiden Fällen das gleiche.<br></p><h1>Architektur und Zustand<br></h1><p>Es ist wichtig, Ihr System so zu gestalten<br></p><div><ul><li><p>dass es weich und anpassungsfähig ist, damit Sie gewünschte Änderungen schnell umsetzen können,</p></li><li><p>aber auch robust genug, damit Sie sicher sein können, dass diese Änderungen kein unerwartetes Verhalten hervorrufen werden, </p></li><li><p>und klar genug, damit man sich leicht zurechtfindet und es einem nicht über den Kopf wächst.</p></li></ul></div><p>Um dies zu erreichen, ist die Entkopplung entscheidend. Um Ansichten, Ansichtsmodelle, Szenen und so weiter zu entkoppeln, müssen Sie herausfinden, wie Sie die Quelle der Wahrheit in der gesamten Anwendung gemeinsam nutzen können. Wenn Sie dies falsch handhaben oder nicht viel über den Zustand nachdenken, werden Sie es selbst mit UIKit-Anwendungen schwer haben, da dies zu einer Kopplung führt, die in Code resultiert, der schwer zu testen, zu lesen und zu verstehen ist:<br></p><p><img src="/de/blog/PublishingImages/Articles/MobileIt/swift-ui-and-state-02.png" data-themekey="#" alt="" /></p><p>ViewModels machen in diesem Fall viel zu viel. Sie geben untereinander Zustände weiter, was sie schwer testbar und schwer lesbar macht. Die Quelle der Wahrheit für diese Daten geht ebenfalls verloren, es ist unklar, woher der Zustand stammt und wem er gehört.</p><p>Die Zustandsverwaltung ist nichts Neues, das mit SwiftUI eingeführt wurde, sondern existiert schon seit Jahrzehnten, und es gibt keine spezifischen neuen Architekturanforderungen. Wenn Sie Funktionen unabhängig machen, Ihre Abhängigkeiten einfügen, testen und die Quelle der Wahrheit mit einem Repository-Muster definieren, können Sie Ihr System so gestalten, dass es leichter zu warten und zu erweitern ist, unabhängig davon, welches UI-Framework Sie wählen.<br></p> <p><img src="/de/blog/PublishingImages/Articles/MobileIt/swift-ui-and-state-01.png" data-themekey="#" alt="" style="margin:5px;" />In diesem Beispiel gibt es eine strikte Grenze zwischen den Funktionen. ViewModels transformieren nur Daten und Aktionen zwischen Views und UseCases. Für jede Funktion gibt es eine klare Quelle der Wahrheit. Die Isolierung führt zu Wiederverwendbarkeit und Testbarkeit.</p><div><div><p>State Management war schon immer wichtig in der App-Entwicklung, leider wurde es oft vernachlässigt oder schlecht gemacht. Deklarative UI-Konzepte bringen nichts Neues, da sie nur explizit betonen, was wichtig ist, um es gut zu handhaben, weil die Ansicht eine Funktion eines Zustands ist.<br></p></div><h1>Alt und neu, zusammen</h1></div><p>Bahnbrechende Technologien wie SwiftUI kommen nicht allzu oft auf den Markt, aber das bedeutet nicht, dass Ihre Anwendung und Architektur vollständig von dieser Technologie abhängig sein und/oder sich von ihr ableiten sollte. Im Gegenteil: Wenn Sie sich an die Trennung von Belangen halten und Ihren Code entkoppeln, erreichen Sie streng definierte Grenzen und können mit der Übernahme dieser Technologien beginnen, ohne den größten Teil Ihrer Anwendung neu schreiben zu müssen, und dies sogar schrittweise tun.<br></p><p>SwiftUI ist eine brandneue Technologie, aber das bedeutet nicht, dass wir nicht von zeitlosen und klassischen Prinzipien profitieren können, die über viele Jahrzehnte geholfen haben, viele Herausforderungen zu bewältigen. Altes und Neues können Hand in Hand gehen und sich gegenseitig ergänzen, damit wir brillante Apps entwickeln können.<br></p><br><br>