Sollte ich einen schlechten Codierungsstil verwenden, um die an meinem Arbeitsplatz geltenden Konventionen einzuhalten?

102

Ich arbeite seit ungefähr einem Jahr an meinem Arbeitsplatz. Ich arbeite hauptsächlich in unserer GUI-Oberfläche, die Methoden aus einem C-Backend verwendet, aber ich muss mich im Allgemeinen nicht mit ihnen befassen, außer mit Rückgabewerten. Unsere Benutzeroberfläche ist angesichts unserer Einschränkungen ziemlich vernünftig strukturiert.

Ich wurde beauftragt, dem Befehlszeilenteil des Programms eine Funktion hinzuzufügen. Die meisten dieser Funktionen haben eine Länge von 300 Zeilen und sind schwierig zu bedienen. Ich versuche, Teile davon zu sammeln, um bestimmte Alarminformationen zu erhalten, und ich habe Probleme, mich zu organisieren. Ich weiß, dass ich meine Tests komplizierter mache, indem ich sie in einer einzigen langen Funktion durchführe.

Sollte ich einfach alles in einer riesigen Funktion gemäß dem Stil der vorhandenen Funktionen halten oder sollte ich die Alarme in ihren eigenen Funktionen einkapseln?

Ich bin mir nicht sicher, ob es angemessen ist, gegen die aktuellen Kodierungskonventionen zu verstoßen oder ob ich einfach in die Kugel beißen und den Code für mich selbst etwas verwirrender machen sollte.

Zusammenfassend vergleiche ich

showAlarms(){
    // tons of code
}

gegen

showAlarms(){
   alarm1();
   alarm2();
   return;
}

alarm1(){
    ...
    printf(...);
    return;
}

BEARBEITEN: Vielen Dank für den Rat an alle, ich habe beschlossen, meinen Code faktorisiert zu gestalten und dann zu fragen, was sie wollen. Wenn sie alles in einem wollen, kann ich einfach meinen faktorisierten Code ausschneiden und ihn wieder in 1 umwandeln große Funktion. Dies sollte es mir ermöglichen, es zu schreiben und einfacher zu testen, selbst wenn sie den gesamten Code in einer einzigen Definition haben möchten.

UPDATE: Am Ende waren sie mit dem faktorisierten Code zufrieden und mehr als eine Person hat mir dafür gedankt, dass ich diesen Präzedenzfall geschaffen habe.

Justin
quelle
117
Es ist höchst zweifelhaft, dass die Firma, für die Sie arbeiten, die Position einnimmt, dass Ihre Funktionen 300 Zeilen lang sein sollten, weil "das ist die Art und Weise, wie wir es immer gemacht haben." Das sind keine "Codierungsstil-Konventionen". Es ist einfach ein schlechter Stil.
Robert Harvey
64
Dies ist die Art von Sache, die Sie mit anderen Mitgliedern Ihres Teams besprechen sollten, um herauszufinden, welche Praktiken Sie als Konventionen ansehen, die für alle wichtig sind, und welche Dinge jemand gerade einmal getan hat und welche nicht emulieren müssen. Es wird zweifellos eine gewisse Menge von beidem geben.
Servy
17
@beginnerBinx Das hängt nur davon ab, wie Sie es ausdrücken. Formulieren Sie es nicht so: "X macht etwas wirklich Dummes, muss ich auch das Dumme tun?" aber eher als etwas wie: "Ich merke, dass X diese eine Sache tut, gibt es einen bestimmten Grund, warum es so tut, wie es tut; wäre es ein Problem, wenn ich beim Schreiben von Y nicht dasselbe täte?" Dann entscheiden sie, ob sie den alten Code verprügeln oder erklären, warum sie es auf diese Weise tun mussten (ob es widerwillig oder enthusiastisch ist).
Servy
11
Über guten oder schlechten Stil wird häufig gestritten und selten abgestimmt. Die universitäre Lehre besagt, dass Funktionen kurz sein sollten, aber wenn dies die Bedeutung verdeckt, tun Sie es nicht. Der Test sollte klar sein und nicht unüberlegt einem Regelwerk folgen.
quick_now
9
Zufällige Leute im Internet haben nichts dagegen, Ihre Teamkollegen zu lesen. Alle Antworten, die Sie hier erhalten, sind nur die persönlichen Vorlieben der Leute. Sie sollten mit Ihrem Team sprechen. Ist die Langfunktion ein bewusstes Gestaltungsprinzip? Möchten sie, dass Sie den Stil einer langen Funktion beibehalten, oder möchten sie, dass Sie das schreiben, was Sie für das sauberste halten?
JacquesB

