Ich beauftrage eine Vertragsfirma, eine kleine Anwendung für meine Gruppe neu zu schreiben. Das Entwicklerteam wird aus einer einzigen Person bestehen. Aufgrund früherer Erfahrungen mit anderen Entwicklern mache ich mir Sorgen, dass der produzierte Code funktionsfähig, aber inkonsistent gestaltet sein wird. Ich verhandle gerade über das Statement of Work.
Sollte ich etwas zu "Kundenverpflichtungen" über den Codestil hinzufügen? Was ist mit der Forderung nach Verwendung von ReSharper oder etwas Ähnlichem? Gibt es Beispielbausteine, die ich verwenden kann?
Ich habe die verwandte Frage zu einem PM gelesen, der den Codestil für Entwickler erzwingt. Diese Frage ist insofern anders, als ich nach dem Hinzufügen einer bestimmten Sprache zur SoW frage.
Sollte ich etwas zu "Kundenverpflichtungen" über den Codestil hinzufügen?
Sie können dies tun, aber Sie messen möglicherweise das Falsche. Das riecht nach einem X/Y-Problem: Sie müssen ein Problem mit der Übergabe der Ergebnisse lösen, haben entschieden, dass der Codierungsstil das Problem beheben wird, und versuchen jetzt, es nach dem „Codierungsstil“ und nicht nach dem zu lösen zugrundeliegendes Prozessproblem.
Stimmen Sie zwar zu, dass ein konsistenter Programmierstil wichtig ist, definieren Sie jedoch die Risiken, die Sie zu mindern versuchen. Erwägen Sie dann, Ihre Aufmerksamkeit auf messbare Qualitätsmetriken und Akzeptanztests als Projektkontrollen zu richten, anstatt auf Stilfragen als Proxy für Ihr tatsächliches Risikomodell.
Sie können alles, was Sie möchten, in eine Leistungsbeschreibung aufnehmen, aber dies ist nicht der Weg, um tatsächlich das zu bekommen, was Sie wollen. Ich interpretiere Ihre wahre Motivation als:
Was Sie hier wirklich tun möchten, ist sicherzustellen, dass die Ergebnisse einige definierte Kriterien (z. B. PEP-8 oder den Ruby Style Guide ) als Teil der "Definition of Done" erfüllen. Die Überschrift des Vertragsteils ist unerheblich; Was zählt, ist, dass Sie sicherstellen, dass der Vertrag festlegt, was ein akzeptables Qualitätsniveau für Ihre Leistungen ist (und nicht).
Dies unterscheidet sich nicht von einer Fabrik, die Bearbeitungstoleranzen für ein Produkt angibt. Sie müssen jedoch sicherstellen, dass Ihre Qualitätskriterien angemessen, konkret und messbar und nicht nur subjektiv sind. Aus diesem Grund ist die Verwendung eines dokumentierten Styleguides unerlässlich; Sie sollten den Käse der Entwickler wegen undokumentierter Spezifikationen nicht nachträglich verschieben.
Eine weniger strenge, aber möglicherweise ebenso nützliche Alternative sind Akzeptanztests. Akzeptanztests werden oft als etwas angesehen, das Endbenutzer durchführen, um eine Benutzeroberfläche oder Anwendungsfunktionalität zu testen, aber sie können auch auf Codelesungen oder Neuaufbauten angewendet werden, die von einem Entwicklungsteam durchgeführt werden.
Ihre Stilanforderungen sind wirklich nur Mittel zum Zweck: Kann mein internes Team oder jemand anderes als der ursprüngliche Entwickler den Code verstehen? Die einzige Möglichkeit, dies sicherzustellen, besteht darin, dass eine andere Person oder ein Team es sich ansieht, die Komponententests durchführt, den Code kompiliert oder versucht, einige Änderungen vorzunehmen. Ich nenne diesen Entwicklungsteam-Abnahmetest hiermit .
Es spielt keine Rolle, wie hübsch der Code ist. Code kann den ganzen Tag den Styleguides folgen und trotzdem schlecht dokumentiert, unnötig komplex oder falsch gestaltet sein. Stellen Sie sich zum Beispiel vor, Sie möchten eine Finanzanwendung von Dollar in Euro umwandeln; Wenn der exquisit schöne Code, den Sie als Ergebnis erhalten, es unmöglich macht, herauszufinden, wie man eine grundlegende Änderung wie diese vornimmt, dann ist der Code Spaghetti-Code, selbst wenn er richtig eingerückt ist.
Natürlich sollten diese Art von Abnahmetests Teil Ihrer dokumentierten Abnahmetestkriterien sein und als Teil der zu erledigenden Arbeit klar kommuniziert werden. Eine 100%ige Abdeckung aller Eventualitäten kann man nicht garantieren, aber eine Spezifikation, die besagt:
Alle magischen Zahlen werden als Modulkonstanten oben in der Moduldatei gespeichert.
ist für alle Projektbeteiligten viel besser als:
Stellen Sie sicher, dass Ihr Code hübsch aussieht, damit meine Augen nicht bluten.
Seien Sie so spezifisch wie nötig, aber lassen Sie genügend Spielraum, um sicherzustellen, dass die Richtlinien nicht zu einer Zwangsjacke werden. Denken Sie daran, dass Sie bekommen, was Sie messen, und wenn Sie die falschen Dinge messen, erhalten Sie einige großartige Gantt- oder Tortendiagramme und eine Reihe völlig nutzloser Ergebnisse.
Eine Leistungsbeschreibung sollte alles angeben, was Ihnen wichtig ist. Wenn der Programmierstil auf dieser Liste steht, ist theoretisch nichts falsch daran, ihn anzugeben, obwohl er das Risiko unbeabsichtigter Konsequenzen birgt. Andere Antworten sind darauf ausführlicher eingegangen.
In einem Unternehmen, in dem ich bis vor kurzem gearbeitet habe, hatten wir es satt, dass uns Web-Unterseiten ohne Dokumentation übergeben wurden, Abhängigkeiten sporadisch notiert wurden und das Ganze nicht ohne Weiteres in unser Umfangs-CMS integrierbar war. Wir haben uns entschieden, Entwicklern einen Klon (damals über Adobe AMI; jetzt denke ich, dass die Organisation Puppet verwendet) unseres Systems in all seiner vorhandenen Unordnung zur Verfügung zu stellen. Eine in die SOW geschriebene Akzeptanzbedingung war, dass der Code in ein VCS eingecheckt wird, sodass wir der Dokumentation folgen und ihn zum Testen und dann zur Produktion in einen anderen Klon unserer Bereitstellung einchecken können.
Es hat dem Ende des Prozesses und der „Definition of Done“ beträchtliche Vernunft verliehen. Es hat viele Anbieter von unserer Liste entfernt, aber auch diejenigen, die mit uns zusammengearbeitet haben, darüber informiert, wie sie ihre Arbeit am besten auf brauchbare Weise präsentieren können.
Sie können der SOW hinzufügen, was Sie wollen, was Sie kontrollieren oder verlangen möchten. Ob Sie dies tun sollten, hängt davon ab, was Sie aufgrund der Sprache erhalten im Vergleich zu den Kosten, den Risiken, die Sie dadurch eingehen, und anderen Strafen. Zum Beispiel ist "Kundenverpflichtungen" etwas mehrdeutig. Wie würde ein Entwickler dies in Bezug auf sein Risiko kontrollieren, dh sich ändernde Verpflichtungen, Rock nicht glänzend genug usw. Der Entwickler würde aufgrund dieser Sprache das Risiko in seinen Preis einbauen. Wenn fest fixiert, wird der Preis steigen. Wenn es für einen festen Preis zu riskant ist, müssen Sie T&M verwalten, was ebenfalls kostspielig und riskant ist.
Ein weiteres Beispiel könnte eine Strafe sein, wie sie der Entwickler möglicherweise angeboten hat und die sich als besser als Ihre beabsichtigten Verpflichtungen erweisen würde. Zu viel Kontrolle darüber, wie es gemacht wird, erstickt Innovation oder andere interessante Ideen.
Sie müssen also Alternativen analysieren und ein wirklich gutes Risikomanagement durchführen. Wenn Sie die Analyse richtig machen, richtig bewerten, sollte Ihre Antwort eintreten.