Würde/sollte der PM den Codestil für ein Softwareprojekt definieren?

Ich würde sagen, es liegt in der Verantwortung des Teams, wahrscheinlich unter der Leitung eines technischen Leiters, sich auf den Syntaxstil zu einigen. Wenn ein PM jedoch glaubt, dass es einfach chaotisch ist, hat er das Recht, dies mit dem Team als potenzielles Problem zu besprechen.

Versuchen Sie, keine Richtlinien oder Stile einzuführen, die nicht automatisch durchgesetzt werden können.

Projektmanager sollten damit nichts zu tun haben, auch wenn sie über die erforderlichen technischen Kenntnisse verfügen.

Apropos Kommentare. Dies wird von Organisation zu Organisation unterschiedlich sein. Unsere Kultur ist, dass wir den Code nicht kommentieren. Der Code muss sauber sein, und wenn er Kommentare benötigt, müssen wir ihn wahrscheinlich refaktorisieren. Wir sind ein Team von über 20 Entwicklern, die an einem großen Unternehmenssystem arbeiten.

Die folgenden Personen sollten an der Definition von Code-Richtlinien beteiligt sein:

1. Führende Entwickler (Front-End, Serverseite sowie Datenbank) müssen einbezogen werden, um Richtlinien festzulegen, von denen sie glauben, dass sie die Codequalität in ihren Abteilungen verbessern werden.
2. CI (Continuous Integration) oder jemand, der für den Build-Zyklus verantwortlich ist, muss einen Mechanismus implementieren, der diese Richtlinien durchsetzt. Beispiel: Der Build muss fehlgeschlagen sein, wenn es mehr als drei Verstöße gegen bestimmte Richtlinien gibt. In .NET kann dies alles mit StyleCop und TFS erreicht werden

Alles unter einem Projekt befindet sich im PM-Bereich. Bei relativ großen, komplexen Projekten weiß der PM jedoch einfach nicht alles. Und eine Entscheidung wie diese und viele andere ausdrücklich seine/ihre Entscheidung zu treffen, impliziert einen autoritären Ansatz. Es ist in der Tat ausdrücklich seine/ihre, einfach weil der PM die verantwortliche Rolle für den Erfolg des Projekts hat. Aber der PM muss die Intelligenz des Teams nutzen, um zu solchen Entscheidungen zu gelangen, selbst wenn das Teamergebnis für den PM kontraintuitiv ist, egal wie unbequem das sein mag.

Ich denke, für so etwas ist der beste Ansatz des PMs, die Entscheidung mit dem Team zu erleichtern, die Entscheidungsmethode festzulegen, Konflikte und Knackpunkte zu lösen, alle anderen Hindernisse für eine Entscheidung zu beseitigen, die es geben könnte, und den Trumpf zu ziehen Karte, das Team nur als letzten Ausweg zu überstimmen.

Anstatt den PM den Stil definieren zu lassen, würde ich vorschlagen, dass vereinbarte Unternehmensstandards nicht existieren, sollte ein entsprechend qualifizierter technischer Leiter die Aufgabe erhalten, die Codierungsstandards, Qualitätserwartungen usw. für den Code zu definieren. Auf diese Weise bleibt die Verantwortung beim PM, aber die technischen Entscheidungen liegen dort, wo sie sollten: bei den Spezialisten für Entwicklung / technische Lieferung.

Ebenso sollte der PM nicht derjenige sein, der die Anwendung der Standards überprüft. Das ist die Aufgabe der Projektsicherung. Die Ausnahme hiervon kann sein, wenn der PM auch die Entwicklung überwacht, aber in einer solchen Situation kann argumentiert werden, dass der PM zwei oder mehr Rollen erfüllt und die Qualitätssicherung als Teil einer der anderen Rollen durchgeführt wird.

Während in der Tat alles an einem Projekt als die Domäne des Projektmanagers angesehen werden kann, mag ich die Analogie mit dem „Kapitän des Schiffes“. Bei einem kleinen Boot kann der Kapitän den Motor reparieren, für das Einpacken und Verteilen von Sandwiches usw. verantwortlich sein. Auf einem größeren Boot spezialisieren sich andere auf diese Bereiche und der Kapitän sorgt dafür, dass alle Leute zusammenarbeiten.

Warum können Sie (als PM) für den speziellen Fall von Codestandards und -stil nicht einfach sagen, dass Sie erwarten, dass das Team eine Reihe von Standards hat? Sie müssen sie nicht direkt überprüfen oder genehmigen. Zu sagen, was erwartet wird, zu erklären, warum es erwartet wird, und Ihr Team zu befähigen, Ergebnisse zu liefern, funktioniert in diesen Situationen wirklich gut.

Wenn Sie die Experten des Unternehmens für Codierungsstandards sind, müssen Sie Ihren Stil als PM möglicherweise etwas anpassen. Diktieren Sie nicht die Standards, aber stellen Sie bei der Kommunikation mit dem Team Fragen, die ihnen beim Lernen helfen. (z. B. "Wie haben Sie die Übergabe des Codes an das Wartungsteam nach der Veröffentlichung berücksichtigt?"), Wenn sie dann Fragen haben, können Sie allgemeine Vorschläge machen, keine Lösungen. Lassen Sie sie die Antworten selbst entdecken und durch praktische Anwendung lernen. Es mag kurzfristig schmerzhaft sein, aber es baut großartige Teams auf, die weiter lernen und sich verbessern.