Antworten:

102

Dies ist wirklich zwischen Ihnen und Ihren Teamkollegen. Niemand sonst kann dir die richtige Antwort geben. Wenn ich es jedoch wage, zwischen den Zeilen zu lesen, liefert die Tatsache, dass Sie diesen Stil als "schlecht" bezeichnen, einige Informationen, die darauf hindeuten, dass es besser ist, langsam zu fahren. Sehr wenige Codierungsstile sind tatsächlich "schlecht". Es gibt solche, die ich selbst nicht verwenden würde, aber sie haben immer einen Reim oder Grund dafür. Dies legt für mich nahe, dass die Geschichte mehr enthält, als Sie bisher gesehen haben. Herumzufragen wäre ein sehr weiser Anruf. Jemand weiß vielleicht etwas, was Sie nicht wissen.

Ich bin persönlich darauf gestoßen, als ich zum ersten Mal in die missionskritische Echtzeit-Codierung vordrang. Ich habe folgenden Code gesehen:

lockMutex(&mutex);
int rval;
if (...)
{
    ...
    rval = foo();
}
else
{
    ...
    rval = bar();
}
unlockMutex(&mutex);
return rval;

Als der helle und glänzende OO C ++ - Entwickler, den ich war, machte ich sie sofort auf die Fehlerrisiken aufmerksam, die sie hatten, indem ich Mutexe manuell sperrte und entsperrte, anstatt RAII zu verwenden . Ich bestand darauf, dass dies besser war:

MutexLocker lock(mutex);
if (...)
{
    ...
    return foo();
}
else
{
    ...
    return bar();
}

Viel einfacher und sicherer, oder ?! Warum müssen Entwickler daran denken, ihre Mutexe auf allen Kontrollflusspfaden freizuschalten, wenn der Compiler dies für Sie tun kann?

Was ich später herausfand, war, dass es einen prozeduralen Grund dafür gab. Wir mussten bestätigen, dass die Software tatsächlich korrekt funktionierte, und es gab eine endliche Liste von Tools, die wir verwenden durften. Mein Ansatz mag in einer anderen Umgebung besser gewesen sein, aber in der Umgebung, in der ich gearbeitet habe, würde mein Ansatz den Aufwand für die Verifizierung des Algorithmus leicht verzehnfachen, da ich gerade ein C ++ - Konzept von RAII in einen Codeabschnitt gebracht habe das wurde nach Maßstäben gehalten, die für das Denken im C-Stil wirklich zugänglicher waren.

Also, was für mich wie ein schlechter, geradezu gefährlicher Codierungsstil aussah, war eigentlich gut durchdacht und meine "gute" Lösung war tatsächlich die gefährliche, die später Probleme verursachen würde.

Also fragt herum. Es gibt sicherlich einen erfahrenen Entwickler, der mit Ihnen zusammenarbeiten kann, um zu verstehen, warum er das so macht. Oder es gibt einen erfahrenen Entwickler, der Ihnen helfen kann, die Kosten und den Nutzen eines Refactors in diesem Teil des Codes zu verstehen. Fragen Sie in jedem Fall nach!

