Anstatt über eine bestimmte Technologie oder ein bestimmtes Projekt zu sprechen, werde ich in diesem Beitrag über Softwarearchitektur und vermeidbare Fehler.
Es wäre viel einfacher, über die Erfolge zu sprechen und sie zu loben, aber ich finde Fehler trotzdem ein interessantes Thema, vor allem, weil sie sehr nützlich sind, um den Lernprozess zu verbessern.
Ich werde damit beginnen, ein wenig Kontext zu geben und dann meine Ansichten zur Softwarearchitektur zu teilen, die meiner Meinung nach der wichtigste Teil der Softwareentwicklung ist und wie man vermeiden kann, in die häufigsten Fallen zu tappen.
Wenn einem Programmierer die Frage gestellt wird:“Was bevorzugst du: ein Projekt von Grund auf neu zu beginnen oder ein bestehendes zu pflegen?„
Sie antworten:“Etwas von vorne anfangen!„
Das mag naheliegend erscheinen, weil das Erfolgserlebnis in der Regel größer ist, wenn wir sagen können:“Das ist mein Werk (zumindest ein beträchtlicher Teil davon). Es existierte vorher nicht und jetzt tut es das!„
Aber es steckt noch mehr dahinter. Das menschliche Gehirn mag Ordnung, es leitet aus dem Chaos und den scheinbaren Zufallsinformationen gerne Muster ab. Das gilt auch für die Softwareentwicklung.
Aber was passiert in einem bestehenden Projekt? Es ist wahrscheinlich, dass das Projekt bereits ein gewisses Maß an wahrgenommenem Chaos enthält, und es gibt sicherlich mehr als ein nicht existierendes.
Daher besteht die unmittelbare Reaktion darin, ein Projekt lieber von Grund auf zu beginnen, bei dem Sie das Chaos vollständig nach Ihren Erfahrungen kontrollieren können.
Natürlich In Software Utopia würden wir niemals etwas tun, das durch unsere eigene Nachlässigkeit Chaos verursachen würde. Leider leben wir nicht in dieser Welt, aber wir haben Werkzeuge und Prinzipien, die uns leiten.
Das beste Tool, das wir zur Verfügung haben, um die lästigen Aufgaben der Regression, der Behebung von Fehlern und dergleichen zu bewältigen, ist die Vorausplanung. Eine gute Architektur ist unser Freund.
Eine gut durchdachte Lösung ist Tausende von Stunden wert, da sie uns in Zukunft wirklich viel Zeit sparen wird.
Die meisten von uns haben gelesen die Bücher, wir kennen die Dinge zu tun. Wir sollten auch Tests durchführen und die Entwurfsmuster gewissenhaft anwenden. “Konzentrieren wir uns wirklich darauf, diesen MVC beizubehalten; lassen Sie uns BDD dafür anwenden; lassen Sie uns die Feature-Tests entwerfen, bevor wir den Produktionscode schreiben.“
Manchmal vergessen wir, wie wichtig der erste Schritt sein sollte, noch vor all dem.
Architektur.
Sicher, bevor Sie Produktionscode schreiben, ja, schreiben Sie bitte Ihre ersten Tests.
Aber noch bevor Sie Ihre ersten Tests schreiben, hat das Designteam wahrscheinlich bereits alle Anforderungen gesammelt, es wurden Verhandlungen mit dem Kunden und den anderen Beteiligten geführt, sie haben möglicherweise sogar einige Versionen des Designs des Produkts erstellt, das Sie bauen werden, und sie wurden vorab genehmigt, sodass Sie vielleicht denken, dass Sie bald mit dem Programmieren beginnen sollten.
Außer du solltest es nicht.
Das gesamte Team sollte sich hinsetzen und über das Produkt sprechen, das es bauen wird. Sie sollten sich ein Blatt Papier schnappen oder an ein Whiteboard gehen und anfangen, alle Funktionen aufzuzählen, die das Produkt haben wird.
Identifizieren Sie eindeutig alle technischen Anforderungen und die Durchführbarkeit der vorgeschlagenen Lösung. Hinterfragen Sie jeden Schritt und stellen Sie sich wirklich eine Lösung vor, die einen anderen Ansatz, vielleicht andere Frameworks, sogar eine andere Sprache verwendet.
Unterm Strich gibt es nicht so etwas wie zu viel Zeit mit Architektur zu verbringen.
Für mich ist eine der besten Arten zu lernen, Fehler zu machen.
Da es peinlich oder frustrierend sein kann, Fehler zu machen, wenn wir sie machen, neigen wir dazu, darauf zu achten, was passiert ist, und bemühen uns, die Lösung zu finden und herauszufinden, wie wir denselben Fehler am besten nicht noch einmal machen.
Das entspricht Erfahrung.
„Erfahrung ist einfach der Name, den wir unseren Fehlern geben.“
— Oskar Wilde
Vor kurzem habe ich an einem ziemlich komplexen iOS-Projekt gearbeitet. Gleich zu Beginn des Projekts gab es ein paar Dinge, die nicht stimmten. Die Anforderungen waren nicht zu 100% definiert, die Voraussetzungen waren nicht zu 100% erfüllt, die APIs waren noch nicht fertig...
Aber das Wichtigste war wahrscheinlich: Wir hatten die Architektur des Projekts nicht so definiert, wie wir es hätten tun sollen.
Das wurde mir natürlich erst bewusst, als der Schaden angerichtet war. Es gab viele Regressionen, das Umschreiben von Features und mehrmals sagte ich mir:“Warum habe ich das nicht richtig gemacht?“
Eine solche Gefahr bestand darin, dass kein Testframework verwendet wurde. Überhaupt. Tests und Validierungen wurden mit Benutzertests und spärlichen Peer-Code-Reviews durchgeführt. Als dann tatsächlich ein Testframework in das Projekt aufgenommen wurde, war es zu spät.
Eines der bekanntesten und anerkanntesten Frameworks für die iOS-Entwicklung spielte einfach nicht gut mit all den Feinheiten, mehreren Sprachen und schlechten Entscheidungen, die bei der Gestaltung der Produktarchitektur (aus technischer Sicht) getroffen wurden.
Zurück zum Zeichenbrett. Sie erhalten ein neues Projekt und waren möglicherweise sogar an der Phase der Anforderungserfassung beteiligt. Unabhängig davon, ob Sie bereits eine Vorstellung von der technischen Gesamtlösung für dieses Projekt haben, würde ich Folgendes empfehlen:
1. Schreib alles auf. Erstellen Sie Schaltpläne, Komponentendiagramme, Klassendiagramme, Flussdiagramme, was auch immer Sie für notwendig halten, um Ihnen — und dem Team — zu helfen, das Gesamtbild des Problems auf einen Blick zu verstehen.
Beziehen Sie sich so oft wie nötig darauf. Dies wird wahrscheinlich mehrmals überarbeitet, bevor die erste Codezeile geschrieben wird.
2. Wenn alle Komponenten/Module identifiziert sind, versuchen Sie, solide bestehende Lösungen für sie zu finden. Open-Source-Frameworks sind der richtige Weg, da sie bereits von mehreren Personen verwendet werden und daher getestet und viel fehlerfreier sind, als es Ihre eigene benutzerdefinierte Lösung sein könnte.
3. Achten Sie bei der Auswahl von externen Frameworks oder Frameworks von Drittanbietern darauf, dass sie“spiel nett“ mit den restlichen Frameworks. Versuchen Sie, genügend Beweise zu finden, die die Kompatibilität zwischen allen Frameworks bestätigen, die Sie verwenden werden.
Wenn Sie während der Entwicklung Frameworks ändern müssen, weil Sie herausgefunden haben, dass etwas nicht wie gewünscht funktioniert, wenn ein anderes Framework vorhanden ist, zwingt Sie dazu, ohnehin Zeit mit der Suche nach einer anderen Lösung zu verbringen, und Sie verschwenden noch mehr Zeit mit diesen unerwünschten Regressionen.
4. Wählen Sie ein gutes Testframework. Stellen Sie ähnlich wie im vorherigen Schritt sicher, dass das Testframework problemlos mit allen anderen Frameworks funktioniert, die Sie verwenden werden.
Ein Testframework ist nur so gut wie die Berichterstattung, die es Ihnen über ein bestimmtes Projekt bieten kann. Wenn es nicht gut geeignet ist oder eine bestimmte Technologie oder ein bestimmtes Modul, das Sie verwenden möchten, überhaupt nicht unterstützt, verlassen Sie sich nicht darauf.
Das Testen von 8 von 10 Funktionen reicht nicht aus.
Beim nächsten Projekt, an dem ich beteiligt sein werde, werde ich mein Bestes tun, um diese Prinzipien zu befolgen und sie bei Bedarf zu aktualisieren. Vielleicht werden eine oder mehrere dieser Annahmen in Frage gestellt und verfeinert.
Wenn Sie aus eigener Erfahrung etwas anderes gelernt haben, teilen Sie uns gerne Ihre Ansichten und Empfehlungen dazu mit, was die ersten Schritte sein sollten, wenn Sie ein neues Projekt beginnen.
Computersystemanalyst, Computerprogrammierer und Anwendungsentwickler. Besonders interessiert an der Entwicklung von Anwendungen für mobile Plattformen.
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
