Wie codieren Sie, ohne zu beleidigen?

Was ich damit meine ist, wie entwickeln Sie auf einer Codebasis, die Sie mit Entwicklern teilen, die jahrelang daran gearbeitet haben und mit ihr sehr vertraut sind?

Ich möchte niemandem auf die Zehen treten, aber ich bekomme keine so subtilen Beschwerden darüber, wie ich Dinge tue, ob ich meinen Code mit Leerzeichen schreibe oder wie oft ich mich bei SVN einchecke (zu oft). Obwohl ich diese Dinge leicht ändern kann, möchte ich im Allgemeinen ein besserer Teamentwickler sein.

Ich bin nicht sicher, was ich tun soll, außer zu fragen, aber vielleicht habt ihr ein paar Gedanken, die ich umsetzen könnte.

AKTUALISIEREN

Es gibt keinen Styleguide, über den man sprechen könnte - es ist nur so, dass die Leute nicht daran gewöhnt sind, die Codebasis zu teilen. Jeder hat seine eigene kleine Code-Welt.

Dies ist ein Perl-Shop, aber ich bin sicher, dass diese für jede Sprache gelten

UPDATE 2

Der CTO, der später CEO wurde, war ein absoluter Größenwahnsinniger und die Hauptursache für diese Beschwerden. Wenn Sie Dinge nicht genau so taten, wie es ihm gefiel, ob es sich um einen Mac oder einen Emac handelte, oder um vier Tabulatoren anstelle von zwei oder um eine bestimmte Kleidung, waren Sie minderwertig. Es war eine schreckliche Situation, die ich zu korrigieren versuchte, aber die einzig richtige Antwort für mich war zu gehen.

Ich bin davon überzeugt, dass dies ein Fall von Mobbing an einem Arbeitsplatz war, und bin mir in der Folge besser bewusst, was subtiles Mobbing und unangemessenes Verhalten in einer Arbeitsumgebung sein könnte.

Wenn ein Entwickler nach Antworten auf eine solche Situation sucht, verlassen Sie diese sofort. Sie können sich nicht aus einer schlechten Team-Situation herausarbeiten.

Fragen. Fragen Sie also die Leute, mit denen Sie arbeiten. Geben Sie Ihr Bestes, um den festgelegten Stil des vorhandenen Codes beizubehalten. Fragen Sie vor allem, ob es eine Dokumentenliste mit Kodierungsstandards gibt, und befolgen Sie diese. Wenn es keinen gibt, schreiben Sie einen ersten Entwurf auf der Grundlage dessen, was Sie im Code beobachten, und bitten Sie die anderen Teammitglieder, ihn zu kritisieren. Sie werden dem Unternehmen (und neuen Entwicklern, die nach Ihnen kommen) einen Service anbieten, indem Sie damit beginnen, die akzeptierten Codierungspraktiken zu dokumentieren. Das einzige Risiko besteht möglicherweise darin, sich in der Mitte zu verfangen, wenn sich herausstellt, dass die Oldtimer nicht einig sind, was akzeptabel ist oder nicht.

Hab auch keine Angst, du selbst zu sein . Sie sind vielleicht der Neue, aber Sie sind ein Mitglied des Teams, und Ihre Meinungen sind gültig. Wenn Sie bessere Möglichkeiten finden, etwas zu tun, schlagen Sie es vor. Respektiere die anderen Teammitglieder und die etablierte Art, Dinge zu tun, aber lass dich nicht herumschubsen. Das Unternehmen hätte Sie nicht eingestellt, wenn es Ihren Input nicht gewürdigt hätte.

Es ist sehr hilfreich, wenn Sie jemanden im Team finden, der freundlich und besonders bereit ist, Fragen zu beantworten. (Wenn es ein gutes Team ist, sollte es jeder sein, aber Teams sind nicht immer so.) Ihr Chef hat möglicherweise jemanden beauftragt, der Ihnen den Einstieg erleichtert. Verwenden Sie diese Person als Ressource. Notieren Sie sich die Fragen, die Ihnen gerade einfallen, und bitten Sie diese hilfreiche Person, sie von Zeit zu Zeit zu beantworten.

Wenn Sie den Code "zu oft" einchecken möchten, erstellen Sie doch einen eigenen Zweig für Ihre regelmäßigen Commits und führen Sie ihn dann wieder zum Trunk zusammen, wenn der Code fertig ist. Das kann niemandem schaden, und wenn Ihre Kollegen sehen, dass Sie von SVN profitieren, das sie möchten, können sie Ihrem Beispiel folgen.

Was Whitespace betrifft: Mach es einfach, aber der Code macht es schon. Geh mit dem Fluss.

In Bezug auf SVN-Eincheckvorgänge: Dokumentieren Sie diese sehr deutlich. Das hilft den Leuten zu verstehen, was im Code vor sich geht. (Follow-up: Was sind ihre Einwände gegen die häufigen Einchecken?)

Im Allgemeinen: Beginnen Sie mit dem Aufbau eines Kodierungsstandarddokuments. Versuchen Sie nicht, es mit 100 Regeln zu füllen. Fügen Sie einfach Regeln hinzu, wenn sie auftauchen.

