Sie haben einen Kurs abgeschlossen, eine Reihe von Videos auf YouTube angesehen oder eine Reihe von Artikeln über die iOS-Entwicklung gelesen und fühlen sich nun bereit, Ihr erstes Lieblingsprojekt zu schreiben.

Erstens: Gut gemacht! Das ist großartig. Du bist cool! 💪

Zweitens ist ein Lieblingsprojekt eine fantastische Steigerung Ihrer Fähigkeiten. Wenn Sie anfangen, etwas auf eigene Faust zu tun, ohne den Anweisungen zu folgen, müssen Sie eine Menge Zeit und Mühe aufwenden, viel googeln, Unmengen neuer Informationen lesen und versuchen, sie zu filtern und genau auf Ihren Fall zuzuschneiden. Kurz gesagt, es ist bereits eine echte Aufgabe, die Sie um das Fünffache steigern wird.

Allerdings ignorieren die meisten Anfänger wichtige Dinge (nicht aus eigener Initiative, sondern ohne zu verstehen, wie wichtig sie sind). In den letzten sechs Monaten war ich aktiv Mentoring und Neuankömmlingen bei ihren Fragen und Problemen zu helfen, einschließlich Lieblingsprojekten.

Ich habe die drei wichtigsten Punkte identifiziert, die Sie als Anfänger in Ihre Must-Have-Liste aufnehmen, beherrschen, verstehen und nutzen sollten.

Zugriffsebene

Zunächst achtet fast niemand auf den private Modifikator. Mittlerweile kann jeder SOLID sofort erklären, wenn man ihn mitten in der Nacht weckt. Nachdem man verschiedene kluge Artikel gelesen hat, versucht man, eine Reihe von Klassen nach der Idee von S (Single Responsibility) zu erstellen.

Und dann ändern sie mit gutem Gewissen die Eigenschaft der class A von class B und umgekehrt.

 class A { var someAValue: Int? } class B { let a = A() func foo() { a.someAValue = 1 } }

Im Allgemeinen, wenn es noch unklar ist, ist hier der Plan: Schreiben Sie immer überall private , und wenn der Compiler sich beschwert – denken Sie darüber nach, ob es in Ordnung ist, von außen auf diese Eigenschaft oder Funktion zuzugreifen? Und wenn ja, entfernen Sie private .

Lassen Sie sich beim Nachdenken von realen Vergleichen leiten. Handelt es sich bei Ihrer Klasse beispielsweise um ein Geschäft, dann sollte das goods selbstverständlich für den externen Kunden zugänglich sein. Aber das moneyInCashRegister kann natürlich nur von einem internen Filialmitarbeiter geändert werden.

Schließlich soll ein Kunde keinen Zugriff auf die Kasse haben, auch nicht mit put , geschweige denn fetch .

Man könnte argumentieren: „Ich verstehe vollkommen gut, welche Eigenschaft berührt werden kann und welche nicht, auch ohne einen private Modifikator.“ Das Schreiben von Zugriffsebenenmodifikatoren ist jedoch Teil des Designs. Ich bin sicher, Sie würden keinen Bauplan für ein Haus erstellen, dessen Tür im dritten Stock nach draußen führt.

Und dann denken Sie daran, es nicht zu öffnen. Schließlich ist es wahrscheinlich, dass auch andere Ihren Code verwenden.

Eine ähnliche Situation besteht übrigens auch mit var und let . Auch hier sollten Sie immer let verwenden, es sei denn, Sie sind sich sofort sicher, dass Sie den Wert ändern werden.

Einfachheit der Architektur

Mir ist eine Tendenz aufgefallen, dass Anfänger versuchen, alles im Voraus zu planen. Obwohl dies lobenswert ist, machen Entwickler aufgrund mangelnder Erfahrung häufig Fehler. Sie bereiten übermäßig komplexe Manager vor (normalerweise kopiert von Paketüberfluss ) mit vielen komplizierten Methoden, die sie schließlich nie anwenden. Dadurch wächst die Menge und Komplexität des Codes.

Statt eines scheinbar bequemen, vorgefertigten Dienstes hatte unser Programmierer am Ende nur Probleme und Missverständnisse. Dasselbe gilt auch für die Architektur.

Lassen Sie mich Sie kurz durch die Geschichte der Programmierung führen, um meinen Standpunkt zu verdeutlichen. Ende der 1960er Jahre, als die Beliebtheit von Programmen zunahm, nahm auch die Größe der Programme zu. Wie Sie verstehen, bedeutet eine größere Programmgröße mehr Codezeilen, was zu erhöhter Komplexität und Schwierigkeiten beim Verständnis des Programms führt.

Um dieses Problem anzugehen, entstand die strukturierte Programmierung – Funktionen und Verfahren, die es ermöglichten, Programme in kleinere, überschaubare Teile zu unterteilen. Der Code wurde modular, wiederverwendbar und verständlicher.

Das Aufkommen der Strukturierung führte zu einem weiteren Wachstum der Programme, bis sie erneut ihre Grenzen in Größe und Komplexität erreichten. Daher wurde Ende der 1970er und Anfang der 1980er Jahre der objektorientierte Programmieransatz entwickelt. Diese Lösung ermöglichte die Schaffung flexibler und skalierbarer Systeme für immer komplexere Aufgaben.

