Ich habe erwähnt, dass mein Compiler mir Fehler in diesen Zeilen gibt, aber er scheint zu glauben, dass es ein Fehler in meinem Computer-Setup ist.

An diesem Punkt sollten Sie aufhören und sicherstellen, dass Ihr Computer genau so konfiguriert ist wie er.

Wenn der Fehler weiterhin auftritt, bitten Sie um weitere Anleitung.

Meine Frage ist, ob ich ihm das noch einmal vortragen und meine Argumentation erläutern soll.

Nein. Ihnen wurde bereits gesagt, was das Problem ist. Es ist an der Zeit, zuzuhören, Ihren Computer zu reparieren und sich wieder den Dingen zuzuwenden, die in Ihren Verantwortungsbereich fallen.

Ist es eine gute Idee, dies weiter voranzutreiben, insbesondere angesichts meiner derzeitigen misslichen Lage?

Nehmen wir an, jemand, der mir berichtet, sagte, die Software würde nicht kompilieren. Nachdem ich nachgeforscht habe, stelle ich fest, dass sie nicht die richtigen Werkzeuge verwenden, also fordere ich sie auf, die Maschine zu reparieren, um sie in Übereinstimmung zu bringen.

Wenn diese Person dann zu mir zurückkäme und darauf bestand, dass das Programm mit dem falschen Werkzeugsatz kompiliert werden sollte, hätten wir ein "nettes" Gespräch darüber, wie ausgerechnet Programmierer verstehen sollten, wie man Anweisungen befolgt. Wenn es ein drittes Mal passierte, würde ich sie feuern.

Ich würde dringend vorschlagen, dass Sie Ihren Computer reparieren, bevor Sie dieses Problem erneut ansprechen. Informieren Sie sich dann darüber, warum sie diesen speziellen Compiler/diese spezifische Konfiguration ins Visier genommen haben. Es gibt einige Gründe, einen Compiler einem anderen vorzuziehen - bevor Sie verstehen, warum die anderen ausgeschlossen wurden, gibt es keinen Grund, darauf zu bestehen, dass sie verwendet werden.

Ich höre gerne jemandem zu, der mir sagt, dass ich falsch liege. Was ich jedoch nicht ertragen werde, ist, dass jemand behauptet, etwas sei falsch, bevor er sich die Mühe gemacht hat, das Problem oder die Gründe für die bereits getroffenen Entscheidungen zu verstehen.

Wenn das Projekt derzeit nur auf einer bestimmten Version eines bestimmten Compilers korrekt funktioniert, ist zu erwarten, dass derselbe Compiler auch in der endgültigen Version verwendet wird, es sei denn, dieser Compiler wird irgendwann in der Zukunft nicht mehr unterstützt - andernfalls Vielleicht gibt es einige gute Gründe, die Sie nicht kennen, um diesen speziellen Compiler zu verwenden.

Angenommen, Sie können dieses Projekt zum Laufen bringen, indem Sie Ihren Compiler ändern und die richtigen Config/Flags verwenden, ist dies nicht wirklich ein "Fehler" als solcher - es ist jedoch ein Indikator für eine potenziell fragile Projektkonfiguration, die auftreten könnte als potenzielles Risiko für das Projekt in der Zukunft - das scheint jedoch derzeit nicht der Fall zu sein; es klingt, als gäbe es noch keinen Grund, sich darüber Sorgen zu machen.

Die konstruktiven nächsten Schritte, die Sie unternehmen könnten, wären, zuerst Ihre Entwicklungs-/Test-/Build-Umgebung mit den richtigen Tools und Konfigurationen zu reparieren und dann diese anfänglichen Einrichtungsverfahren in Form einer Dokumentation zu erfassen (falls noch nicht vorhanden). ) - beispielsweise eine Readme-Datei, eine private Wiki-Seite, eine OneNote-Seite usw.

Während Sie Ihre Entwicklungsumgebung reparieren, notieren Sie sich alle einmaligen Schritte, an die Sie sich wahrscheinlich in ein paar Monaten nicht mehr erinnern werden. Zum Beispiel: "Install [Tool] [Version] into [Folder]", oder "Create an Environment Variable called [Name] set to [Value]", oder "edit [Configuration File] and change [Line] to [Something else]", usw.