Cort Ammon
quelle
60
Der wohl gefährlichere Teil des Mutex-Beispiels ist das offensichtliche Fehlen von Code-Kommentaren, die erklären, warum es RAII nicht verwenden konnte. Zugegeben, wenn sich dieses explizite Sperren / Entsperren auf der gesamten Codebasis befindet, kann es unhandlich sein, für jede Instanz einen Kommentar hinzuzufügen. In diesem Fall sollte möglicherweise ein Grundlagendokument geschrieben werden, mit dem neue Entwickler vertraut sein müssen.
Kelvin
10
Sicher ist es immer gut, mit einem Senior zu sprechen, und das Refactoring muss mit Sorgfalt (und mit Tests) durchgeführt werden. Und natürlich sind Nebenläufigkeiten / Mutexe ein besonderes Tier für sich. Aber wenn ich Funktionen mit> 300 Zeilen sehe, würde ich nicht zu viel Zeit in die Suche nach einem "versteckten technischen Grund" investieren, warum diese Funktionen zu groß sind. Der Grund, warum Funktionen zu lang werden, ist immer der gleiche und sie sind nicht technisch.
Doc Brown
8
@DocBrown Nur weil sie nicht technisch sind, heißt das nicht, dass sie keine Gründe sind. Für Entwickler ist es wichtig, sich daran zu erinnern, dass sie Teil einer größeren Maschine sind. (Ich kann nicht zählen, wie oft ich diese Lektion neu gelernt habe)
Cort Ammon
4
@ DocBrown So oder so, es sind die Senior-Entwickler, mit denen man sprechen sollte. Ich habe das Beispiel gewählt, weil es einfach ist, unzählige Argumente dafür zu finden, warum dummer Code dumm ist. Es ist schwieriger, die Argumente dafür zu finden, warum Code, der dumm aussieht, eigentlich nicht dumm ist.
Cort Ammon
3
@DocBrown Aus Ihren Kommentaren und Antworten kann ich schließen, dass der Unterschied zwischen unseren Meinungen darin besteht, dass Sie von der Annahme ausgehen, dass der Code bereits "schlecht" ist, basierend auf den Beweisen, die Sie erhalten haben Nehmen Sie zuerst Pfade, die untersuchen, ob der Code "schlecht" ist oder nicht.
Cort Ammon
84

Glauben Sie wirklich, dass es nur eine Frage des Stils ist, Funktionen zu haben, die mit 300 Zeilen schwierig zu bedienen sind? Wenn Sie also dem schlechten Beispiel folgen, könnte das Gesamtprogramm aus Gründen der Konsistenz in einem besseren Zustand bleiben? Ich vermute, Sie glauben es nicht, sonst hätten Sie diese Frage hier nicht gestellt.

Ich vermute, dass diese Funktionen so lang sind, weil es in unserem Geschäft viele mittelmäßige Programmierer gibt, die nur Features über Features stapeln, ohne auf Lesbarkeit, Codequalität, korrekte Benennung, Komponententests und Refactoring zu achten, und sie haben nie gelernt, richtige Abstraktionen zu erstellen . Sie müssen selbst entscheiden, ob Sie dieser Herde folgen oder ein besserer Programmierer sein möchten.

Nachtrag, aufgrund der Kommentare: "300 Zeilen" und "schwer zu bedienen" sind meiner Meinung nach starke Anzeichen für schlechten Code. Nach meiner Erfahrung ist es sehr unwahrscheinlich, dass es einen "versteckten technischen Grund" gibt, warum ein solcher Code nicht besser lesbar implementiert werden kann, vergleichbar mit dem Beispiel von Cort Ammons Antwort. Ich stimme jedoch Cort zu, dass Sie dies mit den Verantwortlichen im Team besprechen sollten - nicht um obskure Gründe zu finden, warum der Code oder diese Art von Stil nicht geändert werden kann, sondern um herauszufinden, wie der Code sicher überarbeitet werden kann, ohne Dinge zu beschädigen .