Im nächsten Jahrzehnt erlebten wir den Boom der Computerspiele. Die Reaktion auf Benutzeraktionen (Klicks, Drücken) erwies sich als entscheidend und führte zur Entstehung der ereignisgesteuerten Programmierung.

Und für die Organisation von Code in Web- und Desktop-Anwendungen – wenn dieselben Daten aus verschiedenen Perspektiven neu angeordnet werden mussten – entstand das MVC-Muster (d. h. die Trennung des Modells von seiner visuellen Darstellung).

Sie haben den Grundgedanken verstanden: Es entsteht ein Problem -> eine Lösung entsteht. Problem -> Lösung.

Warum also beginnen Programmieranfänger jetzt mit der Anwendung von Lösungen (Architekturen) zu einem Zeitpunkt, an dem die Probleme noch nicht aufgetreten sind? In den Tutorials wird sofort empfohlen, mindestens einen MVP auszuwählen. Bei Testaufgaben für einen/zwei Bildschirme wird immer angegeben, dass MVC NICHT verwendet werden soll.

In Interviews wird eine Person, die mehrere Lieblingsprojekte mit denselben ein/zwei Bildschirmen geschrieben hat, zu VIPER-Problemen befragt. Wie könnte er von den Problemen wissen, wenn er sie noch nicht erlebt hat?

Im Kontext der Architektur wird oft über die Bequemlichkeit der Testbarkeit gesprochen, aber Tests wurden noch nie geschrieben. Und wenn ja, basierte es ausschließlich auf einem Tutorial und konzentrierte sich nur auf Unit-Tests, ohne sie an eine tatsächliche Anwendung zu binden.

Sie können das MVP-Schema in einfachen Worten erklären, geraten jedoch häufig in Verwirrung, wenn es um Protokolle mit ähnlichen Namen geht, wie z. B. ViewInput und ViewOutput . Tief im Inneren sehen sie das alles bereits als etwas Overhead an 🙄🤯

Fazit: Machen Sie sich keine Probleme. Schämen Sie sich nicht für MVC. Wenn Ihr Controller zu groß wird oder Sie auf Unannehmlichkeiten stoßen, ist es an der Zeit, nach neuen Ansätzen zu suchen.

Einfachheit der Benutzeroberfläche

Die Frontend-Entwicklung ist ein Dopamin-Paradies für Anfänger. Sie schreiben Code und sehen das Ergebnis sofort auf dem Bildschirm – Sie erhalten Ihre Belohnung 🍭. Es ist unbestreitbar motivierend. Allerdings hat diese Medaille auch eine Kehrseite. Anfänger streben oft danach, sofort eine übermäßig komplexe Benutzeroberfläche zu erstellen.

Darüber hinaus folgen komplexe Funktionen in der Regel einer komplexen Benutzeroberfläche. Auch wenn SwiftUI die Aufgabe heutzutage vereinfacht, kann man immer noch viel Zeit damit verbringen, Schnickschnack hinzuzufügen, ohne wirkliche Fortschritte zu machen.

Ich habe die iOS-Entwicklung in einem Kurs gelernt, in dem wir Teams bildeten und an einem einzelnen Projekt arbeiteten. In meinem Team schlug jemand vor, unsere App-Entwicklung mit der Auswahl von Schriftarten und Farben für den Dunkelmodus zu beginnen.

Insgesamt hat er den gesamten Kurs damit verbracht, und es ist erwähnenswert, dass die Schriftarten und Farben fabelhaft geworden sind. Allerdings hat der Typ in dieser Zeit ungefähr null Zeilen tatsächlichen Codes geschrieben.

Zweifellos sind die Schönheit und Funktionalität Ihrer Anwendung von entscheidender Bedeutung. Letztendlich müssen Sie diesem Aspekt Zeit widmen. Es ist einfach besser, mit etwas Einfacherem zu beginnen. Entwickeln Sie ein MVP (Minimum Viable Product), konzentrieren Sie sich auf die wichtigsten Funktionen und starten Sie von dort aus.

Der 80-20-Regel Hier gilt: Erstellen Sie die Grundlage der Anwendung und fügen Sie dann die Extras hinzu. Der umgekehrte Ansatz führt dazu, dass man sich mit komplexen Nuancen auseinandersetzt und sich ständig mit einer Hauptfunktionalität auseinandersetzt, die immer wieder kaputt geht.

Für Neueinsteiger in der mobilen Entwicklung besteht das Risiko, komplexe Lösungen vorzeitig zu übernehmen. Während die visuellen Vorteile der Front-End-Entwicklung verlockend sein können, ist es oft klüger, mit einem einfachen MVP zu beginnen.

Historische Trends legen nahe, dass Lösungen als Reaktion auf echte Herausforderungen entwickelt werden sollten.

Für eine effektive Entwicklung ist es von entscheidender Bedeutung, die Grundprinzipien zu verstehen und reale Probleme anzugehen, sobald sie auftreten.

Auch hier veröffentlicht