Wie kann ich kritische Fehler in einer neuen Codeumgebung vermeiden?

Wenn mehrere Entwickler Änderungen an derselben Codebasis vornehmen (und nicht immer auf dem neuesten Stand sind), werden diese Dinge passieren. Ich bin selbst Entwickler; Es ist nichts, woran man sich aufhängen sollte, es wird uns allen mindestens einmal passieren. Es gibt jedoch ein paar Dinge, die Sie tun können, um das Risiko eines erneuten Auftretens zu verringern.

Aus dem Kontext sieht es so aus, als hättest du alles lokal getestet und es hat gut funktioniert. Erst später ging etwas schief. Dies deutet darauf hin, dass entweder Ihre eigene Codebasis leicht veraltet war und/oder jemand anderes veralteten Code hatte, als er seine eigenen Änderungen festlegte. Das Beste, was Sie tun können, bevor Sie Ihren Code festschreiben, ist, alle kürzlich vorgenommenen Änderungen aus Ihrem Repository (oder wie auch immer Sie es nennen) abzurufen, damit Sie sicher sein können, dass Ihre Änderungen mit dem aktuellsten Code funktionieren. Wenn alle Tests bestanden sind, können Sie guten Gewissens zusagen.

Ich würde auch vorschlagen, gegenüber Ihren Kollegen etwas lauter zu sein. Wenn Sie Änderungen an einem kritischen System vornehmen, teilen Sie es ihnen mit. Selbst wenn es sich um eine einfache Anfrage wie „Ich bin dabei, diesen wichtigen Teil zu ändern, haben Sie Zeit für eine Codeüberprüfung?“ . Auf diese Weise verbringt Ihr Team nicht Tage damit, das Problem zu finden, falls es eines gibt, und Sie können beruhigt sein, da Sie wissen, dass Sie UND Ihre Kollegen von den Änderungen überzeugt sind. Einige Entwicklungsteams veranstalten tägliche Stand-ups, in denen sie äußern, woran sie arbeiten. Es hilft dem Team, besser zu wissen, woran Sie arbeiten und ob die Gefahr besteht, dass Ihre Änderungen mit denen anderer kollidieren.

Du lernst, indem du es tust. Wenn Sie sich mit Sprachen wie C# auskennen, lernen Sie Java vielleicht schneller kennen, als Sie denken!

Diese Situation passiert von Zeit zu Zeit - Sie tun etwas, das unvorhergesehene Auswirkungen auf etwas anderes hat, von dem Sie vorher nichts wussten.

Die Tatsache, dass Sie nicht sofort entlassen oder auf einen PIP gesetzt wurden, bedeutet, dass das Unternehmen erkennt, dass Fehler passieren, sie aussortiert werden und das Leben entsprechend weitergeht.

Was können Sie dagegen tun? Informieren Sie sich über diese Konsequenz und prüfen Sie, ob es etwas anderes gibt, das Sie hätten berücksichtigen sollen, oder ob Sie ein anderes Team zu den Folgewirkungen einer API-Änderung hätten befragen sollen.

Das alles gehört zum Sammeln von Erfahrungen dazu und sollte Sie nicht davon abhalten, weiterzumachen.

Die Möglichkeit, dieses Problem zu vermeiden, bietet Ihnen auch die Möglichkeit, einen wesentlichen Beitrag zu Ihrem neuen Unternehmen zu leisten: Die Wurzel dieses Problems sind unzureichende Tests, nicht Sie (es sei denn, Sie waren auf eine Weise fahrlässig, die in Ihrem Beitrag nicht auftaucht).

In allen Entwicklungsumgebungen sollte es möglich sein, vor dem Einchecken herauszufinden, ob die von Ihnen vorgenommene Änderung einen größeren Fehler verursachen wird, und herauszufinden, ob der Code den Build beschädigen wird. Während es sicherlich peinlich ist, derjenige zu sein, der ein so klaffendes Ganzes in den Prozessen des Unternehmens findet, können Sie jetzt führend sein, wenn Sie versuchen, einen solchen Prozess in Ihrem neuen Unternehmen zu etablieren.

Sie können vorschlagen, dass das Team mit dem Schreiben von Unit-Tests beginnt und mit der Einrichtung einer kontinuierlichen Integrationsumgebung beginnt, die das Projekt neu erstellt und die Unit-Tests jedes Mal ausführt, wenn Code eingecheckt wird, und in der die Tests einzeln vor dem Einchecken ausgeführt werden können. Die Einheitentests erfordern Engagement des Teams, aber eine grundlegende CI-Umgebung kann ziemlich schnell aus Open-Source-Projekten eingerichtet werden, solange Sie eine VM oder einen Server dafür bereitstellen können.

Bearbeiten: Code-Reviews sind eine weitere gute Programmierpraxis, die diese Art von Fehlern minimieren kann und auch ziemlich einfach in Gang zu bringen ist.

TL;DR nutzen Sie diese peinliche Gelegenheit, um die Entwicklungsprozesse Ihres Unternehmens zu modernisieren. Du wirst nach Rosen riechen.

Das Problem tritt auf, dass die API in einer BPMN-Workflow-Datei referenziert wird, die nicht angezeigt wurde, als ich in der IDE nach den Referenzen oder dem API-Namen als Text gesucht habe.

Was haben die Teams in Bezug auf diesen Vorfall rückblickend herausgefunden? Welche Abteilungsverfahren könnten eingerichtet werden, damit sich dies nicht wiederholt? Was ist nach Ansicht des Teams beim Onboarding neuer Entwickler notwendig? Und welche neuen Onboarding-Verfahren sollen entwickelt werden?

PS In den oben genannten Bereichen proaktiv zu sein, ist eine großartige Möglichkeit, zu lernen und zu führen.