Doc Brown
quelle
127
Selbst kompetente Programmierer begehen diese Verbrechen, wenn die Fristen knapp sind.
Gardenhead
13
@gardenhead, ich kann verstehen, eine 300-Zeilen-Funktion nicht umzugestalten, um Zeit zu sparen, aber es gibt keine Möglichkeit, wie Sie durch das Schreiben einer 300-Zeilen-Funktion Zeit sparen können.
Dangph
39
@gardenhead: Wenn ich zu einem Chirurgen gehe, weil ich dringend Hilfe benötige, erwarte ich immer noch, dass er sich die Zeit nimmt, um sich die Hände zu waschen, bevor er anfängt, an mir zu arbeiten. Dies ist etwas, das viele Menschen in unserem Geschäft lernen müssen, um echte Kompetenz zu erlangen : Lassen Sie den Code immer in einem besseren Zustand als zuvor zurück, und dies verbessert auch die Fähigkeit, Termine einzuhalten. 300 Leitungsfunktionen werden in der Regel von Tag zu Tag größer, von Menschen, die sich nicht darum kümmern, und sie werden immer "die Frist" als Ausrede verwenden.
Doc Brown
17
@Dangph Es spart Zeit, wenn Sie der Funktion nur 5 Zeilen hinzufügen, anstatt sie umzugestalten. Diese werden normalerweise größer, wenn die anfängliche Funktion lang ist (über 30 Zeilen) und der nächste Programmierer denkt, "das ist nicht mein Code, ich werde nicht umgestalten, es nicht zu brechen, füge nur hier und da ein paar Zeilen hinzu".
Džuris
7
@Juris, so wie ich es verstehe, geht es um die Erstellung einer neuen Funktion, nicht um die Umgestaltung bestehender Funktionen. Wenn Sie eine neue Funktion schreiben, sparen Sie keine Zeit, indem Sie sie zu einer einzigen Monsterfunktion machen.
Dangph
42

Nein.

In dem Buch Pragmatic Programmer spricht der Autor über die Broken Window Theory .

Diese Theorie besagt:

Stellen Sie sich ein Gebäude mit einigen zerbrochenen Fenstern vor. Wenn die Fenster nicht repariert werden, besteht die Tendenz, dass Vandalen ein paar weitere Fenster zerbrechen. Möglicherweise brechen sie sogar in das Gebäude ein, und wenn es nicht besetzt ist, können sie zu Hausbesetzern oder Feuer im Inneren werden.

Oder betrachten Sie einen Bürgersteig. Es fällt etwas Müll an. Bald sammelt sich mehr Müll an. Irgendwann lassen die Leute sogar Müllsäcke in Restaurants zum Mitnehmen oder brechen sogar in Autos ein.

In dem Buch schreibt der Autor eine Parallele zwischen dieser Theorie und dem Code. Sobald Sie einen Code wie diesen gefunden haben, hören Sie auf und stellen sich die gleiche Frage.

Und die Antwort lautet: Nein.

Sobald Sie dieses zerbrochene Fenster verlassen - in unserem Fall ein fehlerhafter Code - wird dies den Effekt hervorrufen, dass jeder zerbrochene Fenster zurücklässt.

Und eines Tages wird der Code zusammenbrechen.

Geben Sie allen eine Kopie von Clean Code und Clean Coder .

Und während Sie im Fach sind, ist eine Kopie von TDD auch eine gute.

linuxunil
quelle
6
Was ist, wenn die Codebasis ein Gewächshaus mit nur zerbrochenen Fenstern ist?
Alan Shutko
8
@AlanShutko Dann stellen Sie sicher, dass Ihr Lebenslauf aktuell ist? Finden Sie jetzt einen anderen Arbeitgeber .
David Montgomery
12
Code "kollabiert" selten. Das Hinzufügen neuer Funktionen wird immer schwieriger, nimmt immer mehr Zeit in Anspruch, und die Schätzungen für die Bereinigung des Codes nehmen zu - was bedeutet, dass es noch schwieriger wird, ein Zeitbudget für die erforderliche Bereinigung zu erhalten.
Doc Brown
8
Wow, was für eine willkürliche Analogie scheint die "broken window" Theorie zu sein.
Samthere
4
TDD hat damit nichts zu tun. Ganz gleich, ob Sie sich für das Design von Business- / Domain- / Test- / Nothingness-Treibern entscheiden, an denen sich nichts ändert. Befolgen Sie die Grundlagen für sauberen Code. Tut mir leid, aber es ist wirklich anstrengend zu sehen, dass 'TDD' überall zitiert wird, wo es nicht einmal im Betreff ist
Walfrat
25

Ja, mach es. Struktur! = Stil

Sie sprechen von Struktur, nicht von Stil. Stilrichtlinien schreiben (normalerweise) keine Struktur vor, da die Struktur im Allgemeinen aufgrund ihrer Angemessenheit für ein bestimmtes Problem und nicht aufgrund ihrer Angemessenheit für eine Organisation ausgewählt wird.

Achtung

