it-swarm.com.de

Wie normalisieren Sie den Codierungsstil zwischen mehreren isolierten Entwicklern?

Wir sind ein kleines/mittelständisches Unternehmen mit etwa einem Dutzend Softwareentwicklern, die unsere eigene interne Software für den internen Gebrauch entwickeln. Angesichts der Tatsache, dass es so wenige von uns gibt und nur so viel zu tun ist, verwaltet jeder Entwickler zum größten Teil einen separaten Teil des Systems und teilt seine Arbeit nicht viel mit anderen Entwicklern. Jeder hat sozusagen seine "Domain".

Gelegentlich überschneiden sich jedoch die Domänen und wir müssen zusammenarbeiten. und auch das Arrangement bedeutet, dass es schwierig ist, Leute zu ersetzen, und wenn etwas schief geht, müssen wir da sein, um Dinge zu reparieren, weil es niemand anderes tun kann (zumindest nicht schnell). Dieses Arrangement ist also sowohl Nizza (wir haben alle die volle kreative Kontrolle) als auch nicht Nizza (wir sind grundsätzlich gezwungen, rund um die Uhr auf Abruf zu sein, obwohl es in der Praxis etwas entspannter ist).

Kürzlich haben wir einen kleinen "Workshop" unter uns versucht, um einige bessere Codierungsstandards zu fördern, nämlich Unit-Tests. (Ja, wir sind einer der Leute, die das noch nicht machen ...) Während des 2-stündigen Treffens wollten wir ein kleines Beispielprogramm mit Unit-Tests erstellen, um ein Gefühl dafür zu bekommen.

Es waren lustige 2 Stunden, und wir haben es am Ende geschafft, ein bisschen Code zu produzieren, aber ein interessantes Problem wurde schmerzlich offensichtlich: Nachdem wir so lange so viel isoliert gelebt haben, hat jeder von uns im Grunde seinen eigenen Codierungsstil.

Jetzt spreche ich nicht über Tabs gegen Leerzeichen, Kamelhülle gegen Schlangenhülle oder einen solchen anderen kosmetischen Unterschied. Ich spreche über Prinzipien der Anordnung von Code. Wie man Dinge benennt. In welchen Ordnern und Namespaces sollen sie abgelegt werden? Teile ich diesen Code in drei oder nur eine Klasse auf? 5 winzige Dateien oder 1 gigantische? Mit Schnittstellen und Fabriken abstrahieren oder direkt aufrufen? Getter und Setter oder nackte Felder? Usw.

Manchmal entwickelte sich das Schreiben des absolut trivialen Programms fast zu einem schreienden Match, obwohl wir dankenswerterweise am Ende unsere Coolness bewahren konnten und keine Gefühle verletzt wurden.

Ich habe mich gefragt, wie man den Codierungsstil unter mehreren erfahrenen Entwicklern mit jeweils eigenen Vorlieben normalisiert. Die verschiedenen Stile sind lästig, wenn wir tun mit den Codes des anderen interagieren müssen, ganz zu schweigen von Verwirrung für Neulinge. Und wenn ein Teil des Codes von der Domain einer Person an die einer anderen Person übergeben wird, besteht immer der starke Wunsch, ihn so umzuschreiben, dass er Ihren eigenen Vorstellungen entspricht.

Gibt es zunächst Regeln für das Layout Ihres Codes? Irgendwelche Standards? Bisher habe ich nur das kosmetische Zeug über Räume und Fälle gesehen. Grundsätzlich, wie Sie Ihren Code formatieren, sobald er geschrieben ist (zumindest in Ihrem Kopf). Aber gibt es Anleitungen, wie Sie Ihren Code schreiben, anordnen und benennen können? Wo und wie kann man es in Teile teilen und wie lässt man die Teile interagieren?

Wenn es keinen Standard gibt und wir unseren eigenen erstellen müssen, wie gehen Sie vor, wenn jeder eine starke Meinung darüber hat, was richtig und was falsch ist? Nun wohlgemerkt, wir sind alle erfahrene Entwickler hier. Wir erkennen, dass keiner unserer Ansätze von Natur aus besser oder schlechter ist als jeder andere - nur dass jeder von ihnen bestimmte Stärken und bestimmte Schwächen hat. Wir haben aber auch eine starke Meinung darüber, welche Stärken und welche Schwächen am wichtigsten sind. Wie entscheiden Sie sich für The Right Way ™ und wie stellen Sie sicher, dass alle daran festhalten, ohne Gefühle zu verletzen (zu sehr)?