Wo wurden die BPMN-Dateien gespeichert, sodass sie bei der Suche nach anderen API-Konsumenten nicht sichtbar waren?

Das Problem hört sich so an, als ob Sie nicht alle API-Konsumenten kannten/auf sie Zugriff hatten.

Wenn sie nicht Teil Ihres standardmäßigen Entwicklungsarbeitssatzes sind und aus irgendeinem Grund nicht hinzugefügt werden können, müssen alle APIs, die bis dahin verwendet werden, in gleichwertigen Kopfzeilenkommentaren für Methodenaufrufe dokumentiert werden. Je nachdem, wie formal Ihr Überprüfungsprozess ist, kann die ausdrückliche Bestätigung, dass sie nicht betroffen sind, eine gültige Prozessänderung sein.

Das Problem, dass Sie nicht über alles außerhalb der Codebasis, an der Sie arbeiten, Bescheid wissen, muss bei Ihrem nächsten Standup/Ihrer nächsten Retrospektive von Ihnen angesprochen werden, wenn Ihre Kollegen dies nicht tun. So etwas sollte im Rahmen Ihres Einstiegs in das Projekt behandelt worden sein.

Du musst deine Denkweise ändern.

Sie haben keinen „kritischen Fehler“ gemacht. Sie haben nach besten Kräften gearbeitet; Sie waren offen für die Arbeit in einer unbekannten Umgebung; Sie waren transparent in Bezug auf Ihr Wissen und alles andere, davor und danach; Sie haben mit den anderen Jungs zusammengearbeitet, um das Problem zu beheben, Sie haben vermutlich keinen Wutanfall im Büro bekommen. Nach dem Debakel kommen Sie hierher und versuchen, sich noch weiter zu verbessern.

Kurz gesagt: Ich würde mir die Finger lecken, mehr Mitarbeiter wie Sie zu haben.

Zur Beantwortung Ihrer Frage:

1. Sie persönlich können solche Dinge im Allgemeinen nicht vermeiden. Der technische Fehler lag vollständig außerhalb Ihres Einflussbereichs. Wenn Sie 100% sicher sein möchten, würden Sie bis zum Stillstand mahlen. Sie können keine Teile eines Systems überprüfen, von denen Sie nichts wissen.
2. Systeme (einschließlich Computer und Menschen) können auch nicht so gebaut werden, dass sie solche Dinge vermeiden, sobald sie komplex genug werden.
3. Eine Möglichkeit, dies anzugehen, ist der DevOps/Agile-Ansatz , Fehler einzuladen und hart und schnell zu scheitern. Darum geht es bei allen CI- und besonders bei CD-Sachen. Sie setzen so häufig und schnell ein, dass Sie sehr oft scheitern werden ; und jedes Mal, wenn Sie den jeweiligen Grund mit höchster Priorität beheben (unter Verwendung der üblichen Techniken - automatisierte und manuelle Tests, schmerzloses Rollback kleiner Commits, Blau-Grün-Bereitstellungen mit Rollback-Umschaltung im Handumdrehen usw.). Dies führt logischerweise dazu, dass der gesamte Prozess sehr schnell robuster wird. Idealerweise machst du das ab Tag 0. Einfach? Nein. Kann Stück für Stück verbessert werden? Ja.

Unabhängig davon, was Sie oder andere tun, um Fehler zu minimieren, Fehler werden passieren .

Natürlich gibt es technische „Best-Practices“, die helfen, und ja, es gibt all die Plattitüden über das Lernen aus Fehlern. Aber das hast du alles, wie es scheint. Trotzdem fühlst du dich immer noch so schlecht wegen des Vorfalls, dass du dir die Zeit genommen hast, es auf jobs.stackexchange.com zu schreiben?

Ich denke, es gibt etwas Greifbares, das Sie tun können, das Ihnen und den anderen helfen wird, sich bei dieser ganzen Sache besser zu fühlen.

Das Beste, was Sie tun können, ist, die Freundlichkeit und Großzügigkeit, die Ihnen gezeigt wurde, zur Kenntnis zu nehmen und sich dafür zu bedanken .

Anstatt sich noch ausgiebiger zu entschuldigen und schnell vergessene „Nie wieder“-Versprechungen abzugeben, nehmen Sie sich die Zeit, den Leuten, die bei der Lösung des Problems geholfen haben, und denen, die Ihnen Unannehmlichkeiten bereitet haben, persönlich zu DANKEN. Wenn es angebracht ist, bringen Sie zum Beispiel eine Schachtel Donuts mit ins Büro und ergänzen Sie Ihre Kollegen.

Und wenn dann das nächste Mal etwas passiert und jemand anderes einen Fehler macht, sei nett zu ihm, hilf ihm und erwidere die Freundlichkeit, die dir zuteil wurde . Das ist es. Ihr werdet wegen solcher Dinge ein besseres Team sein.

Machen Sie Ihre Commits so klein wie möglich und wenn Sie nach jedem Push vom Build-Server bauen können. (Wenn es nicht oft gebaut wird, möchten Sie vielleicht auch vor Ihrem Push bauen!)

Das wird Ihnen nicht helfen, keine Fehler zu machen, aber es wird sie viel weniger kritisch machen. Wenn Sie wissen, welches Commit/welche Gruppe von Commits den Build zum Absturz gebracht hat, ist es trivial, es zurückzusetzen, während Sie an dem Problem arbeiten, und wenn Commits so klein wie möglich sind, ist es einfacher, die Ursache des Problems zu finden.

Wenn Sie git verwenden, gibt es sogar einen Befehl, der dabei hilft: git-bisect , mit dem Sie eine binäre Suche durch eine Gruppe von Commits durchführen können, um denjenigen zu finden, der das Problem verursacht.