Wie in dem vorigen Kapitel erwähnt, sind Devops wichtig, um den Code aufrechtzuerhalten, aber raten Sie mal, das ist auch eine Teamanstrengung und zusätzlich eine geschäftskritische Priorität, denn schlechter Code bringt schlechte Dinge mit sich.
„Coding ‘Free for all’“ – also, Entwickler entwickeln einfach, wie sie wollen – ist weit entfernt von der Art und Weise, wie der Code in einem grossartigen Produktcode-Repository aufrechtzuerhalten sein sollte.
Eines der oft übersehenen „warum’s“ hier ist, dass der Code geistiges Eigentum (IP) des Unternehmens ist und einen monetären Wert hat, wenn nicht in den Buchhaltungsunterlagen, dann als möglicher Vermögenswert, wenn das Unternehmen verkauft wird. Das allein macht es wert, den Code aufrechtzuerhalten.
Weiter – warum sollte der Code lesbar und überblickbar sein? Die wichtigsten Funktionen sollten dokumentiert sein, zumindest auf hoher Ebene (es ist extrem schwierig, die Dokumentation in einer raschen Entwicklungsumgebung auf dem neuesten Stand zu halten, und könnte die Entwicklung stark verlangsamen).
Den Code in einem Git-Repository zu haben, sorgt dafür, dass neue Versionen hinzugefügt werden können und man immer zurückgehen und nachverfolgen kann, was hinzugefügt wurde, und wenn man ein Task-Management-System verwendet, um den Backlog zu verwalten, kann man auch das Ticket oder die Aufgabe verfolgen, was für eine sehr gute Dokumentation der Geschichte sorgt.
Das ist nützlich, um zu sehen, warum etwas geändert wurde und was es ausgelöst hat. Durch die Arbeit in Branchen haben die Entwickler ihre eigene verteilte Kopie des Codes auf ihrem eigenen Computer und können leicht zusammenarbeiten, indem sie eine Aktualisierung des Codes ziehen, wenn ein anderer Entwickler an derselben Branch gearbeitet hat oder wenn neue Feature-Branches während einer Produktionsfreigabe zur Hauptbranch hinzugefügt wurden.
Lesen Sie mehr in „The CTO Playbook“ verfügbar auf Amazon/Kindle.
Mir si es Schwiizerischi Firma (LLC) mit Sitz z'
Schwiiz.