Wenn eine solche Dokumentation bereits vorhanden ist, aber zufällig unvollständig/ungenau ist, können Sie diese Erfahrung sinnvoll nutzen, indem Sie die Dokumentation bearbeiten, um fehlende Informationen hinzuzufügen oder Anweisungen zu klären, die Sie selbst nur schwer verstehen oder befolgen konnten. Diese Informationen werden für Entwickler wertvoll sein, die sich Ihrem Projekt in Zukunft anschließen (oder sogar für Sie selbst, wenn Sie feststellen, dass Sie Ihr Betriebssystem neu installieren müssen).

Während ausgereifte Projekte in der Regel einen einfachen One-Step-Build-Prozess haben, erfordern neue und unvollständige Projekte oft andere klobige/unordentliche Verfahren, bis jemand Zeit hat, den Prozess zu rationalisieren. In Wirklichkeit braucht so etwas Zeit, um es zu verfeinern, und hat normalerweise eine niedrige Priorität im Vergleich zur Behebung echter Fehler und der Implementierung neuer Funktionen. Bis dahin ist es sinnvoll, die Projektkonfigurationsdokumentation auf dem neuesten Stand zu halten, damit neue Entwickler direkt in den Code einsteigen und schneller produktiv sein können.

Das Problem liegt woanders: Wie Sie sagen, wird auf Ihrem PC nicht kompiliert, aber auf seinem System funktioniert alles einwandfrei.

In allen Unternehmen, in denen ich je gearbeitet habe, gab es einen zentralen Build-Server: Jeder hat eine Programmierumgebung auf seinem eigenen PC, aber wenn ein Stück Quellcode geändert wird, wird dieser in ein zentrales Versionierungssystem, den zentralen Build-Server, eingegeben ruft dann die letzten Versionen aller Quellcodeteile ab und versucht zu kompilieren. Wenn dies funktioniert, ist alles in Ordnung. Wenn nicht, dann liegt ein Problem vor.

Das könnte also ein wertvoller Ansatz für Ihr Anliegen sein: „Mein Herr, wir haben hier die Situation, dass auf dem einen PC etwas funktioniert, auf dem anderen aber nicht Server bauen, und wenn wir in Zukunft jemals wieder in eine solche Situation geraten, wird dieses System darüber entscheiden, wer Recht hat."

Viel Glück

Suchen Sie nach einer Lösung, die bei beiden Setups funktioniert

Ein allgemeines Prinzip in solchen Situationen ist die Pfadfinderregel :

Lassen Sie den Code (mindestens) in der gleichen oder (vorzugsweise) besseren Form, als Sie ihn gefunden haben.

Ihr leitender Kollege hat also seine Entwicklungsumgebung auf eine bestimmte Weise eingerichtet. Dafür kann es viele Gründe geben, einige mögliche gute und sehr gültige, einige unnötige und vielleicht sogar schädliche.

Gute Gründe für dieses Setup können sein, dass ...

• Es beschleunigt Entwicklung, Debugging und/oder Bereitstellung
• Es enthält Funktionen, die in anderen Setups nicht vorhanden sind
• Es befasst sich mit der Abwärtskompatibilität, die für die Interoperabilität mit anderen Modulen erforderlich ist
• Der Wechsel zu einem anderen Setup kann umfangreiche Arbeit erfordern, um sicherzustellen, dass der Rest des Codes weiterhin wie beabsichtigt funktioniert _(*) .

Schlechte Gründe für dieses Setup können sein ...

• Faulheit oder anderweitig irrationaler Widerstand, die Entwicklungsumgebung auf dem Laufenden zu halten ("Bei mir läuft es gut, ich rühre es nicht an!")
• Vorurteil gegenüber neueren Versionen als "Unerprobt, daher unsicher".
• „Das haben wir schon immer so gemacht“

Was Sie hier tun können, ist, Ihren älteren Kollegen zu fragen : "Wie kommt es, dass Sie das verwenden? Gibt es einen bestimmten Grund?". Und sie werden es dir sagen. Vielleicht ist ihr Grund – Ihrer Meinung nach – gut und gültig, oder es wird – wiederum Ihrer persönlichen Meinung nach – ein schlechter Grund sein. Beachten Sie jedoch, dass sie höchstwahrscheinlich der Meinung sind, dass der Grund gültig ist.

Was am wenigsten Aufhebens machen würde, wäre, wenn Sie eine Änderung vornehmen, die auf beiden Setups funktioniert, vorausgesetzt, Sie führen die Änderung korrekt durch. Dazu muss man ein...

Checkliste