Eine Möglichkeit, von der ich gehört habe, besteht darin, einen glorreichen Anführer auszuwählen, der dann seinen bevorzugten Stil anderen aufzwingt (über Codeüberprüfungen und Besprechungen und was auch immer), aber ... Sie brauchen einen wirklich guten glorreichen Anführer, der in der Tat über anderen steht . Was ist, wenn Sie keine haben und wir hier wirklich alle gleich sind?

52
Vilx-
  1. Haben Sie einen Codierungsstandard. Wenn in dem Geschäft, für das Sie arbeiten möchten, bereits einer verwendet wird, folgen Sie diesem. Vermeiden Sie Kodierungsstandards, die Dutzende von Seiten lang sind. es ist nicht so kompliziert. Schauen Sie sich stattdessen den Code an, den Sie auf Github mögen, und folgen Sie diesem Stil. Finden Sie die etablierten Redewendungen für Ihre spezielle Programmiersprache (camelCase usw.) und verwenden Sie sie.
  2. Lassen Sie die Tools IDE und Code-Stil den größten Teil der Arbeit für Sie erledigen. Zum Beispiel verfügt Visual Studio bereits über die meisten wichtigen Regeln. Gefällt mir nicht Bitten Sie Visual Studio, den Code für Sie neu zu formatieren. Problem behoben.
  3. Stellen Sie Softwareentwickler ein, die wissen, was sie tun. Sie schreiben guten Code, ohne sklavisch einem Styleguide folgen zu müssen.
  4. Codeüberprüfungen durchführen lassen. Konsens basierend auf Funktion und Lesbarkeit suchen. Gefällt dir der Konsens nicht? Eine Person ist der Krawattenbrecher; ihre Entscheidung steht.
  5. Streben Sie nicht nach Perfektion; Sie werden es nie bekommen (aus vielen, vielen Gründen, die außerhalb des Rahmens dieser Frage liegen). Streben Sie stattdessen nach Verbesserungen.
  6. Versuchen Sie, nicht viel Zeit und Geld für Dinge zu verschwenden, die keine Rolle spielen. Schreiben Sie insbesondere keinen Code neu, der bereits funktioniert und bereits gut getestet ist, nur um Ihre eigenen Empfindungen zu befriedigen wie dieser Code aussehen sollte.
  7. Erfahren Sie, wie Sie Funktionen und Methoden schreiben, die eine Sache tun und es gut machen. Wenn Sie das tun, sollte sich Ihre Benennung von selbst erledigen (der Name ist eine kurze Verbalphrase, die beschreibt, was die Funktion tut). .
  8. Wenn Sie OO machen, lernen Sie, wie man kleine Klassen mit einer Verantwortung schreibt/Änderungspunkt. Wenn Sie das tun, sollte Ihre Benennung für sich selbst sorgen (der Name ist eine kurze Nominalphrase, die beschreibt, was die Klasse ist).
  9. Erfahren Sie, wie Sie Code schreiben, der leicht zu testen ist. Wenn Sie dies tun, kümmern sich die Unit-Tests um sich selbst.
  10. Wähle deine Schlachten aus. Ist diese kleine, dunkle Neigung, die einer der Entwickler zeigt, wirklich wichtig? Vermeiden Sie Religionen und Dogmen.
  11. Denken Sie zum Schluss daran, dass der Code gehört nicht Ihnen. Seien Sie nicht sentimental. Sie sollten es "besitzen" und nach Bedarf Änderungen vornehmen (in diesem Sinne gehört es Ihnen), aber es dient einem Zweck. Eine übermäßige Bindung an den Code verhindert dies nur, indem eine objektive Analyse der Vor- und Nachteile umfangreicher Änderungen oder Entscheidungen über die Struktur des Codes verhindert wird und Sie Einwände gegen Kompromisse erheben.
88
Robert Harvey

Der erste Schritt (und es hört sich so an, als ob Sie bereits auf dem besten Weg sind) besteht darin, von allen Entwicklern die Zustimmung zu erhalten, dass ein Problem vorliegt, das behoben werden muss. Sie alle müssen verstehen, dass sie möglicherweise einige ihrer Gewohnheiten zum Wohle der Allgemeinheit ändern müssen. Es ist nahezu sicher, dass jeder mindestens eines an der Art und Weise ändern muss, wie er Code schreibt, aber hoffentlich auch weiterhin einige Dinge so tun kann, wie er es immer getan hat. Jeder muss dies abonnieren.

