Ich arbeite seit über sechs Jahren als iOS-Entwickler. Ich habe zufällig in verschiedenen Unternehmen und Teams gearbeitet. Ich habe sowohl im Outsourcing als auch im Outstaff gearbeitet und hatte sogar die Möglichkeit, am Startup teilzunehmen. Und jetzt, nach einigen Jahren kommerzieller Entwicklung sowie einigen Jahren Programmierung an der Universität, begann ich, einige Prinzipien oder Regeln für einen qualitativen Ansatz für die Anwendungsentwicklung herauszuarbeiten. Zuerst war es ein Rat an meinen Freund. Ich gab ihm Ratschläge und dachte, dass mir solche Ratschläge fehlten, als ich gerade meinen Entwicklungspfad begann. Was soll ich sagen, einige Momente habe ich vor relativ kurzer Zeit für mich selbst realisiert, und einige befinden sich bereits an einem neuen Arbeitsplatz. Und so entstand die Idee, eine Liste mit Tipps zu erstellen, die ich vor fünf bis sechs Jahren mit mir teilen möchte. Ich bin mir sicher, dass ich mir in weiteren fünf Jahren heute etwas zu sagen haben werde. Aber wir werden dies wahrscheinlich für die Zukunft belassen.
Ihr Code ist schlecht
Und das erste, was ich mir nach wie vor sagen möchte, ist: „Ihr Code ist schlecht!“. In gewöhnlichen Menschen "Govnokod". Und meine ausländischen Kollegen in der Entwicklungswerkstatt haben „Affencode“.
Nein, das haben Sie nicht gedacht. Ich möchte nicht betonen, dass ich früher ein schlechter Programmierer war, und jetzt ist mein Code perfekt. Ich möchte diese Botschaft umformulieren und drei wichtige Punkte im Sinne dieses Ratschlags vermitteln.
"Ihr Code war und wird schlecht sein!"Der erste Moment: Es gibt keinen perfekten Code, niemand legt die ideale Architektur fest und es gibt keinen solchen Code, in dem es keine Fehler geben würde. Ich denke, viele haben sich dabei erwischt, dass sie die neue Bibliothek oder die neue Technologie nicht herausfinden konnten. Oder einige von uns haben bis zum Äußersten versucht, das Feature perfekt zu schreiben, wobei sie alle Prinzipien von OOP, SOLID befolgt haben. Was wiederum zu viel Zeit und manchmal zu einer Sackgasse führte. Manchmal wurden bei dem Versuch, den perfekten Code zu schreiben, Monster geboren, die eine vollständige Liste von Mustern enthielten, die der Entwickler kennt, oder vielleicht sogar mehr.
Mit meinem Satz möchte ich die Idee vermitteln, dass Sie sich nicht zuallererst Sorgen machen sollten, sondern sich über die Qualität Ihres Codes Sorgen machen sollten. Es ist unmöglich, alles vorherzusagen. Und es ist besser, sich zu entspannen, einfacher zu schreiben und, wie Sie wissen, vergeblich zu leiden und sich Sorgen zu machen. Mit der Erfahrung werden Entscheidungen von selbst kommen. Manchmal ist es notwendig, "nagovodnodit" zu machen, sie werden auf Probleme stoßen, die dieser Shitcode ein für alle Mal verursacht und versteht, dass es besser ist, dies nicht zu tun.
Der zweite Moment, den ich zuvor erwähnt habe, ist, dass es fast unmöglich ist, alles vorherzusagen. Ja, mit der Erfahrung kommt das Verständnis dafür, was Sie tun. Und Sie können den Entwicklungspfad des Projekts vorhersagen. Aber es kommt mit Erfahrung. Und wenn Erfahrung nicht ausreicht, sollten Sie nicht versuchen, den Code universell zu machen. Es gibt häufige Fälle, in denen Ihre Funktion, die Sie lange und so sorgfältig überlegt und dann geschrieben haben, einfach aus der Anwendung entfernt wird. Es gibt auch Fälle, in denen sich Anwendungen nur ändern, weil für den Kunden alles anders schien. Und nach langen Stunden mühsamer Übertragung der Benutzeroberfläche vom Design zum Code erscheinen plötzlich 100.500 Änderungen. Dies ist nur der Anfang, da nach dem ersten Wiederherstellen immer mehr neue Änderungen vorgenommen werden. Und wenn der Entwickler nicht über genügend Erfahrung verfügt, kann dieser Prozess nicht nur viel Zeit in Anspruch nehmen, sondern auch nicht die angenehmsten Empfindungen hervorrufen, die durch unangenehme Gedanken irgendwo in den geheimen Winkeln des Geistes ausgelöst werden, wodurch der Entwicklungsprozess von einer lustigen Lektion in höllischen Schmerz verwandelt wird. Achten Sie deshalb auf Ihre Nerven und passen Sie nicht zum Ideal. Manchmal kann man ein bisschen reden.
Dritter Punkt: Dies ist wieder ein rein psychologischer Moment, nämlich Kritik von anderen Entwicklern. Wie jeder weiß, berücksichtigen alle inländischen Entwickler jeden anderen Code - Shit Code. Selbst wenn ihm sein eigener Code gezeigt wird, den er nicht erkennt, wird er ihn wahrscheinlich als Scheiße bezeichnen. Oft geht eine solche Kritik mit der moralischen Befriedigung des Kritikers selbst einher. Wie erfahrene Entwickler festgestellt haben, sind es die Leute, die am häufigsten den Code eines anderen als govnodkod bezeichnen, genau diejenigen, die auf einmal mehr als novnokovodil haben. Und je lauter jemand „Govnokod“ schreit, desto mehr seiner „Kuchen“ hat er auf seinem Weg gelassen.
Darüber hinaus müssen Jungfrauen, die sich an junge Menschen erinnern, unbedingt zugeben, dass er ein Novocode für Ruhm war.
Daher rate ich Ihnen, den Ausdruck "Ihr Code war und wird eine Scheiße sein" als Schutz vor nicht immer konstruktiver Kritik zu verwenden. Ich möchte auch darauf hinweisen, dass Ihr Code immer Scheiße sein wird, weil die Entwicklung nicht stillsteht. Jedes Jahr verbessert sich die Qualität Ihres Codes nur. Der aktuelle Code wird also irgendwann zu govnokod.
Teilen und erobern
Ich möchte nicht, dass es so aussieht, als würde ich nur Govnokod empfehlen, daher werde ich anfangen, Ratschläge zu geben, wie man diesen schlechten Code vermeidet. Und ich möchte mit dem Prinzip beginnen, das ich für mich selbst beiseite gelegt habe. Nein, dies ist keine Vererbung oder Polymorphismus und nicht eines der Prinzipien von SOLID. Ich nenne dieses Prinzip Teilen und Erobern.
Ja, es gibt so etwas wie Zersetzung.
Zersetzung - die Aufteilung des Ganzen in Teile. Außerdem ist die Zerlegung eine wissenschaftliche Methode, die die Struktur des Problems verwendet und es Ihnen ermöglicht, die Lösung eines großen Problems durch eine Reihe kleinerer Aufgaben zu ersetzen, die zwar miteinander verbunden, aber einfacher sind.
Wie Wikipedia sagt. Dies ist jedoch nur ein Teil dessen, was ich in die Bedeutung meines Prinzips gebracht habe. Auf jeden Fall müssen Sie das Projekt und die Aufgaben in kleinere Teile aufteilen. Aber ich meine den konzeptionellen Ansatz zur Trennung logischer Gruppen im Projekt.
Und das erste, worauf ich mich bei diesem Prinzip beziehe, ist die Trennung der Benutzeroberfläche UND der Geschäftslogik der Anwendung. Es scheint, dass ich jetzt direkter Hauptmann der Beweise bin. Aber! In der Praxis verschwimmen diese Grenzen häufig, und es stellt sich heraus, dass der ViewController oder die Aktivität eine Geschäftslogik enthält.
Ich denke, ein Beispiel für den Anmeldebildschirm ist einfach und verständlich. Hier beginnt der Entwickler mit der Implementierung der MVC-Architektur. Es scheint, dass es eine separate Ansicht gibt, wie Controller mit Modell ebenfalls hinzufügt, wie es sollte. Aber irgendwann denken sie: "Warum muss ich mit einer einzigen Schaltfläche mehrere Klassen für den Bildschirm hinzufügen?" und in diesem Moment empfehle ich dringend, solche bösartigen Gedanken aufzugeben und sich strikt an das Prinzip „Teilen und Erobern“ zu halten, um Benutzeroberfläche und Geschäftslogik zu trennen. Und selbst wenn für die Architektur eine ViewModel-Klasse hinzugefügt werden muss, in der zwei Codezeilen vorhanden sind, sollten Sie dies tun. Denn es gibt oft Fälle, in denen ein Bildschirm, auf dem ursprünglich nur eine Schaltfläche vorhanden war, im Laufe der Zeit zu undenkbaren Schwierigkeiten wird. Wenn Sie die Trennung der logischen Komponenten im Voraus verfolgen, wird dies das Leben in der Zukunft erheblich erleichtern.
Sie können insbesondere die Essenz der strengen Trennung von Benutzeroberfläche und Logik spüren, wenn Sie Bildschirme von einem Projekt in ein anderes übertragen müssen. Oder in einer Situation, in der unter verschiedenen Bedingungen unterschiedliche Algorithmen in der Geschäftslogik verwendet werden. Durch Aufteilen des Autorisierungsbildschirms in Komponenten können wir beispielsweise eine der Komponenten in Zukunft ersetzen, ohne die andere zu beeinflussen. Wir können entweder Ansicht oder Modell durch neue Autorisierungsmethoden für dieselben Daten ersetzen.
Beschränken Sie nicht das Prinzip, nur diese beiden Schichten zu teilen und zu erobern. Zur strengen Trennung würde ich die Trennung von Bildschirmen und Navigationslogik für mobile Anwendungen hinzufügen. Was meine ich damit?
Meine Praxis hat mich dazu veranlasst, das Codieren für einen bestimmten Bildschirm zu vereinfachen, indem die Navigationslogik separat herausgenommen wird. Ein Bildschirm, insbesondere View, für iOS, ist ein UIViewController und manchmal ein UIView. Für Android Activity oder Fragment sollten sie nicht an einer Funktion beteiligt sein, um sich selbst anzuzeigen und zu anderen Bildschirmen zu wechseln. Jede dieser Klassen sollte sich nur darum kümmern, was auf einem bestimmten Bildschirm geschieht, oder vielmehr nur um einen bestimmten Bildschirm zu rendern und mit einer Geschäftslogikklasse (Presenter, ViewModel und andere) zu interagieren.
Dies sind nur zwei von vielen Beispielen, bei denen Sie der Trennung grundsätzlich folgen müssen. Das Befolgen dieses Prinzips wird die weitere Arbeit mit dem Projekt erheblich erleichtern. Auch wenn Govnokod in einer der separaten Komponenten enthalten ist.
Single Style
Ich gehe nahtlos von den vorherigen Ratschlägen aus und möchte zum nächsten übergehen, nämlich zur strikten Einhaltung eines einzelnen Stils im Projekt.
Was meine ich damit?
Zunächst ist das Schlüsselwort hier streng, vom Wort überhaupt. Zunächst wählen wir einen einzelnen Ansatz zum Organisieren eines Projekts, zur Dateiverwaltung, zum Codestil usw. aus. Dies wird das allgemeine Erscheinungsbild des Projekts erheblich verbessern und die Navigation im Projekt, die Suche nach Code und die Einführung eines neuen Entwicklers in das Projekt erheblich erleichtern. Ich denke, es lohnt sich nicht daran zu erinnern, dass wir nach einer Weile selbst mit unserem alten Code diese neue Person werden können.
Die Wahl der Architektur und deren Befolgung
Ausgehend von den vorherigen Ratschlägen gehen wir wieder reibungslos zum nächsten über, der Wahl der Architektur. Und die Hauptidee, die ich vermitteln möchte, ist nicht, über die besten Architekturen zu sprechen oder zu sagen, dass Sie dies und nicht eine andere wählen müssen. Nein! Zunächst gibt es keine ideale Architektur, die alle möglichen Fälle im Projekt vollständig abdeckt. Ich hörte einmal diese Worte: "Wenn es eine ideale Architektur gäbe, würden wir Entwickler als unnötig gefeuert und durch Skripte ersetzt, die die ideale Architektur erzeugen."
Ich glaube, der Hauptpunkt ist nicht die Wahl der besten Architektur, sondern die strikte Einhaltung der Architektur, die bereits ausgewählt und angewendet wurde. Sei es VIPER, REDUX, MVP oder MVC. Jede der oben genannten Architekturen hat natürlich Vor- und Nachteile. Im Laufe der Zeit immer mehr neue Ansätze für die Gestaltung der Architektur des Projekts.
Ich werde genauer auf meine Idee eingehen. Wenn Sie VIPER bereits verwendet haben, befolgen Sie dessen Grundsätze genau. Auch wenn es den Anschein hat, dass für einen Bildschirm mit nur einer Schaltfläche zu viele Dateien vorhanden sind, um Codezeileneinheiten zu erstellen, sollten Sie diese Regeln unter keinen Umständen umgehen. Denn in solchen Momenten wie diesem wird der Govnokod geboren, der dann wie ein Schneeball alles wächst und wächst.
Ich empfehle Ihnen, sich mit den beliebtesten Architekturen vertraut zu machen und entweder die gewünschte oder die beliebteste auszuwählen, bevor Sie ein neues Projekt starten. Ich empfehle dringend, die zweite Option zu wählen, nämlich mit der beliebtesten Architektur zu beginnen Es wird leicht sein, Antworten auf viele Fragen zu finden. Bei der Auswahl einer Architektur sollte besonderes Augenmerk auf die Nachteile dieser Architektur gelegt werden. In diesen Fällen wird empfohlen, sie zu verwenden.
Wenn es sich beispielsweise um ein kleines Projekt handelt, für das es zwei Entwickler gibt, sollten Sie VIPER nicht verwenden, da dies eine ziemlich umständliche Architektur ist, die sich sehr gut für große Projekte und große Teams eignet. Es gibt also keine Fälle, in denen der Code zum Erstellen von VIPER um ein Vielfaches größer ist als der Code der Geschäftslogik selbst.
Persönlich bevorzuge ich jetzt die MVVM + Router-Architektur. Es funktioniert gut bei einem kleinen Projekt, bei dem ich ein einzelner Entwickler bin.
Fazit: Hauptsache nicht, welche Architektur Sie gewählt haben, sondern wie genau Sie ihr folgen.
Ich möchte auch hinzufügen, wenn das Projekt nicht von Grund auf neu entwickelt wird, müssen Sie sich zunächst mit der aktuellen Architektur und dem allgemeinen Stil des Projekts vertraut machen und beginnen, ihm zu folgen. Sie sollten nicht mit Schreien ausbrechen, dass es Govnokod gibt (zurück zum ersten Rat) und anfangen, alles zu wiederholen. Eine Ausnahme kann eine vollständige Anarchie des Projekts oder das Fehlen eines gemeinsamen Stils sein.
Refactoring-Pausen
Abschließend möchte ich sagen, dass eine Pause für das Refactoring ein guter Ansatz ist. Refactoring ist ein sehr wichtiger Bestandteil der Entwicklung hochwertiger Anwendungen. Ja, wir schreiben nicht sofort den perfekten Code, aber es ist auch nicht gut, ihn so zu belassen, wie er ist. Es kommt häufig vor, dass die ursprüngliche Implementierung nicht skalierbar ist, wenn Sie neue Funktionen einführen müssen. Schließlich ist es fast unmöglich, alle möglichen Änderungen in zukünftigen Versionen des Projekts vorherzusagen. Außerdem garantiert keine Architektur eine 100% ige Abdeckung aller Fälle. Daher ist es wichtig, Änderungen am vorhandenen Code vorzunehmen, um ihn an neue Funktionen anzupassen.