Seien Sie einfach verdammt sicher, dass Sie keine negativen Konsequenzen in anderen Bereichen haben, die Ihnen möglicherweise nicht in den Sinn gekommen sind. Zum Beispiel,

  • Stellen Sie sicher, dass Sie keine Unterschiede oder Codezusammenführungen komplizieren, da Sie Ähnlichkeiten mit vorhandenem Code ausgelöscht haben.
  • Stellen Sie sicher, dass Ausnahmeflüsse korrekt in die Luft sprudeln und Stapelspuren nicht mit einem großen Haufen unleserlichen Blödsinns verunreinigt sind.
  • Stellen Sie sicher, dass Sie nicht versehentlich öffentliche Einstiegspunkte anzeigen, die bei einem direkten Aufruf Probleme verursachen würden (nicht in die Karte einfügen und / oder nicht exportieren).
  • Überladen Sie den globalen Namespace nicht, z. B. wenn für alle kleineren Funktionen ein globaler Kontext erforderlich ist, der zuvor im funktionslokalen Bereich deklariert wurde.
  • Sehen Sie sich unbedingt alle Protokolle an und fragen Sie sich, ob Sie im Support-Team wären, wenn die von Ihrem Code generierten Protokolle verwirrend wären, wenn sie mit den Protokollen von jedem Code, den Sie nicht berühren, verflochten wären.
  • Stellen Sie sicher , Sie zu bestehendem Stil halten, zum Beispiel , auch wenn sie die alten Schule verwenden ungarische Notation und es macht Ihre Augen bluten, bleiben im Einklang mit der allgemeinen Code - Basis. Das einzige, was schmerzhafter ist als das Lesen der ungarischen Notation, ist das Lesen von Code, der ein Dutzend verschiedener Notationstypen verwendet, je nachdem, wer was geschrieben hat.

Sei sanft

Denken Sie daran, dass Sie Teil eines Teams sind, und obwohl guter Code wichtig ist, ist es auch sehr wichtig, dass Ihre Teammitglieder in der Lage sind, die Dinge, die Sie geschrieben haben, zu pflegen, wenn Sie in den Urlaub fahren. Versuchen Sie, sich an einen Fluss zu halten, der für Menschen, die an den alten Stil gewöhnt sind, sinnvoll ist. Nur weil du der klügste Typ im Raum bist, heißt das nicht, dass du über alle Köpfe hinweg reden solltest!

John Wu
quelle
"Versuchen Sie, sich an einen Fluss zu halten, der für Menschen, die an den alten Stil gewöhnt sind, sinnvoll ist." - Also, ist es Ihr Rat, auf die gleiche Art und Weise zu programmieren, wie es ein inkompetenter Clown zuvor getan hat? Das Hinzufügen der 300-Zeilen-Funktion wird es nicht einfach machen.
BЈовић
11
Ich habe nicht gesagt, dass ich mich an einen ähnlichen Fluss halten soll. Ich sagte, bleib bei einem Fluss, den sie verstehen werden.
John Wu
2
Guter Rat. Als ich in dieser Antwort einen einzelnen Befehl in 5 Funktionen umgestaltet habe , habe ich die Semantik subtil geändert, indem ich Werte in einem logischen Ausdruck vorberechnet habe, die ursprünglich nur bedingt berechnet wurden. Die Rezensenten haben es allerdings erwischt ;-). Der ernsthafte Rat ist, gründlich zu überprüfen und zu testen. Jede Änderung kann zu Fehlern führen, und dies ist möglicherweise der Hauptgrund, warum niemand sie vorgenommen hat.
Peter A. Schneider
6

Ich sehe das nicht als Code-Konvention. Ich sehe dies als jemanden, der nicht versteht, wie man wartbaren Code schreibt, der leicht zu verstehen ist. Ich würde Ihren Code in verschiedene Funktionen aufteilen, während Sie Ihrem Team die Vorteile dieser Vorgehensweise vorschlagen und erläutern, während Sie versuchen, zu verstehen, warum Funktionen mit 300 Zeilen als akzeptabel erachtet werden. Es würde mich sehr interessieren, ihre Argumentation zu hören.

Bernard
quelle
1
" Es gibt keinen Grund, es ist nur unsere Politik. "
5

Die Antwort ist in der Codeüberprüfung.