Zweitens müssen Sie die Unterschiede genau identifizieren und in eine Liste eintragen. Wie Sie richtig hervorheben, ist einiges davon trivial und kosmetisch, und einiges ist viel logischer. Aber es muss in Worten festgehalten werden, damit Sie es zähmen können.

Drittens müssen Sie die niedrig hängenden Früchte finden, möglicherweise unter Verwendung eines Abstimmungssystems unter den Entwicklern. Einige Ihrer Unterschiede werden schwer zu lösen sein, da alle Entwickler eine starke Präferenz haben und es sich um eine gleichmäßige Aufteilung handelt. Einige werden jedoch eher eine 75/25-Aufteilung sein, oder sie werden gleichmäßig aufgeteilt sein, aber eine Seite fühlt sich viel stärker dabei als die andere. Diese Probleme sind leichter zu lösen. Identifizieren Sie sie und nehmen Sie sie einzeln. Teilen Sie den Entwicklern das Ergebnis der Umfrage mit und dass der gesamte neue Code dem bevorzugten Ansatz der Gruppe entspricht.

Schließlich benötigen Sie eine Möglichkeit, die Entscheidung durchzusetzen, und die Lösung hierfür ist einfach die Codeüberprüfung. ALLE Änderungen müssen von mindestens einem anderen Entwickler überprüft werden. Dies ist ein gutes Protokoll, auch wenn Sie nicht versucht haben, den Codierungsstil zu normalisieren. Prüfer sollten nach potenziellen Fehlern, unklarem Code, irreführenden Kommentaren und natürlich nach Konformität mit den Richtlinien für den Codierungsstil suchen.

Sobald eine Änderung eingelegt ist, fahren Sie mit der nächsten fort. Wenn sich die Entwickler an diesen Prozess gewöhnen, werden sie offener, wenn Sie sich den strittigeren Themen nähern.

13
Pete

Ihr erklärtes Ziel für das Meeting war es, Unit-Tests zu diskutieren, um die Codequalität unter einer Gruppe erfahrener Entwickler zu verbessern. Sie stritten sich dann über:

Wie man Dinge benennt. In welchen Ordnern und Namespaces sollen sie abgelegt werden? Teile ich diesen Code in drei oder nur eine Klasse auf? 5 winzige Dateien oder 1 gigantische? Mit Schnittstellen und Fabriken abstrahieren oder direkt aufrufen? Getter und Setter oder nackte Felder?

Keines der oben genannten Themen ist für Unit Testing von entscheidender Bedeutung, es handelt sich lediglich um einen Codierungsstil, und ich würde erwarten, dass jeder erfahrene Entwickler mit einer der oben genannten Optionen in eine Codebasis springen und ohne zu zögern stilistisch kompatiblen Code schreiben kann.

Daher würde ich einen Schritt zurücktreten, feststellen, dass Sie in eine Debatte über nichts wirklich Wichtiges geraten sind, und mich wieder mit dem Thema Testen befassen (nicht nur auf Unit-Tests beschränkt).

Betonen Sie die Wichtigkeit von Tests unter den Entwicklern und geben Sie ihnen Zeit/Raum, um diese Tests so zu schreiben, dass sie am besten zu ihrem individuellen Stil passen. Solange sie klar dokumentieren, wo/wie die Tests für ihren Code zu finden/auszuführen sind, geht es Ihnen gut.

6
Graham

Sie haben keinen anderen Codierungsstandard als den für die Plattform üblichen. Und nehmen Sie an, dass Ihre Entwickler alle Erwachsene sind.

Zwei Regeln: Wenn Sie eine Datei bearbeiten, passen Sie sie an ihren Codierungsstil an. Und neuer Code wird im Stil des Entwicklers geschrieben, der ihn schreibt.

Und sei tolerant. Kein Grund zum Schreien. Wer schreit, ist falsch.

5
gnasher729