Wenn Sie die Scout-Regel anwenden und ein Problem "beheben" möchten, das nicht direkt mit Ihrer Arbeit zusammenhängt, wird es normalerweise geschätzt, wenn Sie dies tun. Aber nur, wenn Sie sicherstellen, dass das, was Sie tun, tatsächlich besser ist. Als solches müssen Sie sicherstellen, dass ...

1. Meine Änderungen werden nichts kaputt machen

Der Weg zur Hölle ist mit guten Vorsätzen gepflastert

Das erste, was Sie tun müssen, ist sicherzustellen, dass Ihr Fix nichts beschädigt. Die üblichen Sicherheitsvorkehrungen – keine Compilerfehler, Codeüberprüfung, automatisierte Tests – helfen Ihnen dabei. Vermeiden Sie es, einen Scout Rule Fix in den Hauptentwicklungspfad einzuchecken, verwenden Sie stattdessen den Nebenzweig des Codes und lassen Sie die Änderung vor allem anderen testen .

2. Meine Änderungen werden die Dinge nicht verwirrender machen oder unnötige Komplexität hinzufügen

Dieser Punkt ist ziemlich selbsterklärend. Es ist eine Tugend, den Code einfach und wartbar zu halten. Wenn Ihre Änderung dazu führt, dass es schwieriger wird, den Code zu lesen, zu erstellen oder bereitzustellen, lassen Sie die Änderung am besten weg. Wenn es jedoch ohne Änderung der Komplexität des Codes oder des Build- und Bereitstellungsprozesses hinzugefügt werden kann, ist es in Ordnung.

3. Meine Änderungen werden die Dinge verbessern

Genauso wie der leitende Entwickler denkt, dass sein Setup für ihn funktioniert, könnten Sie in dieselbe Falle tappen. Und obwohl eine Verbesserung für Sie Grund genug ist, eine Veränderung zu bewirken, möchten Sie vielleicht auch andere fragen: „Lohnt sich das?“. Wenn sie zustimmen, dass dies eine Verbesserung ist, dann fahren Sie fort.

_{(*) Ich hatte einen Codebruch, weil ich einfach auf eine neue Unterversion eines Entwicklungskits aktualisiert habe ... nicht einmal die Nebenversion, sondern die Unterversion .}

Um die Wahrscheinlichkeit zu erhöhen, dass er Ihre Eingabe akzeptiert, beginnen Sie nicht mit einem einfachen „Ich habe einen Fehler in Ihrem Code gefunden“. Nehmen Sie es von der Seite und bitten Sie ihn, sich zu Ihnen zu setzen und den Code durchzugehen, damit Sie die Logik verstehen.

Erklären Sie, was und warum Sie für falsch halten, und hören Sie sich seine Antworten an. Es gibt zwei Möglichkeiten:

1. Sie haben Recht, und er wird den Fehler verstehen, ohne sich über Ihre "kühne" Aussage zu "ärgern".
2. Sie liegen falsch, und Sie haben sich die Mühe gemacht, den Code mit ihm zu verstehen, ohne zu behaupten, er sei verwanzt.

Stellen Sie zunächst sicher, dass Sie die genauen Sprachregeln für die Software kennen. In der Regel werden neue Funktionen hinzugefügt, wenn sich Sprachen und ihre Standards weiterentwickeln. Manchmal haben bestimmte Compiler Funktionen, die über jeden formalen Standard hinausgehen. Welche Sprachfunktionen verwendet werden dürfen, ist normalerweise eine Entscheidung der erfahrenen Entwickler, kann aber von Marketingproblemen beeinflusst werden, wenn Kunden in der Lage sein müssen, den Code zu kompilieren. "Können wir die Spracherweiterung X verwenden?" ist eine legitime Frage, die Sie stellen sollten.

Wenn Sie vorhaben, mit dem leitenden Entwickler nicht einverstanden zu sein, welche Funktionen verwendet werden sollten, brauchen Sie sehr gute Gründe, warum es unbedingt so sein muss, wie Sie es vorschlagen. Wenn es nur um Meinungen und Vorlieben geht, gewinnt die Meinung des Senior Developers.

Nachdem Sie den beabsichtigten Satz von Sprachfeatures herausgefunden haben, müssen Sie als Nächstes sicherstellen, dass Ihr Compiler alle Features unterstützt, die die Regeln zulassen. Dies kann die Installation eines anderen Compilers, zusätzlicher Bibliotheken oder das Setzen von Compiler-Flags erfordern, um Funktionen zu aktivieren, die standardmäßig deaktiviert sind.

