So machen Sie Ihre Architektur, Anwendung und Ihren Code für andere Entwickler leicht unterstützbar. [...]
Bei der agilen Softwareentwicklung geht es nicht nur um agile Prinzipien und Praktiken. Um erfolgreich Software auf den Markt zu bringen, die sich positiv auf den Endanwender auswirkt, technische Schulden adressiert und zuverlässig eingesetzt werden kann, muss das Entwicklungsteam auch ihre agilitätsfördernden Programmierpraktiken und Architekturstandards berücksichtigen.
Eine noch wichtigere Überlegung steht für Technologieunternehmen auf dem Spiel. So schwer es auch ist, Software zu entwickeln, noch schwieriger ist es, Verbesserungen und Upgrades regelmäßig über einen längeren Zeitraum bereitzustellen. Devops CI/CD- und IAC-Praktiken (Infrastructure as Code) richten sich teilweise an einen kritischen Faktor, da die Automatisierung zuverlässige und wiederholbare Wege zur Bereitstellung von Anwendungen ermöglicht. Fügen Sie kontinuierliche Tests hinzu, und die Entwicklungsteams haben einen Weg gefunden, um zu bestätigen, dass Code-Änderungen keine Auswirkungen auf bestehende Funktionen haben.
Wenn die Anwendungen jedoch älter werden, wechseln die ursprünglichen Entwickler zu anderen Projekten und manchmal zu anderen Unternehmen. Wenn neue Entwickler dem Team beitreten, müssen sie die Architektur der Software kennen und den Code verstehen, bevor sie ihn zuverlässig und effizient ändern können.
Darüber hinaus wollen Entwickler, die Anwendungen entwickeln, oft neue entwerfen. Es könnte sich bequem und sicher anfühlen, an die bestehenden Anwendungen gebunden zu bleiben, die Sie entwickeln, aber an Ihren Code gebunden zu sein, ist nicht gesund für Ihre Karriere oder das Unternehmen.
Der beste Weg, um zu neuen und aufregenden Softwareentwicklungsinitiativen überzugehen, besteht darin, Ihre Architektur, Anwendung und Ihren Code für andere Entwickler leicht nutzbar zu machen. Agile Teams und Entwickler müssen Programmierpraktiken einführen und durchsetzen, die die kontinuierliche Softwareentwicklung unterstützen.
1. Erfinden Sie das Rad nicht neu
Die erste Regel der Kodierung: Kodiere nichts, was nicht kodiert werden muss! Wie?
- Erwägen Sie, Fragen nach den Anforderungen zu stellen. Warum ist ein Feature wichtig? Wer profitiert davon? Genauer gesagt, untersuchen Sie Nicht-Kodierungsoptionen, um das Problem zu lösen. Manchmal ist die beste Lösung gar keine Lösung.
- Hat jemand in Ihrem Unternehmen bereits eine ähnliche Lösung kodiert? Vielleicht gibt es einen Mikroservice, der nur eine Erweiterung oder eine Softwarebibliothek benötigt, die ein kleines Upgrade erfordert? Achten Sie darauf, die Codebasis Ihres Unternehmens zu durchsuchen, bevor Sie etwas Neues programmieren.
- Gibt es Lösungen von Drittanbietern, einschließlich erschwinglicher SaaS-Tools oder Open-Source-Optionen, die den Mindestanforderungen entsprechen?
- Haben Sie sich offene Code-Repositorys wie GitHub angesehen, um Codebeispiele und Ausschnitte zu finden, die den Compliance-Anforderungen Ihres Unternehmens entsprechen?
2. Berücksichtigen Sie Low-Code-Entwicklungsoptionen
Wenn Sie eine Lösung kodieren müssen, dann können vielleicht alternative Low-Code-Plattformen die Entwicklung der Funktionen effizienter gestalten als die Kodierung in Entwicklungssprachen wie Java, .Net, PHP und JavaScript.
Low-Code-Plattformen wie Caspio, Quick Base, Appian, OutSystems und Vantiq bieten alle Werkzeuge, um Anwendungen mit wenig Code und manchmal sogar ohne Programmierung zu entwickeln. Jede Plattform ist auf unterschiedliche Fähigkeiten spezialisiert und somit für eine bestimmte Klasse von Anwendungen geeignet. Caspio zum Beispiel macht es einfach, Formulare und Workflows in Websites einzubetten. Quick Base verfügt über robuste Workflow- und Automatisierungsfunktionen, und die ereignisgesteuerte Architektur von Vantiq eignet sich für IoT und andere Echtzeitdatenanwendungen.
Es gibt Zeiten, in denen eine Codierung erforderlich ist, aber Entwickler sollten auch eine oder mehrere Low-Code-Entwicklungsoptionen beherrschen und diese für geeignete Anwendungsfälle erwägen.
3. Automatisieren Sie das Testen
Neben dem Schreiben von Code, der die Anforderungen erfüllt, ist das Testen eines der wichtigsten Dinge, die Entwickler tun müssen. Testgetriebene Entwicklungspraktiken und automatisierte Testwerkzeuge sind ausgereift, und die Entwicklungsteams sollten Unit-, Regressions-, Leistungs- und Sicherheitstests als Teil ihrer agilen Kostenschätzungen berücksichtigen.
Zusätzlich zu den Tests zur Validierung von Builds und Releases tragen diese Tests auch dazu bei, den Code besser unterstützen zu können. Tests sind Dokumentationen und legen einen Vertrag darüber fest, wie sich der Code verhalten soll. Wenn neue Entwickler in Teams eintreten und versehentlich eine schlechte Änderung implementieren, stoppt das kontinuierliche Testen den Build und gibt dem Entwickler aussagekräftiges Feedback, um das Problem schnell zu lösen.
4. Alle Konfigurations-Parameter auslagern
Es sollte keine Entschuldigung für Entwickler geben, jemals Einstellungen auf Systemebene, Benutzernamen und Passwörter oder andere Konfigurationsinformationen im Code auf Hardcode-Ebene vorzunehmen. Ich habe gesehen, wie Entwickler bei der Entwicklung von Prototypen, die ihren Weg in die Produktionsumgebung finden, Abkürzungen nehmen. In den heutigen Architekturen sollte dies niemals geschehen. Hardcodierung ist keine technische Angelegenheit, sondern eine faule, unverantwortliche Codierungspraxis, die erhebliche Folgen haben kann. Wird Code versehentlich zugänglich, entsteht eine Sicherheitsschwachstelle, wenn Endpunkte oder Zugangsberechtigungen offengelegt werden.
Einen Schritt weiter zu gehen, wenn an Legacy-Code gearbeitet wird, sollte die Adressierung aller fest programmierten Konfigurationen und Parameter eine nicht verhandelbare Priorität für die technische Verschuldung sein.
5. Befolgen Sie die Namenskonventionen und fügen Sie Kommentare hinzu, um Code lesbar zu machen
Ich habe einmal mit einem unglaublich talentierten Entwickler zusammengearbeitet, der kein Englisch konnte und nicht die beste Schreibkraft war. Er würde Objekte mit Namen wie a, b und c anführen und dann lokale Variablen namens zz, yyy, xx erstellen. Er würde sich verpflichten, dies vor der Veröffentlichung zu bereinigen, aber nur selten durchsetzen.
Du solltest keine Paar- oder Mob-Programmierung einrichten lassen müssen, um zu erkennen, dass dies eine schreckliche Praxis ist.
Teams sollten Namenskonventionen wie Googles JavaScript Style Guide und Java Style Guide übernehmen und sich verpflichten, Code zumindest auf der modularen Ebene und idealerweise auf der Klassenebene zu kommentieren. Darüber hinaus sollten Unternehmen die Verwendung von statischen Codeanalysetools in Betracht ziehen, die den Entwicklern Feedback geben, wenn Code ein Refactoring für Struktur- und Lesbarkeitsfaktoren benötigt.
6. Überprüfen Sie regelmäßig den Code in der Versionskontrolle
Wenn Sie Code nicht täglich oder häufiger in die Versionskontrolle einchecken, kann es zu Konflikten und anderen Blockaden kommen, die das Team beeinträchtigen. Ein kleiner Fehler kann dazu führen, dass agile Teams ihre Sprintverpflichtungen verpassen oder zusätzliche Arbeit zur Lösung von Abhängigkeiten leisten.
Teams sollten sich auf Konventionen für das Einchecken von Code einigen, der nicht produktionsreif ist. Herkömmliche Ansätze beinhalten Feature-Flags und Git-Verzweigungen.
7. Vermeiden Sie es, Heldentaten und Komplexitäten zu kodieren
Die meisten Entwickler, die ich kenne, wurden professionelle Software-Ingenieure, weil sie es lieben, Programmierherausforderungen zu lösen. Codierung ist eine Kunst, Wissenschaft und ein Handwerk, und bessere Entwickler suchen nach Denkanstößen, Programmieraufgaben und eleganten Implementierungen.
Es gibt nur eine Grauzone zwischen der Lösung anspruchsvoller geschäftlicher und technischer Aufgaben und der Programmierung von Heldentaten, die den nächsten Entwicklern einen Code hinterlassen, der schwer zu verstehen und zu pflegen ist.
Für diejenigen von uns, die schon einige Zeit kodieren, erinnern wir uns an den Komfort von Perl-Einzeilern oder die Verwendung verschachtelter Vorlagen in C++. Manchmal gibt es gute Gründe, diese Ansätze zu verwenden, aber wenn eine neue Gruppe von Entwicklern diese Techniken nicht versteht, ist es schwieriger, den Code nachträglich zu ändern. Manchmal sind einfache, aber weniger elegante Kodierungsverfahren besser.
Agilität in der agilen Softwareentwicklung fördern
Die Rituale, die in die Scrum- und agile Entwicklung eingebettet sind, einschließlich Verpflichtungen, Standups, Sprint-Reviews und Retrospektiven, sind heute bewährte Praktiken, die eine Teamzusammenarbeit ermöglichen und eine erfolgreiche Umsetzung vorantreiben. Um jedoch über einen langen Zeitraum Agilität zu demonstrieren, müssen Entwickler Verantwortlichkeiten und Programmierpraktiken übernehmen, die eine längerfristige Unterstützung und Erweiterbarkeit des von ihnen entwickelten Codes ermöglichen.
Entwicklungsteams müssen ihre Programmierpraktiken kritisch hinterfragen. Es reicht nicht nur aus, heute eine Demoversion und einen Release durchzuführen, sondern es ist auch wichtig, dass andere Personen die Anwendung und den Code problemlos warten können.
*Isaac Sacolick ist der Autor von „Driving Digital: The Leader’s Guide to Business Transformation through Technology“, der viele Praktiken wie Agile, Devops und Data Science abdeckt, die für erfolgreiche digitale Transformationsprogramme entscheidend sind. Sacolick ist ein anerkannter Top-Social-CIO, ein langjähriger Blogger bei Social, Agile and Transformation und CIO.com sowie Präsident von StarCIO.
Be the first to comment