Ich denke, Sie versuchen, das falsche Problem zu lösen. Soweit ich weiß, besteht Ihr Problem darin, dass jeder Entwickler in seinem Silo arbeitet und andere Entwickler nur dann einspringen, wenn die Probleme schwerwiegend sind. Natürlich kann in diesem Fall ein gemeinsamer (Deep Coding) Stil hilfreich sein, aber ich denke, die bessere Option ist, zuerst die Silos zu brechen. Solange Sie isoliert arbeiten, werden alle weiterhin ihre Standards codieren. Dies muss keine böswillige Absicht sein (da Sie mit dem Standard nicht einverstanden sind), es kann sich lediglich um unterschiedliche Interpretationen handeln. Wir haben unsere Codierungsstandards jahrelang mit demselben Kernteam, stoßen aber manchmal immer noch auf das Problem, dass eine Codeüberprüfung unterschiedliche Interpretationen des Codierungsstandards für verschiedene Personen aufdeckt. Das ist übrigens keine schlechte Sache, da nur Diskussionen und Meinungsverschiedenheiten die Entwicklung eines Codierungsstandards ermöglichen.

Daher empfehle ich, zuerst die Silos zu zerbrechen. Vielleicht steht ein neues Projekt an, bei dem 2-3 Entwickler dies gemeinsam erstellen können. Vielleicht können Sie mehrere Entwickler in einer Gruppe ähnlicher Projekte zusammenbringen. Lassen Sie diese Miniteams ihre Codierungsstandards in der Praxis entwickeln und überprüfen Sie die Interpretation des abstrakten Standards, indem Sie Codeüberprüfungen üben.

Der Übergang vom individuellen zum kollektiven Code-Besitz (und ein gemeinsamer Standard ist ein Element davon) geschieht nicht über Nacht und kann nicht in einer Besprechung entschieden werden. Es ist ein Ziel, das Sie durch schrittweise tägliche Verbesserungen anstreben und erreichen.

5
Manziel

Da es nicht nur um den oberflächlichen Stil geht, sondern um die Art und Weise, wie Menschen schreiben, vermute ich stark, dass Sie, wenn Sie jedem einen Weg des Winden und Denkens in Form eines "Standards" aufzwingen wird die Kreativität Ihrer Teammitglieder unterdrücken, und das könnte Ihr Team/Unternehmen töten. Was Sie tun müssen, ist daran zu arbeiten, diese schreienden Streichhölzer in etwas Produktiveres zu verwandeln. und lernen, Ihre starken Meinungen lockerer zu halten.

Führen Sie keine große Veränderung ein, Sie werden auf Widerstand stoßen. Setzen Sie sich stattdessen ein Ziel ("Wir wollen ein einheitlicheres Maß an Designfähigkeiten im gesamten Team" im Gegensatz zu "Wir wollen einen bestimmten Codierungsstil") und finden Sie heraus, was ein kleiner Schritt ist, um in diese Richtung zu gehen. Wenn Sie dann das Gefühl haben, dort angekommen zu sein, finden Sie den nächsten Schritt heraus. Ich denke, Sie können sich alle einig sein, dass Orte, an denen der Code einer Person mit dem Code einer anderen Person interagieren muss, nicht in der Verantwortung einer einzelnen Person liegen sollten, und dass der Code an diesen Schnittstellen erfordert, dass die beteiligten Parteien beim Design vorsichtiger vorgehen und dies tun Verbringen Sie einige Zeit, um das Problem der Interaktion besser zu verstehen. Also fang dort an; Führen Sie die Vorstellung ein, dass der Code an den Grenzen nicht von einer einzelnen Person entschieden wird oder sogar einer einzelnen Person gehört. Lassen Sie sie die Abhängigkeiten und die "Macht" -Beziehungen zwischen den Systemen/Komponenten explizit untersuchen und vereinbaren.

Eine andere Sache, die Sie tun können, ist, sie dazu zu bringen, irgendeine Form der Paarprogrammierung in ihre Routine aufzunehmen (während eines Teils der Arbeitszeit, möglicherweise mit einem Rotationsschema), auf eine Weise, die nicht zu störend ist (Sie müssen es herausfinden Was bedeutet das in Bezug auf die Art und Weise, wie Sie jetzt arbeiten? Auf diese Weise können sie Fähigkeiten voneinander abholen und untereinander "kämpfen", wenn es darum geht, wie der Code gestaltet wird. Denn anders als bei einem hitzigen Streit in einem Meeting werden sie echte Probleme lösen und so in der Lage sein, die Ideen des anderen herauszufordern und sie im Kontext zu bewerten und auszuprobieren. Dies würde auch bei Ihrem Problem helfen, bei dem niemand wirklich den Code eines anderen versteht als seinen eigenen.

P.S. Da Sie gerade erst mit TDD anfangen, würde ich das auch dem Team nicht aufzwingen. Stattdessen würde ich einen Weg für sie finden, es in einem Nebenprojekt zu üben und es dann langsam in ihre tägliche Arbeit zu integrieren, da TDD, IMO, ein gewisses Maß an Übung und ein gewisses Maß an (Testschreiben und Design) erfordert ) Geschicklichkeit, bevor es effektiv eingesetzt werden kann. Andernfalls könnten sie am Ende eine Testsuite schreiben, die ihr Leben nicht einfacher macht, sodass sie sie irgendwann ignorieren und/oder eine Feindseligkeit gegenüber der Praxis entwickeln. Sie können auch einen guten Berater hinzuziehen, mehr Workshops durchführen usw.

