Lass mich etwas mit dir teilen. Ich mag die Idee der plattformübergreifenden Entwicklung. Die Möglichkeit, für alle meine Aufgaben einen Werkzeugsatz zu verwenden, ist ein Traum. Wer möchte nicht nur ein Tool verwenden, um seine Aufgaben erfolgreich abzuschließen? Einmal schreiben, überall laufen? Ich möchte!
Mir gefällt auch die Idee einer utopischen Gesellschaft. Eine Gesellschaft, in der jeder die Überzeugungen anderer respektiert, bedeutende / logische / vernünftige Argumente hat und die Aufgabe stellt, besser zu werden als gestern. Die reale Welt ist jedoch selten so perfekt.
Ich möchte zugeben, ich wollte schon lange den Streit zwischen nativer, plattformübergreifender und hybrider Anwendungsentwicklung diskutieren. Nicht aus Mangel an Motivation, sondern aus der Hoffnung oder dem Wunsch heraus, dass eines Tages ein kombinierter Satz von Tools auftaucht, die Türen öffnet und den besten Wert für die Erstellung mobiler Anwendungen bietet. Ich warte immer noch auf diesen Tag, und dieser Artikel soll dazu beitragen, meine Verbundenheit mit der nativen Entwicklung zu erklären.
Einheimisch, plattformübergreifend, hybrid? Was denn
Ich könnte auf die Unterschiede der einzelnen Entwicklungstypen eingehen, aber da Vergleiche über einen sehr langen Zeitraum möglich sind, werde ich versuchen, diesen Teil kurz zu fassen.
Native Entwicklung
In der nativen Entwicklung verwenden wir spezielle Tools zum Erstellen von Anwendungen für iOS oder Android. Das heißt, es gibt eine Codebasis für jede Plattform. Zu den Toolkits gehören normalerweise Swift / Objective-C + Xcode / AppCode für iOS und Kotlin / Java + Android Studio für Android.
Plattformübergreifende Entwicklung
Wir verwenden eine Plattform / ein Tool, das Ihren Code übersetzt / kompiliert / ausführt, als ob es sich um native Komponenten handeln würde. Der Vorgang unterscheidet sich je nach den verwendeten Tools. Das Endergebnis ist jedoch, dass derselbe Code auf Android- und iOS-Plattformen ausgeführt wird und fast genauso funktioniert.
Einige Beispiele für Tools: Xamarin, React Native, Flutter
Hybrid-Entwicklung
In der Hybrid-Entwicklung verwenden wir eine Plattform / ein Tool, mit dem ein WebView gestartet wird, auf dem Ihre Anwendung gehostet wird. Dies bedeutet im Wesentlichen, dass Ihre Anwendung eine Website ist, die über eine eigene Anwendung ausgeführt wird. Eine Plattform / ein Tool bietet in der Regel auch über Plugins Zugriff auf ihre eigenen Funktionen, z. B. eine Kamera.
Instrumentenbeispiele: Cordova und Ionic
Primäre vs wesentliche Funktionen
Um meine Wahl richtig zu verstehen, muss ich zwei verschiedene Arten von Werkzeugeigenschaften erläutern.
Seit vielen Jahren wird diskutiert, warum ein Tool besser ist als ein anderes. In den meisten Artikeln werden offensichtliche Funktionen des Tools erläutert, z. B. die Größe der Codebasis, die Entwicklungszeit, die Anzahl der Plattformen, für die Sie Anwendungen entwickeln können, usw. Diese Vergleiche nenne ich gerne die "Hauptmerkmale" jeder Toolbox. Die wichtigsten Merkmale des Tools lassen sich am besten mit anderen Tools vergleichen, da Sie die Unterschiede (d. H. Entwicklungsgeschwindigkeit, Erstellungszeit usw.) in der Regel empirisch erkennen können. Diese Merkmale sind für die meisten Menschen in der Regel von Belang, geben jedoch keinen Aufschluss über das Wesentliche.
Um die Konsequenzen der Auswahl eines Werkzeugs vollständig zu verstehen, müssen Sie die „inhärenten Merkmale“ berücksichtigen. Diese Merkmale sind im Allgemeinen subtiler und ihre Auswirkung ist schwieriger zu bewerten als die Hauptmerkmale. Leider ist der Einfluss dieser Merkmale in der Regel erst nach Auswahl eines Werkzeugs zu verstehen, in das große Mittel investiert werden. Diese Merkmale sind die Vollständigkeit und Klarheit der Dokumentation, die Verfügbarkeit geeigneter Werkzeuge usw.
Um die richtige Entscheidung für ein Entwicklungswerkzeug treffen zu können, muss man seine inhärenten Merkmale kennen.
Warum wähle ich native Entwicklung
Im Laufe der Jahre der Softwareentwicklung hatte ich die Möglichkeit, verschiedene Tools für verschiedene Projekte zu verwenden. Normalerweise wurde die Auswahl der Entwicklungswerkzeuge von einem Management oder technischen Ingenieur für mich getroffen. Sobald ich zu freiberuflich wechselte, entschied ich mich für den technologischen Stack.
Letztendlich kam es bei meiner endgültigen Entscheidung darauf an, nicht nur die Faktoren der Tools zu berücksichtigen, sondern auch, wie sich die inhärenten Merkmale auf jedes meiner Projekte in verschiedenen Situationen im Laufe der Zeit auswirken. Hier sind meine Schlussfolgerungen.
1. Ständige Popularität
Als ich 2013 mit dem Programmieren anfing, gab es viele Hype-Vocals von Cordova und Appcelerator. Einige Jahre später wechselte Hype zu Xamarin. Einige Jahre später war es bereits React Native. Derzeit? Flattern wird immer beliebter.
Ich habe festgestellt, dass die Popularität des Tools auch die Unterstützung darstellt, die es erhält. Wenn das Tool einer privaten Firma gehört, wird die Popularität mit dem Verkauf gleichgesetzt, was zu einer Erhöhung der Supportkosten führt. Wenn das Tool Open Source ist, hängt die Beliebtheit davon ab, wie viele aktive Entwickler die Codebasis verbessern. Popularität kann kommen und gehen und das gesamte Entwicklungsökosystem um dieses Werkzeug beeinflussen.
Schauen Sie sich dieses Google Trends-Diagramm an, das verschiedene plattformübergreifende Tools im Zeitverlauf zeigt.
Das Google Trends-Diagramm zeigt grob die Ergebnisse der Anzahl der Suchanfragen für verschiedene plattformübergreifende Mobiltechnologien an.
Obwohl dieses Diagramm eine grobe Schätzung der Popularität ist (da es nur die Ergebnisse der Anzahl der Suchvorgänge darstellt), gibt es einen Einblick in das, was ich als Entwickler erlebt habe. Unternehmen und Privatpersonen neigen dazu, Neues zu nutzen. Dies bedeutet nicht unbedingt, dass das Tool besser oder schlechter ist (da viele Artikel unabhängig vom Veröffentlichungsdatum für / gegen argumentieren), aber die Leute wechseln immer zu etwas Neuerem.
Wenn ein Tool veröffentlicht wird, wird es normalerweise von der Entwickler-Community beworben und als "Zukunft" angesehen. Dies kann dazu führen, dass ältere Werkzeuge weniger Unterstützung haben und mit der Zeit langsam verkümmern.
Vergleichen Sie dies mit der nativen Entwicklung, die garantiert Unterstützung erhält. Während Apple iOS und Google Android unterstützt, ist die native Entwicklung immer relevant. Aus diesem Grund hat native Entwicklung das größte Ökosystem von Entwicklern; es war nur um länger und war in seiner Popularität gleichbleibend.
Ein weiterer zu berücksichtigender Punkt ist die Übertragung des Projekts. Die Wahrscheinlichkeit, dass der nächste Entwickler zumindest etwas Erfahrung im Bereich der nativen Entwicklung hat, ist recht hoch. Auch wenn sie nicht hauptsächlich mit nativen Tools arbeiten, haben die meisten Entwickler zumindest einen Bezug zu diesen Tools, was bei plattformübergreifenden Lösungen weniger wahrscheinlich ist.
2. Geschäftswerte / Vision
Ich höre selten, wie viele Menschen beim Vergleich von Entwicklungstools über den geschäftlichen Wert diskutieren. Ich habe verschiedene Entwickler und sogar Eigentümer des technischen Geschäfts danach gefragt, und meistens erhielt ich als Gegenleistung einen leeren Blick. Es ist wichtig zu verstehen, wie der Unternehmenswert mit einem bestimmten Tool korreliert und wie er diesen Wert liefern kann.
Nehmen Sie zum Beispiel Xamarin. Bereits im Februar 2016 kaufte Microsoft Xamarin für rund 400 bis 500 Millionen US-Dollar. Zu dieser Zeit bezog sich die Vision von Microsoft in erster Linie auf die Entwicklung mobiler Anwendungen. Sie haben mit diesem Tool erhebliche Fortschritte erzielt und es sogar als sofort einsatzbereites Add-In für Visual Studio und Visual Studio für Mac integriert. Ein paar Jahre später hat sich Microsofts Vision auf künstliche Intelligenz verlagert.
Während dieser Visionsänderung arbeitete ich mit Xamarin an einem Projekt. Während dieser Zeit lernte ich eine Plattform kennen, mit der ich von einem stabilen Werkzeugsatz auf einen sich langsam verschlechternden umsteigen musste. Jedes Update des Tools sah aus wie ein Versuch, zumindest nichts zu brechen. Im besten Fall hat alles so funktioniert, wie es sollte. Im schlimmsten Fall haben Sie Stunden oder sogar ein oder zwei Tage damit verbracht, Aktualisierungen rückgängig zu machen und zu versuchen, Ihre Umgebung wieder in einen gesunden Zustand zu versetzen.
Dieser langsame Abbau ist auf der Xamarin-Homepage nicht dokumentiert (was verständlich ist), aber wenn Sie in den Foren nach Informationen suchen, haben Sie möglicherweise das Gefühl, dass sich etwas im Laufe der Zeit geändert hat. Nachrichten über Dinge, die früher nicht mehr funktionieren, oder darüber, wie sich die Erfahrung des Entwicklers mit diesem Tool geändert hat. All dies wirkt sich direkt auf die Entwicklungskosten aus, nicht nur wegen der Rohstunden, sondern auch wegen der Qualität des Codes.
Das Läppen während der Umstellung auf ein neues Werkzeug führt zu einer Erhöhung der Gemeinkosten und zu Gewinneinbußen
Ich gebe zu, dass die native Entwicklung auch hier ihre Probleme hat. Zum Beispiel versucht Apple normalerweise, Entwickler dazu zu bringen, sich auf eine bestimmte Weise zu entwickeln (zum Beispiel mithilfe von Storybords oder der MVC-Vorlage). Das Toolkit ist auch nicht immer perfekt, so dass ich AppCode für die meisten meiner iOS-Entwicklungen verwende. Dennoch investieren sowohl Apple als auch Google viel Zeit und Geld, um sicherzustellen, dass Entwickler problemlos native Lösungen entwickeln können. Schauen Sie sich einfach Android Jetpack, SwiftUI oder ein Upgrade auf Kotlin und Swift an.
Letztendlich haben Google oder Apple nicht die beste Vision der Welt, aber sie ist konsistent. Es ist sehr unwahrscheinlich, dass sich Unternehmen über Nacht weigern, ihre Tools zu unterstützen.
3. Zeit sparen
Oh ja, zeitsparend. Der heilige Gral der Entwicklungswirksamkeit. Dieses umstrittene Thema zu JEDEM Entwicklungstool kann ein Unternehmen gründen oder zerstören. Dieses Thema steht bei jedem Projekt im Vordergrund, da es sich direkt auf die Kosten auswirkt. Aber gehen wir einen Schritt zurück und stellen uns eine Frage.
Was können wir tun, um Zeit zu sparen?
Ich werde es erklären. Wie bei Unternehmenssoftware gibt es normalerweise mehrere Möglichkeiten, ein Problem zu lösen. Die Entscheidung hängt hauptsächlich von der Situation einer bestimmten Person oder eines bestimmten Unternehmens ab. Dies bedeutet, dass der Ansatz „Eine Lösung für alle“ gefährlich ist. es kommt auch der "wir haben es immer getan" -Mentalität sehr nahe. Bei der mobilen Entwicklung ist es leider üblich, ein plattformübergreifendes Tool zu wählen, um Zeit zu sparen. Aber ist es so gut? Können wir beispielsweise eine andere Methode zur Lösung des Problems finden? In der Wirtschaft gibt es ein Sprichwort: "Menschen stehen über Prozessen, über Werkzeugen."
Menschen über Prozessen, über Werkzeugen
Genau dies sollte bei einer Entscheidung berücksichtigt werden. Wie lange dauert die Entwicklung zwischen der Auswahl eines Tools und der Erstellung von Prozessen / Prozeduren oder sogar einem anderen Entwicklungsansatz?
Ein Tool, das in der Lage ist, eine schlechte Mentalität während der Entwicklung zu lösen?
Rationalisiert das Tool den Entwicklungsprozess?
Kann ein leicht veränderter Prozess oder eine leicht veränderte Mentalität zu besseren zeitsparenden Ergebnissen führen?
Können wir die Infrastruktur nutzen, um unsere Probleme zu lösen?
Dies sind alles richtige Fragen, die auch die Komplexität der Lösung zeigen. Es ist nicht so einfach, das nächste plattformübergreifende Framework anstelle der nativen Entwicklung auszuwählen. Was ist für Sie oder Ihr Unternehmen richtig? Nur Sie können diese Wahl treffen.
Da native Entwicklung standardmäßig ein Produkt mit höherer Qualität erzeugt und nahezu unbegrenzt unterstützt wird, werde ich diese Tools auswählen. Meine persönlichen Werte bestimmen diese Wahl (Streben nach Exzellenz). Die eigene Entwicklung dauert wirklich länger (wie viel mehr variiert). Gibt es eine Möglichkeit, Zeit zu sparen? Soll ich überhaupt Zeit sparen? Sollte ich nur nach Projekten suchen, bei denen das Budget keine Rolle spielt?
Eine Möglichkeit, das Problem der Zeitersparnis zu lösen, besteht darin, Code zu erstellen, der wiederverwendet werden kann. Erstellen Sie hochwertigen, wiederverwendbaren Code, der schnell integriert und für mehrere Projekte bereitgestellt werden kann. Da ich ein Toolkit für die Haltbarkeit ausgewählt habe, kann ich sicher sein, dass mein wiederverwendbarer Code für einige Zeit verwendet werden kann.
4. Andere Schlussfolgerungen
Letztendlich habe ich viele andere Schlussfolgerungen gezogen, bevor ich mich für eine einheimische Entwicklung entschieden habe. Viele davon habe ich in meiner gesamten Karriere gemacht und verschiedene Tools, Prozesse und Ansätze ausprobiert. Eine Beschreibung all dessen würde diesen Artikel unglaublich umfangreich machen. Daher werde ich der Kürze halber einige davon erläutern.
Dinge, über die ich nachgedacht habe, bevor ich mich für eine native Entwicklung entschieden habe:
1. Zeit für Onboarding Developer
2. Unterstützende Infrastruktur
3. CI / CD-Pipelines
4. Die Kosten für die Unterstützung älterer Projekte
5. Abstraktionsebenen = mehr Raum für Fehler
6. Verfügbarkeit der Entwickler (Anzahl der Entwickler, die das angegebene Tool verwenden)
7. Unternehmenshierarchie (Airbnb hat eine großartige Blogserie, die sich mit diesem Thema befasst)
8. Abhängigkeit der Plattform von Plugins
9. Glück des Entwicklers bei der Verwendung des Tools
10. Designkosten: Die Notwendigkeit, das Design so zu gestalten, dass beide Plattformen unterstützt werden
11. Benutzerdefinierte Projektstruktur
12. Wissensressourcen - Die Anzahl der erforderlichen Wissensbereiche (für Xamarin sind beispielsweise Folgendes erforderlich: + Xamarin Api-Plattform, C #, spezifische Android-Funktionen, spezifische iOS-Funktionen und Kenntnisse über die Funktionen jeder Plattform und deren Interaktion über Xamarin.)
13. Lizenzierung + Kosten
14. Die Landschaft der mobilen Betriebssysteme. Zum Beispiel: Wie lange halten nur 2 große Plattformen?
Schlussfolgerungen
In den letzten 2 Jahren verwendete er native mobile Entwicklung als Hauptwerkzeug. Einer der vielen Gründe, warum ich mit meiner Entscheidung zufrieden bin, ist, dass ich mir die Zeit genommen habe, so viele Feinheiten wie möglich für jedes Werkzeug in Betracht zu ziehen. Ich kenne die Vor- und Nachteile, und das bringt mir Vorteile.
Ich hoffe, dieser Artikel hilft Ihnen bei der Auswahl eines Werkzeugs, die richtigen Fragen zu stellen. Nehmen Sie Marketing nicht zum Nennwert und folgen Sie BITTE nicht dem Hype. Dig, schmutzig und kritisch denken.