Die eigentliche Frage ist, ob Sie, wenn Sie gut faktorisierten Code einreichen, der einzige sind, der bereit ist, damit zu arbeiten.

Ich glaube, wie die meisten Leute hier, dass 300 Linienfunktionen ein Gräuel sind. Windex auf eine Mülldeponie zu bringen, bringt jedoch nicht viel. Das Problem ist nicht der Code, es sind die Codierer.

Nur Recht zu haben, ist nicht genug. Sie müssen Leute auf diesem Stil verkaufen. Zumindest beim Lesen. Wenn Sie nicht wie dieser arme Kerl enden, werden Sie entlassen, weil Ihre Fähigkeiten zu weit über Ihren Kollegen liegen

Fangen Sie klein an. Fragen Sie nach und finden Sie heraus, ob jemand andere kleinere Funktionen bevorzugt. Besser noch, stöbern Sie in der Codebasis und sehen Sie, ob Sie herausfinden können, wer die Kleinsten schreibt (Sie stellen möglicherweise fest, dass der hässlichste Code der älteste Code ist und die aktuellen Codierer besseren Code schreiben). Sprechen Sie mit ihnen darüber und finden Sie heraus, ob Sie einen Verbündeten haben. Fragen Sie, ob sie jemanden kennen, dem es genauso geht. Fragen Sie, ob sie jemanden kennen, der kleine Funktionen hasst.

Sammeln Sie diese kleine Gruppe und sprechen Sie über Änderungen. Zeigen Sie ihnen die Art von Code, den Sie schreiben möchten. Stellen Sie sicher, dass sie es lesen können. Nehmen Sie Einwände ernst. Nehmen Sie die Änderungen vor. Lassen Sie Ihren Code genehmigen. Sie haben jetzt die Macht eines Meetings hinter sich. Mit ein paar weiteren Schritten können Sie ein einseitiges Dokument erstellen, das den von Ihnen eingeführten neuen Stil ausdrücklich akzeptiert.

Meetings sind überraschend mächtige Dinge. Sie können Schlagkraft erzeugen. Mit Schlagkraft werden Sie gegen diejenigen kämpfen, die sich dieser Bewegung widersetzen. Und genau das ist es an diesem Punkt. Eine Bewegung. Sie kämpfen für das Recht, den Status Quo zu verbessern. Die Menschen fürchten Veränderungen. Sie müssen süß reden, cajole und stoßen. Aber mit ein bisschen Glück werden Sie sofort akzeptiert.

kandierte_orange
quelle
5
Wenn es so viel Geselligkeit und mehrere Besprechungen erfordert, um Entwickler davon zu überzeugen, dass eine 300-Zeilen-Methode zu lang ist, dann glaube ich nicht, dass Gespräche helfen werden. Das Problem mit dem obigen Ansatz ist, dass Sie in der Defensive sind, wenn Sie um die Erlaubnis zum Schreiben von gutem Code bitten. Wenn Sie jedoch nur guten Code schreiben und sich die Zeit nehmen, bestehenden Code umzugestalten, ist jeder, der Einwände erhebt, in der Defensive, um zu erklären, warum eine 300-Zeilen-Methode gut ist, und um zu rechtfertigen, dass er die Zeit zurücklegt.
Brandon
3
Ich kann Ihnen sagen, dass ich einen Weg finden würde, um solchen Besprechungen zu entgehen, wenn ich zu einer Reihe von Besprechungen eingeladen würde, um Codezeilen pro Funktionsbeschränkung zu diskutieren. Es gibt keine korrekte Nummer und Sie werden nie dazu gebracht, dass sich die Leute einigen. Manchmal muss den Menschen ein besserer Weg gezeigt werden.
Brandon
Manchmal ist es der erste Schritt , eine riesige Funktion aufzuteilen (und die Dinge besser zu benennen und Kommentare und Dokumentationen hinzuzufügen, wie ich es herausfinde), bevor eine Änderung vorgenommen werden kann.
JDługosz
@Brandon Du meinst es wahrscheinlich nicht so, aber ich höre, dass du Recht hast und alle anderen einfach damit umgehen können. Solange Ihr Code funktioniert, spielt es keine Rolle, ob der Rest des Teams ihn nicht versteht. Es lohnt sich auf keinen Fall, ihnen etwas beizubringen. Sie freuen sich sehr, wenn Sie zusehen, wie sie weiterhin 300 Zeilenfunktionen erstellen, während Sie Code auf Ihre eigene Weise schreiben.
candied_orange
1
@CandiedOrange Ich wollte sicher nicht gegen das Team gehen. Was ich meinte war, dass einige Themen am besten in Aktion erlernt werden können, aber der Versuch, ein Team dazu zu bringen, eine demokratische Entscheidung über den Stil zu treffen, wird nicht produktiv sein. Ich habe Konsistenz als Entschuldigung für das Schreiben von unlesbarem Code gesehen. Ergebnis? Mehr unlesbarer Code. Ich konnte eine Reihe von Treffen eingerichtet , darüber zu sprechen, oder ich konnte es einfach beheben, und dann zeigen Menschen die Ergebnisse.
Brandon
3