4

Wenn die Teamkultur gut funktioniert hat und jeder Entwickler seine eigene Domäne und seinen eigenen Stil hat und die Leute mit der Situation zufrieden sind, versuchen Sie nicht, dies zu ändern. Wenn diese Isolation kein Problem darstellt, machen Sie sie nicht zum Problem.

Stellen Sie sicher, dass die Einhaltung lokaler Standards die allgemeine Regel ist. Der Leiter für jede Domain sollte entscheiden, welche Standards für ihre Domain gelten. Wenn Personen außerhalb ihrer Domäne arbeiten, sollten sie den Codierungsstil des lokalen Domänenleiters respektieren.

Dies bedeutet nicht, dass Sie keinen Codierungsstandard haben sollten. Einige Codierungsstandards werden ziemlich einfach sein und weit verbreitete Vereinbarungen haben, also standardisieren Sie diese. Aber für die strittigeren versuchen Sie nicht, die Meinungen aller zu vereinheitlichen.

3
Lie Ryan

Angesichts der Tatsache, dass es so wenige von uns gibt und nur so viel zu tun ist, verwaltet jeder Entwickler zum größten Teil einen separaten Teil des Systems und teilt seine Arbeit nicht viel mit anderen Entwicklern. Jeder hat sozusagen seine "Domain".

Dies ist eher ein Problem als es scheint. Nur einen Entwickler in einem Projekt zu haben, fördert diese Art von Überprotektion und birgt andere Risiken des "Busfaktors" - wenn die einzige Person, die ein Subsystem kennt, von einem Bus angefahren wird oder auf andere Weise plötzlich außer Gefecht gesetzt wird oder das Unternehmen verlässt.

Um sich als Team zu verhalten, müssen sie als Team arbeiten, was eine gleichmäßigere Verteilung der Arbeit bedeutet. Dies ist überhaupt nicht einfach und erfordert einen kontinuierlichen Management-Input, lohnt sich aber auf lange Sicht.

Während sie dies tun und die Arbeit des anderen überprüfen, werden sie am Ende die Details diskutieren - aber paarweise und nicht in einer großen Gruppe. Das sollte einen Konsens fördern. Es sei denn, es gibt eine "unvernünftigste" Person, die versucht, ihren Willen durchzusetzen.

3
pjc50

Es ist nicht klar warum der Codierungsstil ist für Sie wichtig. Liegt es daran, dass es zu Meinungsverschiedenheiten kam, wodurch Zeit verschwendet und Reibung erzeugt wurde, oder liegt es daran, dass es Probleme beim Ausführen der Software verursacht, oder liegt es daran, dass es schwierig ist, die Software zu schreiben/zu warten?

