it-swarm.com.de

Wie bringt man alle in Bezug auf die Codierungseinstellungen in einem kleinen Team auf die gleiche Seite?

Angenommen, Sie haben 10-50 Ingenieure, die an einer Codebasis arbeiten. Jeder hat andere Vorlieben für diese Art von Dingen:

  • Ordnerstruktur
  • Namenskonventionen (CSS-Klassennamen, Funktionsnamen, Variablennamen usw.)
  • Testkonventionen
  • Ausdrucksort (wo Variablen in einer Datei definiert sind usw.)
  • Kapselung (sollte dies in ein Dienstprogramm, eine Klasse usw. gehen)
  • So schreiben Sie bestimmte Ausdruckstypen
  • usw.

Wenn Sie alle tun lassen, was sie wollen, entstehen viele Konflikte und die Leute werden wütend. Wenn Sie einen bestimmten Styleguide erzwingen, sehen Sie möglicherweise keine bestimmten Anwendungsfälle voraus und haben viel Boilerplate. Wenn "Führung" die Richtung wählt, fühlen sich die Menschen ausgeschlossen.

Wie entscheiden Sie sich im Allgemeinen für einen bestimmten Präferenzsatz (d. H. Es geht nicht darum, ob es sich um eine Ordnerstrukturdiskussion oder um CSS-Namenskonventionen handelt)?

4
Lance Pollard

Matts Antwort gibt gute Ratschläge (sowie Robert Harveys Kommentare zu der Frage), aber beide sind meiner Meinung nach unvollständig in Bezug auf die Frage, wie bis zu 50 Personen an Bord kommen können. Die organisatorischen Probleme beim Versuch, 5 Personen dazu zu bringen, an demselben Standard zu arbeiten, unterscheiden sich erheblich von den Problemen, mit denen Sie konfrontiert sind, wenn Sie 50 Personen verwalten müssen.

Vor ungefähr 20 Jahren war ich in einer solchen Situation, in der wir einige Teams von insgesamt ungefähr dieser Größe für ein neues Projekt hatten, und wir haben versucht, über einen Zeitraum von ungefähr 6 Monaten (!) Vorab Standards unter ihnen festzulegen. ). Es war keine völlige Katastrophe, aber definitiv nicht kosteneffektiv, und weitere Verbesserungen dieser Standards waren danach nur schwer zu erreichen. Wenn ich von heute zurückblicke, sehe ich einige Dinge, die wir dort besser hätten machen können:

  • Beginnen Sie mit einem kleineren Team von maximal 5-6 erfahrenen Entwicklern und geben Sie ihnen Zeit für einige Iterationen, um das Ökosystem, die Architektur und die Codierungsstandards des Systems zu prototypisieren. Dann skalieren - Leute, die später ins Team kommen, müssen die bereits vorgegebenen Standards übernehmen. Sie können weitere Verbesserungsvorschläge einbringen, aber keine vollständige Änderung "vom Boden" - zumindest nicht ohne ein Buy-In vom Management.

  • Ein 50-köpfiges Team ist zu groß, um alle "auf derselben Codebasis" vollständig zu arbeiten. In der Regel gibt es Unterteams für verschiedene Teile/Komponenten des Produkts. Bestehen Sie nicht darauf, dass jedes Subteam genau dem gleichen Standard folgt. Geben Sie ihnen selbst Raum für Verbesserungen. Der Kommunikationsaufwand lohnt sich normalerweise nicht, und wenn Sie einen Entwickler von einem Unterteam in ein anderes verschieben müssen, kann der Entwickler normalerweise und schnell die "Variante des Standards" des einzelnen Unterteams übernehmen. In einer solchen Situation ist es wichtiger, starre Schnittstellen zwischen den Komponenten zu haben, als alle Komponenten im Inneren zu 100% auf ähnliche Weise strukturiert zu haben.

  • Stellen Sie sicher, dass Sie aus Gründen der Standardisierung nicht standardisieren. Halten Sie die "globalen Standards", die für alle gelten, auf das notwendige Minimum. Wenn es sich wirklich um ein kohärentes System handelt, das erstellt werden sollte, müssen Sie normalerweise das "Ökosystem" der beteiligten Frameworks/Programmiersprachen/Betriebssysteme, die globale Ordnerstruktur und die beteiligten Servertechnologien (Datenbank, Web, SCCS) standardisieren ). Aber lassen Sie kleinste Details wie "wo Variablen in einer Datei definiert sind" oder niedrigere Ebenen der Unterordnerstruktur auf die kleineren Unterteams. Der Versuch, solche Dinge für ein großes Team zu standardisieren, ist normalerweise nicht die Mühe wert.

6
Doc Brown

Verwenden Sie ein oder mehrere veröffentlichte Dokumente zu Codierungsstandards als Ausgangspunkt für Diskussionen. Viele große Organisationen haben ihre Standarddokumente für nahezu jede denkbare Sprache und jeden Rahmen im Internet frei verfügbar gemacht. Laden Sie einige dieser Dokumente herunter und verteilen Sie sie, damit das Team sie überprüfen und prüfen kann. Dadurch wird klargestellt, dass die Dokumente nur dazu dienen, die Diskussion zu erleichtern, und dass die Meinungen Ihres Teams eingeholt werden. Treffen Sie sich dann im Team von Angesicht zu Angesicht, um diese Standarddokumente zu überprüfen und den Menschen die Möglichkeit zu geben, sich für oder gegen bestimmte Regeln einzusetzen und zu entscheiden, welche Standards es wert sind, übernommen zu werden. Auf dem Weg werden Entwickler unweigerlich einige Regeln vorschlagen, die in keinem der veröffentlichten Standarddokumente enthalten sind, mit denen Sie begonnen haben, und das ist auch in Ordnung.

Diskutieren Sie, zielen Sie darauf ab, einen Konsens zu erzielen, halten Sie Stimmen ab, wenn bestimmte Regeln umstritten sind (Stimmen darüber, ob eine Regel überhaupt angenommen werden soll oder nicht, und überlassen Sie diese bestimmte Angelegenheit dem individuellen Ermessen und, falls eine Regel angenommen werden soll, was diese Regel sein sollte be) usw. Wenn der Diskussions- und Entscheidungsprozess fair und gerecht geführt wird, sollten Konsens und Buy-In erzielt werden, auch wenn nicht jeder mit jeder Regel im Standard zufrieden ist, weil er guten Grund zum Respekt hat der Prozess, der den Standard produzierte.

6
Matt

Konflikte entstehen, wenn die Abmitionen der Menschen aufeinander treffen. Sie können dies vermeiden, indem Sie ein automatisiertes System verwenden, das Konventionen erzwingt. Richtliniendokumente und Kodierungshandbücher sind wenig hilfreich, da sie interpretiert werden können. Das Festschreiben von Hook-Checking-Formatierungsregeln, Namenskonventionen usw. ist eine viel sauberere Lösung, die sicherstellt, dass jeder eine ähnliche Behandlung erhält.

2
god