Manchmal muss man mit dem Strom gehen.

Wie Sie sagten, wurden Sie beauftragt, eine Funktion in eine vorhandene Arbeitscodebasis zu implementieren.

Ungeachtet der Unordnung, und ich verstehe, es ist verlockend, es aufzuräumen. In der Geschäftswelt haben Sie jedoch nicht immer die Möglichkeit, Code umzugestalten.

Ich würde sagen, mach einfach das, wozu du aufgefordert wurdest und mach weiter.

Wenn Sie der Meinung sind, dass es sich lohnt, das Produkt zu überarbeiten oder neu zu schreiben, müssen Sie es zur Diskussion mit dem Team bringen.

meda
quelle
2
Wenn Sie bei jedem kleinen Umbau um Erlaubnis bitten, haben Sie für immer nicht verwaltbaren Code, der für ein Unternehmen gefährlich ist. Manager nur auf Kosten einer Änderung aussehen, aber auf Kosten schauen selten von nicht ändern.
Brandon
5
OP wurde gebeten, eine Funktion zu schreiben, die Hunderte von Codezeilen nicht
ändert
2
@ meda genau! Mir geht es sehr ähnlich. Ich entwickle neue Module für das Firmen-Intranet und finde heraus, was als "Jahre der Vernachlässigung ohne Reparatur" bezeichnet werden kann. Seit 2006 werden Serversoftware und Bibliotheken überhaupt nicht mehr aktualisiert. Ich sollte dieses Durcheinander nicht beseitigen , aber ich brauche wegen der Einschränkungen länger, um zu programmieren. (Stellen Sie sich MySQL 5.2, MySQL 5.0 vor). Ich kann nichts aktualisieren, da der vorhandene Code möglicherweise aufgrund von veraltetem Code nicht auf neueren Versionen ausgeführt werden kann.
Roetnig
3
"Wenn es nicht kaputt ist, repariere es nicht." Ich habe ein 20 Jahre altes Auto, aus dem etwas Öl austritt. Geld wert? Zuverlässig? Ja.
3

Bevor ich feststelle, dass die Praktiken schlecht sind, würde ich zunächst einen Schritt tun, um den Grund für große Methoden und andere Praktiken zu verstehen, die sich als schlecht herausstellen könnten.

Dann müssten Sie sicherstellen, dass die Testabdeckung ziemlich hoch oder wirklich hoch ist (soweit Sie dies ohne größere Umgestaltung tun können). Wenn dies nicht der Fall ist, würde ich darauf hinarbeiten, dass die Abdeckung wirklich hoch ist, obwohl Sie den Code nicht geschrieben haben. Auf diese Weise können Sie eine Beziehung aufbauen, und Ihr neues Team wird Sie ernster nehmen.

Sobald Sie diese Grundlagen abgedeckt haben, würde niemand in ihrem Verstand Sie herausfordern. Führen Sie als Bonus-Item ein Micro-Benchmarking durch, und das wird Ihren Fall wirklich bereichern.

Oft trägt die Art und Weise, wie Sie es ausdrücken, wesentlich dazu bei, die Codekultur zu ändern. Mit gutem Beispiel vorangehen. Oder noch besser, warten Sie auf ein Stück Code, das Sie schreiben können - refaktorieren und Unit-Test, verdammt noch mal, und Viola - Sie werden gehört.