Wenn der Code nicht mit einem Compiler und einer Konfiguration kompiliert werden kann, die alle im Programm zulässigen Funktionen unterstützen, müssen Sie diesbezüglich ein Problem mit dem leitenden Entwickler besprechen.

Ich werde hier ein kleines bisschen vom Thema abschweifen und mich zwanghaft auf eine kleine Sache konzentrieren, die Sie gesagt haben ...

dumme Fehler meinerseits

Dafür gibt es eine Lösung. UNIT-TESTS ! Warum nicht für jede wichtige Funktion, die Sie schreiben, eine Reihe von Komponententests haben, die die erwartete Ausgabe für eine bestimmte Eingabe kennen? Während Sie diese Tests schreiben, werden Sie anfangen, über seltsame Grenzfälle in den Eingaben nachzudenken. Verdammt, für ein paar Schlüsselfunktionen schreiben Sie vielleicht sogar zuerst die Tests und beobachten, wie sie langsam von Rot zu Grün wechseln, während Sie Ihr fn implementieren.

Dieser Ansatz wird bei diesen „dummen Fehlern“ sehr hilfreich sein, da Sie explizit nach ihnen suchen, anstatt nur Code für die Qualitätssicherung über die Wand zu werfen.

Finden Sie heraus, welche Art von Unit-Test-Framework Ihre Gruppe verwendet. Wenn es keinen gibt (ich heule und knirsche hier mit den Zähnen), bitten Sie um etwas Zeit, um einen zu finden und zu instrumentieren. Es gibt viele gute mit ähnlichen Namen (nUnit, jUnit, xUnit, ...)

Sie werden es nicht bereuen.

Es ist ziemlich klar, dass Entwickler unterschiedliche Setups auf ihren Computern haben, und die Welt ist perfekt, wenn die Lösung auf ihrem eigenen Computer aufbaut.

Offensichtlich ist dies Quatsch und verlässt sich darauf, dass mindestens eine Person die Lösung in ihrer eigenen Sicht der Welt erstellt und bereitstellt.

Die Antwort ist die Standardisierung durch die Verwendung eines Jenkins- Build-Servers oder etwas Ähnlichem.

Wir haben einen für unsere großen Lösungen. Alle paar Minuten holt es sich die neuesten Codedateien aus dem Quellcode-Manager (in unserem Fall TFS) und versucht dann, die Lösung zu erstellen. Wenn der Build fehlschlägt, erhält jeder im Team automatisch eine E-Mail, und wer den Build kaputt gemacht hat, wird implizit benannt und beschämt.

Offensichtlich sind die Compiler-Optionen und die Umgebung auf dem Jenkins-Server Vanilla und auf einen vollständig gültigen/echten Build ausgerichtet.

Dadurch werden alle Mehrdeutigkeiten beseitigt, die durch Personen verursacht werden, die auf lokale Kopien von Quellcodes/DLLs in freier Wildbahn verweisen, und Sie werden keine Lösung bereitstellen, die auf ein Stück Code verweist, das auf dem Entwicklungscomputer einer anderen Person vorhanden ist.

Die Verwendung eines solchen Build-Servers nivelliert und standardisiert das Spielfeld und stellt eine vollständige Konsistenz des Endergebnisses sicher.

Tatsache ist, dass Sie das Problem bereits diesem leitenden Entwickler gemeldet haben. Was Sie wirklich fragen, ist nicht, wie Sie es melden können, sondern wie Sie ihn davon überzeugen können, eine Änderung vorzunehmen.

Sie haben Ihre Verantwortung erfüllt. Sie haben gemeldet, was Ihrer Meinung nach ein Fehler ist. Er ist der leitende Entwickler, er hat entschieden, dass Sie sich geirrt haben und der Code richtig ist, also das war's. Jetzt gibt es zwei Möglichkeiten: Entweder er hat Recht, oder er hat Unrecht. Wenn er falsch liegt, ist er entweder nicht sehr erfahren oder er ist dumm und akzeptiert nichts von einem Junior-Entwickler. In beiden Fällen bringt Sie Beharrlichkeit nicht weiter.

Anstatt einen Fehler im Code zu finden, bei dem Ihre Meinung gegen seine ist, finden Sie heraus, ob dies zu einem Fehlverhalten der Software führt. Das ist etwas, das objektiv überprüft werden kann und möglicherweise behoben werden muss. Wenn Sie nicht herausfinden können, wie dieser Fehler zu einem Fehlverhalten der Software führt, liegt entweder kein Fehler vor oder er ist unwichtig.