Außerdem: Stellen Sie Fragen an Ihre Mitentwickler. Das gibt ihnen die Möglichkeit, abzuwägen, bevor Sie etwas tun, das ihnen nicht gefällt. Außerdem werden Beziehungen aufgebaut. Außerdem erfahren Sie mehr über die Funktionsweise des Shops.

In Bezug auf den Formatierungsstil des Codes (Leerzeichen, Tabulatoren, geschweifte Klammern usw.) sollten Sie den im Code geltenden Standard befolgen. Wenn es keinen gibt, glaube ich, haben sie nicht viel zu meckern. Wenn es darum geht, ob Sie Klammern in eine eigene Zeile setzen oder nicht, ob Sie Leerzeichen um Methodenparameterlisten setzen usw., ist Ihre persönliche Präferenz und Sie sollten dem vorherrschenden Stil nachgeben, da dies auf lange Sicht nicht der Fall ist Materie . Was zählt, ist konsequent zu sein.

Wenn es um das Einchecken von Code in SVN geht, würde ich versuchen zu evangelisieren, was meiner Meinung nach der richtige Weg ist, Dinge zu tun, anstatt mich dämpfen zu lassen. Ich checke meinen Code nur ein, wenn er erstellt und Tests bestanden hat. Wenn ich mehrere unabhängige Änderungen vornehme, teile ich meine Arbeit in mehrere Commits auf. Wenn etwas für eine Weile kaputt geht, erstelle ich eine Filiale und arbeite dort. Commits erhalten beschreibende Kommentare. Dies funktioniert meiner Erfahrung nach besser als die Methode "Einchecken eines Stapels von Änderungen am Freitag um 5:00 Uhr", und es scheint die vorherrschende "Best Practice" zu sein, so wie ich es hier und anderswo gelesen habe.

Lesen Sie zuerst das Dokument mit den Kodierungskonventionen (wenn sie keine haben, bitten Sie sie, eine zu schreiben, damit Sie sie befolgen können).

Nehmen Sie dann Notiz und bemühen Sie sich bewusst, dem und dem, was sie sagen, zu folgen. Es mag Ihnen so erscheinen, als wären sie hart, aber Codierungsstandards sind wichtig. Es ist besser, jetzt darauf hinzuweisen, was falsch ist, als es später zu einem Problem werden zu lassen, wenn Sie größere Änderungen vornehmen.

Ich bin mir sicher, dass Sie in ein oder zwei Jahren dasselbe tun werden, wenn Ihnen ein Neuling auf die Zehen tritt :)

Fragen Sie nach den Buchungskreisstandards. Achten Sie mehr auf Details. Wenn Sie sehen, dass andere einer bestimmten Form von Leerraum- und Klammermustern folgen, folgen Sie ihnen. Als Sr. könnte man argumentieren, dass dies nicht sehr wählerisch ist, aber als Jr. oder neuer Typ in einem Projekt muss man zeigen, dass man folgen kann, bevor man führen kann.

Verstehen Sie auch, dass alle neuen Entwickler in einem Projekt in der Tat eine notwendige "Anlaufzeit" haben. Also sorge dich nicht darum.

Das Beste, was Sie tun können, ist den Ratschlägen zu folgen, die sie Ihnen geben. Es gibt keine Möglichkeit, im Voraus zu sagen, was sie wollen. Es sei denn, Sie sind Hellseher.

Ich würde jedoch vorschlagen, dass Sie dies dokumentieren, wenn die Leute Ihnen Ratschläge geben. Hast du ein Wiki? Wenn ja, benutze es. Andernfalls ist eine mit dem Quellcode eingecheckte Textdatei möglicherweise eine gute Idee. Bauen Sie eine gut organisierte Programmieranleitung auf. Es hilft Ihnen, sich daran zu erinnern, wie Dinge zu tun sind, und wenn jemand einem früheren Rat widerspricht, der Ihnen gegeben wurde, gibt es Ihnen einen Bezugspunkt, um die Inkonsistenz zu diskutieren. Wenn die nächste Person dem Team beitritt, muss sie nicht das durchmachen, was Sie durchmachen.

Ich würde vorschlagen, dass Sie den Ratschlag im Dokument nicht Einzelpersonen zuordnen ("Codeblöcke sollten um drei Leerzeichen eingerückt werden", nicht "Bill hat mir gesagt, dass Codeblöcke um drei Leerzeichen eingerückt werden sollten"). Wenn Sie diese Informationen jedoch auf unauffällige Weise aufzeichnen können (z. B. schreiben Sie im Festschreibungskommentar eine "hinzugefügte Regel zum Einrücken auf der Grundlage von Bills Ratschlägen"), ist dies möglicherweise hilfreich, um Widersprüche aufzulösen, da Sie sofort zwei Standpunkte erhalten können auf etwas. Was ich hier wirklich denke, ist, dass Sie, wenn Sie widersprüchliche Ratschläge erhalten, vermeiden müssen, dass zwei Kollegen, die sich über etwas nicht einig sind, auf den Fußball treten. Es ist ein bisschen wie ein Cover-your-Ass-Ansatz, aber es könnte umsichtig sein.

Eine einfache Möglichkeit ist es, den Styleguide zu finden und ihm zu folgen. Die meisten haben nichts zu Beleidigendes an sich und werden Sie daran hindern, andere zu beleidigen.