Jede IDE hat eine Tastenkombination, die einen Codestil auf die aktuelle Datei anwendet. In den meisten Fällen wird dies der Codierungsstandard für die jeweilige Programmiersprache sein. Es gibt auch Tools, die die richtige (standardmäßige) Benennung und Schreibweise von Code vorschlagen. Ich habe das mit ReSharper zB gesehen

Daher möchte ich alle Entwickler ermutigen, diese Verknüpfungen zu verwenden und diesen Vorschlägen zu folgen.

Diese Features können auch an den Firmenstandard angepasst werden. Stellen Sie dann sicher, dass alle Entwickler die gleiche Konfigurationsdatei des Firmenstandards verwenden.

Normen sind einfach. Sie sind von den Normungsgremien sehr gut dokumentiert. Das W3C hat sehr klare Definitionen, wie semantisch gültiges HTML-Markup aussieht. Ebenso hat Oracle sehr klare Benennungsstandards für Klassen, Schnittstellen und Methoden.

Tatsächlich sollte jeder Student der Softwaretechnik einmal in Programmierstandards eingeführt werden, wenn nicht während seiner gesamten Universitätskarriere.

Egal in welchem ​​Bereich wir tätig sind, das Hauptziel unserer Ausbildung ist es, uns allen eine Grundlage für die Kommunikation mit anderen Experten auf unserem Gebiet zu bieten. Codierungsstandards sind nur eine gängige Methode, um sicherzustellen, dass ein Entwickler einer Schule in Maryland einspringen und mit der Arbeit an einer sehr großen Unternehmensanwendung beginnen kann, die von einem Entwickler in Großbritannien, Oregon, Kalifornien oder Indien entwickelt wurde.

In der Betriebswirtschaftslehre werden viele der Terminologien von Region zu Region verwendet, wie z.

Standards helfen dabei, sicherzustellen, dass alle auf der gleichen Seite stehen und eine gemeinsame Basis haben. Sie gehen auch weit über die Kommunikation hinaus in den Bereich des guten Anwendungsdesigns.

In Bezug auf die Entwicklung von Google App Engine erstellen Google-Ingenieure Beispielprojekte, die beschreiben, was sie – die technischen Experten auf ihrer Plattform – für den besten Ansatz zum Erstellen einer skalierbaren, erweiterbaren Anwendung auf ihrer Plattform halten.

Für Spring posten die Spring-Entwickler sehr detaillierte Informationen in ihrer Dokumentation sowie in ihren Blogs, wie man Situationen angeht, wie das Marshalling und Unmarshalling von Objekten von Java nach XML/JSON und umgekehrt.

Ich weiß, dass die anderen Entwicklungsplattformen ähnliche Standards haben.

Wenn ich wissen möchte, wie ich etwas integrieren kann, das ein Entwickler in unserem Unternehmen erstellt hat, konsultiere ich diesen Entwickler, meinen Kollegen. Wenn ich wissen möchte, wie ein Entitätsobjekt ordnungsgemäß im JDO-Datenspeicher von Google App Engine gespeichert wird, wende ich mich an die Google-Ingenieure, die Google App Engine entworfen und erstellt haben. Wenn ich wissen möchte, wie ein Objekt ordnungsgemäß zurück nach Java deserialisiert wird und ich Spring verwende, konsultiere ich die Spring-Entwickler-Community.

Kurz gesagt, die Entscheidungen über Standards müssen bei den technischen Experten liegen, sei es der PM, ein Entwickler einer externen JavaScript-Bibliothek wie John Resig von JQuery oder ein Entwickler, der ein Modul in unserem Unternehmen erstellt hat. Wer sich nicht an diese professionellen Standards hält, hat ernsthaften Erklärungsbedarf. Ich werde nicht sagen, dass sie falsch liegen, aber sie sollten auf jeden Fall darauf vorbereitet sein, zu erklären, warum sie die Weisheit der Experten ignorieren und einen alternativen Ansatz wählen. Best Practices und Codierungsstandards sollten nicht diktiert werden, aber es gibt sehr reale Gründe, warum sie existieren. Sie zu ignorieren sollte nicht auf die leichte Schulter genommen werden, und das Ignorieren ihrer Notwendigkeit sollte genau geprüft werden.

Es müsste ein sehr technischer PM sein, um die Besonderheiten eines Standards zu erzwingen. Dies scheint in den Bereich zu fallen, jemandem zu viele Details darüber zu erzählen, wie er seine Arbeit zu erledigen hat. Wenn es einen technischen Vorsprung gibt, sollten Sie es ihm überlassen, obwohl es fair ist, eine Art Standard zu verlangen.

Stellen Sie sich das so vor... Sie sind der Leiter eines Veranstaltungsplanungskomitees. Sie möchten sicher sein, dass der von Ihnen engagierte 5-Sterne-Koch das bestmögliche Abendessen zubereitet. Es ist in Ordnung, wenn Sie nach einer Liste der Zutaten fragen, um sicherzustellen, dass sie daran denken, die richtige Menge an Essen zuzubereiten, aber Sie würden nicht vorschlagen, um welche Zutaten es sich handelt.

PM sollte niemals Codierungsrichtlinien festlegen. Nur das Entwicklungsteam ist dafür verantwortlich und es wird für das Team demotivierend sein, wenn PM diese Richtlinien von oben festlegt.

PM kann jedoch auf das Vorhandensein von Codierungsrichtlinien bestehen und diese vom Entwicklungsteam verlangen.