Das erste, was Sie tun müssen, ist, das warum oder das was und das wie herauszufinden, das Ihnen wahrscheinlich entgehen wird (obwohl alle anderen Antworten Hier haben Sie gute Ideen zu Dingen, die Sie tun sollten.

Was ich in dieser Situation wahrscheinlich tun würde, ist:

  • schreibe an Schnittstellen
  • schreiben Sie Integrationstests, die bestätigen, dass die Software bei Verwendung dieser Schnittstellen funktioniert
  • dokumentiere meine Arbeit gründlich
  • mach das alles nur für meine Arbeit

Bis Sie Macht durch Konsens oder Macht durch Autorität wie die eines Managers erhalten, können Sie Dinge nur anhand eines Beispiels tun. Jeder, der Ihre Arbeit berührt, muss nun die von Ihnen angegebenen Spezifikationen verwenden, was zu weniger Fehlern in Ihrer Arbeit führt und somit seinen eigenen Sinn beweist. Auf diese Weise erhalten Sie Autorität (der beste Weg).

Wenn es die Schnittstellen bei den erwarteten Eingaben richtig ausspuckt, warum interessiert es Sie dann, wenn der Code 3 oder 5 Klassen hat? Weil du ihre Sachen nicht lesen kannst oder es dir nicht gefällt? Sie brauchen bessere Gründe, um einen Stil durchzusetzen, als Sie haben.

Wenn Sie keine Spezifikationen/Tests haben, spielt es keine Rolle, ob Sie einem Affen eine Schreibmaschine zum Codieren gegeben haben und dessen Stil Ihnen nicht gefällt. Sie haben größere Probleme.

1
Iain

Roberts Antwort ist großartig, aber es gibt noch ein bisschen mehr über die Auswirkungen Ihrer technischen Entwürfe auf die Teamarbeit zu sagen.

unit-Tests. (Ja, wir sind einer der Leute, die das noch nicht machen ...)

Unit-Tests sind nicht erforderlich, wenn Sie OO nicht verwenden. Wenn Sie OO verwenden, testen Sie help, um Sie zu warnen, wenn Ihr Code beschädigt wird. Die Tests unterliegen jedoch denselben Regeln wie jeder andere Code und können auf dieselbe Weise wie regulärer Code unerwartet unterbrochen werden.

Wenn Sie anstelle von OO einen funktionaleren Stil verwenden, gibt es keine Unit-Tests mehr. Wenn sie vorhanden wären, würden sie genau so aussehen, als würden Sie Ihren Code kopieren. An diesem Punkt tun Sie dies einfach nicht, sodass Sie Ihren Code klein und lesbar halten können. Ein Beispiel finden Sie weiter unten.

Teile ich diesen Code in 3 Klassen oder nur in eine auf? 5 winzige Dateien oder 1 gigantische? Mit Schnittstellen und Fabriken abstrahieren oder direkt aufrufen? Getter und Setter oder nackte Felder?

Möglicherweise befinden Sie sich in Streitigkeiten darüber, aber Sie müssen eine richtige Antwort finden. Schnittstellen, Abstraktionen, Fabriken, Klassen, Getter und Setter sind willkürliche Konzepte, die sich gut anhören. Zu verstehen, wie sie funktionieren und wie sie in Ihre Software passen, ist jedoch ein Entwickleraufwand. Der Overhead macht Entwickler Lust, neue Lösungen zu finden, damit sie nicht so lange Rätsel lösen müssen. Da diese Konzepte keine messbaren Vorteile haben, können Sie sie vollständig überspringen, um das Lesen und Bearbeiten Ihres Codes zu vereinfachen.

Es kann schwierig sein, aus diesen Argumenten herauszukommen. Hören Sie gut zu, stellen Sie die richtigen Fragen, machen Sie Ihre Fragen kurz, präzise und auf den Punkt und stechen Sie frühzeitig Löcher in Designs. Wenn jemand vorschlägt, ein Factory-Muster zu verwenden, möchten Sie möglicherweise mit einem Beispiel kontern, das weniger Codezeilen verwendet. Wenn sie etwas Unbeweisbares sagen, wie "weniger Code ist nicht immer besser" oder "es entspricht nicht den Standards", sollten Sie sie bitten, dies zu erklären, damit sie über ihre Idee nachdenken, den Fehler zu finden. Wenn sie versagen, werden sie verwirrt und frustriert. Lassen Sie die Auswahl gleiten, arbeiten Sie damit und versuchen Sie es ein anderes Mal. Jedes Mal, wenn Sie fragen, können sie besser nach innen schauen.

Wenn Sie den Entwickler nicht dazu bringen können, mehrmals nach innen zu schauen, und er sich nicht zu verbessern scheint, haben Sie einen Problementwickler. Wenn Ihr gesamtes Team genauso ist, ist es unwahrscheinlich, dass Sie die Situation verbessern können. Akzeptieren Sie die Argumente oder finden Sie eine andere Arbeit.

Sie kommentiert auf Roberts Antwort

wir haben zu viel Erfahrung und jeder hat seine eigene Meinung daraus

Aufgrund Ihrer Beschreibungen glaube ich nicht, dass Sie zu viel Erfahrung erreicht haben. Wenn Sie diese Ebene erreichen, erhalten Sie einen Konsens mit anderen Entwicklern auf derselben Ebene, nicht mit unterschiedlichen Meinungen. Die Antwort steht und nehmen Sie nicht an, dass Sie darüber stehen - finden Sie jemanden, der zeigen kann, dass er weiß, was er tut, und lassen Sie sich von ihm in die richtige Richtung führen.


Bei Unit-Tests für Funktionsstile

Dies ist für die ursprüngliche Frage nicht sehr relevant und etwas lang. Überspringen Sie dies, es sei denn, Sie sind interessiert. Ich wurde gebeten, es zu erklären, also ..

Ein funktionierender Server würde folgendermaßen aussehen:

//main
http.Listen((request,response)=>{
    response.write(request.username);
});

Und ein Test könnte so aussehen:

//test that it returns the right value
var username="billy";
http.request({username:username}, response=>{
    if(response!==username){
        console.error("test failed");
        return -1;
    }
});

Aber sobald mein Basisserver etwas anderes tun muss, würde ich den Test abbrechen. Refactoring ist notwendig, aber jetzt muss ich es an zwei Stellen tun.

Der Test schlug genauso fehl wie die Software! Wenn der Benutzername nicht definiert ist, versuchen wir, einen undefinierten Wert zu lesen, und es wird ein Fehler ausgegeben. Auch dafür können wir einen Test schreiben, der rot-grün ist:

//red: write the test first which will find undefined values
http.request({}, (response,error)=>{
    if(response){
        console.error("got a valid response, test failed");
        return -1;
    }
    if(error){
        return 0;
    }
});

und dann den Code für das Grün korrigieren:

    //main
    http.Listen((request,response, error)=>{
        if(!request.username) error.write("no username");
        else response.write(request.username);
    });

Aber wieder das gleiche Problem. Ich habe meinen Code nur zweimal geschrieben, die Umgestaltung erschwert, mehr Zeilen zum Lesen hinzugefügt, und das Testen hat nichts Nützliches gebracht.

Wann ist das Testen sinnvoll? In OO. Das Testen ist selbst ein funktionaler Stil, bei dem die Funktion den Programmfluss stabil halten und Entwickler dabei unterstützen soll, kleineren, saubereren Code zu schreiben.

class server{
    listen(IPerson request,string response){
        response.write(request.username);
    };
} 
interface IPerson{
    string username;
}
class Person{
    string username;
}
class TestPerson inherits IPerson{
    string username{
        get{usernameCheckedCount++; return _username;} 
        set{_username=value;}
    };
    string _username;
    int numTimesUsernameWasChecked=0;   
}
static int TestServer(){
    //setup
    var didTestFail=0;
    var srv=new server();
    var invalidPerson=new TestPerson{username=null};
    var validPerson=new TestPerson{username="billy"};

    //test that an invalid person throws an error
    srv.listen(invalidPerson,(string response, string error)=>{
        if(error==null) didTestFail=1;
    });
    //test that a valid person throws no error, the server checks the username, and the response is the username
    srv.listen(validPerson,(string response, string error)=>{
        if(error != null) didTestFail= 1;
        if(validPerson.numTimesUsernameWasChecked == 0) didTestFail=1;
        if(response != "billy") didTestFail=1;
    });

    //return
    return error;
}

Wenn ich dies nicht zu Testzwecken geschrieben hätte, hätte ich möglicherweise zunächst einen Dienst, zwei Schnittstellen und eine andere Abhängigkeitsinjektionsdatei erstellt, bevor ich mit der Arbeit selbst begonnen habe, was die Arbeit sicherlich erheblich erschweren wird. Es ist wirklich schwer, alles im Auge zu behalten!

0
Willtheoct

Zusätzlich zu den hier vorgeschlagenen Vorschlägen empfehle ich dringend, die Bildschirmfreigabe zu verwenden, um einige Paarprogrammierungssitzungen durchzuführen, damit Entwickler zusammenarbeiten können. NICHT jeden Tag den ganzen Tag, nur ein paar Stunden pro Woche, um als Paar zu arbeiten und zu verwechseln, wer mit wem zusammenarbeitet, wird sich im Hinblick auf die Normalisierung der Praktiken enorm auszahlen und Tipps miteinander teilen.

0

Soweit ich Ihre Frage verstanden habe, ist die reine Tatsache, dass Menschen unterschiedliche Codierungsstile und Designpräferenzen haben, kein Problem. Ein Problem tritt nur dann auf, wenn

die Domänen überschneiden sich und wir müssen zusammenarbeiten

und diese Stile und Vorlieben kollidieren miteinander. Jetzt ist Ihr Plan, dieses Problem zu lösen, indem Sie den Codierungsstil "normalisieren".

Normalisieren ist für mich in diesem Zusammenhang ein ziemlich seltsames Wort. Wie wäre ein Codierungsstil normaler als jeder andere? Wie sind die aktuellen Codierungsstile nicht normal? Was macht einen normalen Codierungsstil aus? Vielleicht liegt das daran, dass ich kein englischer Muttersprachler bin, aber Ihre Wortwahl könnte bereits ein Hinweis darauf sein, dass Sie hier ein wenig in die falsche Richtung steuern.

Menschen entwickeln normalerweise einen Codierungsstil, der ihnen hilft, besseren Code zu schreiben. Da alle Menschen unterschiedlich sind, manchmal mehr, manchmal weniger, sind auch ihre Codierungsstile unterschiedlich. Natürlich können Sie einen gemeinsamen Codierungsstil erstellen und alle dazu zwingen, ihn zu verwenden, aber das ist ein bisschen so, als würden Sie alle Leute dazu zwingen, dieselbe Hand zum Schreiben zu verwenden, auch wenn einige von ihnen Rechtshänder sind, während andere Linkshänder sind. Handler.

Ein gängiger Codierungsstil ist normalerweise ein Kompromiss und passt zu niemandem, der so gut ist wie der eigene. Einige Leute werden weniger Probleme damit haben, da der Stil ihren Vorlieben nahe kommt, während es für andere ein echtes Problem sein wird. Was ich hier im Grunde zu sagen versuche: Wenn Sie reifen Entwicklern einen Codierungsstil aufzwingen, werden sie im Allgemeinen schlechteren Code produzieren, manchmal nur ein bisschen schlechter, manchmal viel schlechter, abhängig von Ihrer Wahl des Stils. Und ich bin mir nicht sicher, ob die Verbesserungen in den überlappenden Bereichen den Verlust in allen anderen Bereichen kompensieren werden.

Was ich in Ihrer Frage gelesen habe, ist, dass die Tatsache, dass jeder einen eigenen Codestil hat, bisher noch nie ein ernstes Problem war. Ich weiß nicht, ob es klug ist, es zu einem ernsthaften Problem zu machen, indem man einen gemeinsamen Codestil für alle erzwingt und die ganze Zeit sehen Sie, was ich meine?

Bei der Zusammenarbeit fiel mir sofort ein gutes altes Designmuster ein:
Programm für Schnittstellen, keine Implementierungen!

Für die Zusammenarbeit müssen gemeinsame Schnittstellen vereinbart werden. Es ist nicht erforderlich, sich auf gemeinsame Implementierungen hinter diesen Schnittstellen zu einigen. Also hier ist mein Vorschlag:

Lassen Sie jedem seinen bevorzugten Codierungsstil, aber stellen Sie beim Entwerfen von Schnittstellen für die Abschnitte, in denen sich Domänen überschneiden (oder in Zukunft möglicherweise überschneiden), sicher, dass keine einzelne Person sie allein entwirft. Entwerfen Sie sie entweder in einer Teambesprechung oder legen Sie eine Regel fest, nach der mindestens drei oder vier Personen an jeder Schnittstelle zusammenarbeiten müssen. Auf diese Weise erhalten Sie viel bessere Schnittstellen und bessere Schnittstellen führen automatisch zu besserem Code. Sie beantworten auch Fragen wie das Aufteilen Ihrer Probleme in Teile oder das Benennen von Elementen und vor allem, wie Teile miteinander interagieren.

Und denken Sie daran: Eine gute Benutzeroberfläche kann sehr lange überleben, da Sie die dahinter stehende Implementierung jederzeit ersetzen können, ohne anderen Code berühren zu müssen. Aus diesem Grund sind Schnittstellen wichtiger als Implementierungen, da sie Schnittstellen ersetzen, was wirklich harte Arbeit ist. Egal wie gut Sie sind, Sie werden Fehler machen, wenn Sie Schnittstellen selbst entwerfen. Sie werden Probleme übersehen, Sie werden fehlende Details übersehen und ein paar zusätzliche Augen neben sich zu haben, wird wirklich hilfreich sein.

Mein Vorschlag folgt im Wesentlichen einer anderen alten Entwicklerweisheit:
Berühren Sie niemals ein laufendes System. Zumindest nicht, es sei denn, Sie müssen. Wenn Sie jedem einen Codierungsstil aufzwingen, wird Ihr System von Grund auf neu gestaltet, obwohl es bisher sehr gut funktioniert zu haben scheint, nicht wahr? Reparieren Sie nicht den Teil des Systems, der nicht kaputt ist. Konzentrieren Sie sich nur auf das eigentliche Problem, und das sind die Bereiche, in denen sich Domänen überschneiden.

0
Mecki