skipy
quelle
Ich überarbeite den aktuellen Code nicht neu, ich schreibe nur eine neue Funktion und bin mir nicht sicher, ob ich einfach der "Konvention" folgen und sie in mehr als 300 Zeilen Monstrosität codieren oder sie in logische Teile aufteilen soll, wie ich es normalerweise tun würde, aber getan habe nicht in diesem Teil der Codebasis getan worden.
Justin
1
Haben sie Regeln, um sicherzustellen, dass Sie neue Methoden in mehr als 300 Zeilen schreiben? wenn nicht, würde ich es richtig schreiben. aber ich würde absolut alles tun, um sicherzustellen, dass ich sie einschließlich der Zweige teste. Ich habe ähnliche Erfahrungen gemacht und normalerweise gewinnt man sie. Trick ist es, es im Laufe der Zeit zu tun und Rapport aufzubauen.
überspringen
3

Diese Art von Frage ist im Grunde " Bitte lesen Sie meine Teamkollegen ". Zufällige Leute im Internet können das nicht. Alle Antworten, die Sie erhalten, sind nur die persönlichen Meinungen der Leute über den Codierungsstil. Der Konsens ist, dass kürzere Methoden vorzuziehen sind, aber Sie scheinen das bereits selbst zu denken, so dass Sie das nicht wiederholen müssen.

Die aktuelle Codebasis scheint also einen anderen Codierungsstil zu verwenden als den, den Sie bevorzugen. Was sollte man tun? Zuerst müssen Sie herausfinden:

  1. Ist dies eine bewusste Designentscheidung, die von Ihrem aktuellen Team unterstützt wird?
  2. Wollen sie, dass du diesem Stil folgst?

Es gibt nur einen Weg, dies herauszufinden. Fragen Sie .

Es kann mehrere Gründe für lange Funktionen geben. Dies könnte daran liegen, dass das Team glaubt, lange Funktionen seien besser als mehrere kurze Funktionen. Dies könnte auch daran liegen, dass es sich um Legacy-Code handelt und das Team bevorzugt, dass neuer Code einem saubereren Design folgt. Also entweder konnte Wahl , die Sie in Schwierigkeiten als Entwickler landen, wenn Sie mit dem Team sprechen nicht und verstehen ihre Argumentation.

JacquesB
quelle
1
Ich stimme voll und ganz zu und füge hinzu: "Könnten Sie gefeuert werden oder anderweitig in Schwierigkeiten geraten, wenn Sie nicht folgen, was andere getan haben?" Dann lautet die Antwort ja! Nach jeder schlechten Sache verlangt das Unternehmen, dass Sie damit umgehen.
Rob
1

Es gibt verschiedene Ebenen des "Stils".

Auf einer Ebene, die in der Regel Teil von Kodierungskonventionen ist, bedeutet dies, wo Leerzeichen, Leerzeilen, Klammern und Namen (gemischte Groß- und Kleinschreibung, Unterstriche usw.) eingefügt werden.

Auf einer anderen Ebene geht es um das Programmiermodell, manchmal um das Vermeiden von Statik oder die Verwendung von Schnittstellen über abstrakte Klassen, um das Aufdecken von Abhängigkeiten und vielleicht sogar um das Vermeiden einiger esoterischer Sprachfunktionen.

Hinzu kommen die vom Projekt verwendeten Bibliotheken und Frameworks.

Manchmal gibt es eine maximale Begrenzung der Funktionsgröße. Aber selten gibt es ein Mindestlimit! Sie sollten also herausfinden, welche dieser Dinge für die Mächte wichtig sind, und versuchen, dies zu respektieren.

Sie müssen herausfinden, ob das Team eine Umgestaltung des vorhandenen Codes ablehnt. Dies sollte nach Möglichkeit unabhängig vom Hinzufügen eines neuen Codes erfolgen.

Auch wenn sie den vorhandenen Code nicht umgestalten möchten, können Sie möglicherweise einige Ebenen in Abstraktionen für den neuen Code einfügen, den Sie hinzufügen. Dies bedeutet, dass Sie im Laufe der Zeit eine bessere Codebasis entwickeln und den alten Code möglicherweise als migrieren können Wartung erfordert.

Erik Eidt
quelle