Welche gängigen „Best Practices“ sind nicht immer die besten und warum? [geschlossen]

"Best Practices" gibt es in unserer Branche überall. Bei einer Google-Suche nach "Coding Best Practices" werden fast 1,5 Millionen Ergebnisse erzielt. Die Idee scheint vielen Trost zu bringen; Folgen Sie einfach den Anweisungen und alles wird gut.

Wenn ich über eine bewährte Methode lese - zum Beispiel habe ich kürzlich einige in Clean Code durchgelesen -, werde ich nervös. Bedeutet das, dass ich diese Praxis immer anwenden sollte? Sind an Bedingungen geknüpft? Gibt es Situationen, in denen dies möglicherweise keine gute Praxis ist? Wie kann ich sicher wissen, bis ich mehr über das Problem erfahren habe?

Einige der in Clean Code erwähnten Praktiken stimmten nicht mit mir überein, aber ich bin mir ehrlich gesagt nicht sicher, ob das daran liegt, dass sie möglicherweise schlecht sind oder ob das nur meine persönliche Voreingenommenheit ist. Ich weiß, dass viele Prominente in der Technologiebranche zu glauben scheinen, dass es keine Best Practices gibt. Zumindest bringen mich meine nörgelnden Zweifel in gute Gesellschaft.

Die Anzahl der Best Practices, über die ich gelesen habe, ist einfach zu groß, um sie hier aufzulisten oder einzelne Fragen zu stellen. Deshalb möchte ich dies als allgemeine Frage formulieren:

Welche als "Best Practices" bezeichneten Codierungsmethoden können unter bestimmten Umständen nicht optimal oder sogar schädlich sein? Was sind diese Umstände und warum machen sie die Praxis zu einer schlechten?

Ich würde gerne von konkreten Beispielen und Erfahrungen hören.

Ich denke, Sie haben mit dieser Aussage den Nagel auf den Kopf getroffen

Ich würde es hassen, Dinge zum Nennwert zu nehmen und nicht kritisch darüber nachzudenken

Ich ignoriere fast alle Best Practices, wenn es keine Erklärung gibt, warum sie existieren

Raymond Chen bringt es am besten in diesen Artikel, wenn er sagt

Guter Rat hat eine Begründung, damit Sie erkennen können, wann er zu einem schlechten Rat wird. Wenn Sie nicht verstehen, warum etwas getan werden sollte, sind Sie in die Falle der Frachtkultprogrammierung geraten und tun dies auch dann, wenn es nicht mehr erforderlich ist oder sogar schädlich wird.

Könnte auch dies in den Ring werfen:

Premature optimization is the root of all evil.

Nein, ist es nicht.

Das vollständige Zitat:

"Wir sollten kleine Wirkungsgrade vergessen, sagen wir in 97% der Fälle: Vorzeitige Optimierung ist die Wurzel allen Übels. Dennoch sollten wir unsere Chancen bei diesen kritischen 3% nicht verpassen."

Dies bedeutet, dass Sie während Ihres gesamten Konstruktionsprozesses von spezifischen, strategischen Leistungsverbesserungen profitieren . Dies bedeutet, dass Sie Datenstrukturen und Algorithmen verwenden, die mit den Leistungszielen übereinstimmen. Dies bedeutet, dass Sie Überlegungen zum Design kennen, die sich auf die Leistung auswirken. Es bedeutet aber auch, dass Sie nicht leichtfertig optimieren, wenn Sie dies tun, was zu geringfügigen Gewinnen auf Kosten der Wartbarkeit führt.

Anwendungen müssen gut strukturiert sein, damit sie am Ende nicht herunterfallen, wenn Sie sie ein wenig belasten, und dann werden sie neu geschrieben. Das abgekürzte Zitat birgt die Gefahr, dass Entwickler es allzu oft als Ausrede benutzen, um überhaupt nicht an die Leistung zu denken, bis es zu spät ist, etwas dagegen zu unternehmen. Es ist besser, von Anfang an eine gute Leistung zu erzielen, vorausgesetzt, Sie konzentrieren sich nicht auf Kleinigkeiten.

Angenommen, Sie erstellen eine Echtzeitanwendung auf einem eingebetteten System. Sie wählen Python als Programmiersprache, weil "die vorzeitige Optimierung die Wurzel allen Übels ist". Jetzt habe ich nichts gegen Python, aber es ist eine interpretierte Sprache. Wenn die Rechenleistung begrenzt ist und eine bestimmte Menge an Arbeit in Echtzeit oder nahezu in Echtzeit erledigt werden muss und Sie eine Sprache wählen, die mehr Rechenleistung für die Arbeit erfordert als Sie, sind Sie königlich, weil Sie Jetzt muss ich mit einer fähigen Sprache von vorne anfangen.

Eine Rückgabe pro Funktion / Methode.

Das Rad nicht neu erfinden ist ein häufig missbrauchtes Dogma. Wenn es eine geeignete Lösung gibt, verwenden Sie sie, anstatt Ihre eigene zu erstellen. Neben der Einsparung von Aufwand ist die vorhandene Lösung wahrscheinlich besser implementiert (fehlerfrei, effizient, getestet) als ursprünglich geplant. So weit, ist es gut.

Das Problem ist, dass eine 100% geeignete Lösung selten existiert. Möglicherweise gibt es eine zu 80% geeignete Lösung, und die Verwendung ist wahrscheinlich in Ordnung. Aber wie wäre es mit 60% geeignet? 40%? Wo ziehst du die Linie? Wenn Sie die Grenze nicht ziehen, können Sie eine aufgeblähte Bibliothek in Ihr Projekt einbinden, weil Sie 10% der Funktionen nutzen - nur weil Sie vermeiden möchten, das Rad neu zu erfinden.

Wenn Sie das Rad neu erfinden, erhalten Sie genau das, was Sie wollen. Sie lernen auch , wie man Räder herstellt. Learning by Doing sollte nicht unterschätzt werden. Und am Ende kann ein benutzerdefiniertes Rad durchaus besser sein als ein handelsübliches generisches Rad.

"Unit Test Everything."

Ich habe oft gehört, dass jeder Code Unit-Tests haben sollte, ein Punkt, mit dem ich nicht einverstanden bin. Wenn Sie einen Test für eine Methode haben, muss jede Änderung an der Ausgabe oder Struktur dieser Methode zweimal vorgenommen werden (einmal im Code, einmal im Test).

Daher sollten Unit-Tests meiner Meinung nach proportional zur strukturellen Stabilität des Codes sein. Wenn ich ein geschichtetes System von Grund auf schreibe, wird meine Datenzugriffsebene das Wazoo testen. Meine Business-Logik-Ebene wird ziemlich gut getestet, meine Präsentations-Ebene wird einige Tests haben, und meine Ansichten werden kaum bis gar keine Tests haben.

Immer auf Schnittstellen programmieren.

Manchmal wird es nur eine Implementierung geben. Wenn wir den Vorgang des Extrahierens einer Schnittstelle bis zu dem Zeitpunkt verzögern, an dem wir den Bedarf erkennen, werden wir häufig feststellen, dass dies nicht erforderlich ist.

Verwenden Sie nichts Open-Source (oder Nicht-Microsoft für Sie .NET-Entwickler)

Wenn Microsoft es nicht entwickelt hat, verwenden wir es hier nicht. Möchten Sie ORM - EF verwenden, IOC - Unity verwenden, protokollieren - Anwendungsblock für die Unternehmensprotokollierung. Es gibt so viele bessere Bibliotheken - aber ich bin immer dabei, aus dem Dollar-Menü der Entwicklungswelt zu bestellen. Ich schwöre, jedes Mal, wenn ich Microsoft Best Practices höre, denke ich "McDonald's Nutritional Guidelines". Sicher, du wirst wahrscheinlich leben, wenn du ihnen folgst, aber du wirst auch unterernährt und übergewichtig sein.

• Hinweis : Dies ist möglicherweise nicht Ihre beste Praxis, aber es ist ein allgemeiner fast überall folgte ich gearbeitet habe.

Objektorientierung

Es gibt die Annahme, nur weil Code "objektorientiert" ist, ist es magisch gut. Daher werden Funktionen in Klassen und Methoden eingeteilt, nur um objektorientiert zu sein.

Der gesamte Code sollte kommentiert werden.

Nein, das sollte nicht sein. Manchmal haben Sie offensichtlichen Code, zum Beispiel sollten Setter erst kommentiert werden, wenn sie etwas Besonderes tun. Auch warum sollte ich das kommentieren:

/** hey you, if didn't get, it's logger. */
private static Logger logger = LoggerFactory.getLogger(MyClass.class);

Methoden, insbesondere Scrum. Ich kann kein ernstes Gesicht behalten, wenn Erwachsene den Satz "Scrum Master" verwenden. Ich habe es so satt, Entwickler zu hören, die protestieren, dass ein Aspekt von Methodology X nicht für ihr Unternehmen funktioniert, nur um von Guru So-and-So zu erfahren, dass es nicht funktioniert, weil sie in der Tat keine wahren Praktiker sind of Methodology X. "Scrum härter, mein Padawan Lerner!"

In agilen Methoden steckt ein Haufen Weisheit - viele von ihnen -, aber sie sind oft in so viel Mist eingelegt, dass ich meinen Würgereflex nicht bekämpfen kann. Nehmen Sie dieses Bit aus Wikipedia Scrum-Seite :

In Scrum sind eine Reihe von Rollen definiert. Alle Rollen fallen in zwei unterschiedliche Gruppen - Schweine und Hühner -, basierend auf der Art ihrer Beteiligung am Entwicklungsprozess.

"Ja wirklich?" Schweine und Hühner, sagst du? Faszinierend! Ich kann es kaum erwarten, meinem Chef das hier vorzustellen ...

Objektrelationale Zuordnung ... http://en.wikipedia.org/wiki/Object-relational_mapping

Ich möchte nie von meinen Daten abgezogen werden, noch möchte ich diese präzise Kontrolle und Optimierung verlieren. Meine Erfahrung mit diesen Systemen war äußerst schlecht ... Die von diesen Abstraktionsebenen generierten Abfragen sind noch schlimmer als die, die ich vom Offshoring gesehen habe.

Funktionsnamen so schreiben, als wären sie englische Sätze:

Draw_Foo()
Write_Foo()
Create_Foo()

usw. Das mag toll aussehen, aber es ist ein Schmerz, wenn Sie eine API lernen. Wie viel einfacher ist es, einen Index nach "Alles, was mit Foo beginnt" zu durchsuchen?

Foo_Draw()
Foo_Write()
Foo_Create()

usw.

MVC - Ich stelle oft fest, dass es bei vielen Webdesign-Problemen im MVC-Ansatz mehr darum geht, ein Framework (Schienen usw.) glücklich zu machen, als um Einfachheit oder Struktur. MVC ist ein Favorit von "Architektur-Astronauten", die offenbar übermäßiges Gerüst gegenüber Einfachheit schätzen. ymmv.

Klassenbasiertes OO - fördert meiner Meinung nach komplexe Strukturen des veränderlichen Zustands. Die einzigen überzeugenden Fälle, die ich im Laufe der Jahre für klassenbasierte OO gefunden habe, sind die kitschigen Beispiele für "Form-> Rechteck-> Quadrat", die Kapitel 1 jedes OO-Buches bilden

YAGNI

( Du wirst es nicht brauchen )

Dieser Ansatz hat mich Stunden und Stunden gekostet, als ich Funktionen auf einer vorhandenen Codebasis implementieren musste, wo sorgfältige Planung diese Funktionen zuvor einbezogen hätte.

Meine Ideen wurden oft wegen YAGNI abgelehnt, und meistens musste jemand später für diese Entscheidung bezahlen.

(Natürlich könnte man argumentieren, dass eine gut gestaltete Codebasis auch das spätere Hinzufügen von Funktionen ermöglichen würde, aber die Realität sieht anders aus.)

Für SQL

1. Verwenden Sie keine Trigger
2. Verstecken Sie Tabellen immer hinter Ansichten

In Ordnung:

1. Sie sind ein Feature, das seinen Platz hat. Sie haben mehrere Aktualisierungspfade zu einer Tabelle oder müssen zu 100% überwacht werden?

2. Warum nur? Ich würde, wenn ich umgestalten würde, um einen Vertrag beizubehalten, aber nicht, wenn ich gelesen habe, dass Leute die Ansicht ändern, um mit irgendwelchen Tabellenänderungen übereinzustimmen

Bearbeiten:

Nummer 3: Vermeiden Sie * mit EXISTEN. Versuchen Sie es mit 1/0. Es klappt. Die Spaltenliste wird nicht nach SQL-Standard ausgewertet. Seite 191

Meist Design Patterns. Sie sind überstrapaziert und unterstrapaziert.

Das Prinzip der Einzelverantwortung

^{("Jede Klasse sollte nur eine einzige Verantwortung haben. Mit anderen Worten, jede Klasse sollte einen und nur einen Grund haben, sich zu ändern.")}

Ich stimme dir nicht zu. Ich denke, eine Methode sollte nur einen Grund haben, sich zu ändern, und alle Methoden in einer Klasse sollten eine logische Beziehung zueinander haben , aber die Klasse selbst könnte tatsächlich mehrere (verwandte) Dinge tun .

Nach meiner Erfahrung wird dieses Prinzip zu oft zu eifrig angewendet, und Sie haben am Ende viele winzige Ein-Methoden-Klassen. Beide agilen Shops, in denen ich gearbeitet habe, haben dies getan.

Stellen Sie sich vor, die Ersteller der .Net-API hätten diese Art von Mentalität: Anstelle von List.Sort (), List.Reverse (), List.Find () usw. hätten wir die Klassen ListSorter, ListReverser und ListSearcher!

Anstatt weiter gegen die SRP zu argumentieren (was theoretisch nicht schrecklich ist) , möchte ich einige meiner langwierigen anekdotischen Erfahrungen mitteilen:

An einer Stelle, an der ich gearbeitet habe, habe ich einen sehr einfachen Max-Flow-Löser geschrieben, der aus fünf Klassen bestand: einem Knoten, einem Diagramm, einem Diagrammersteller, einem Diagrammlöser und einer Klasse, um mit dem Diagrammersteller / -löser a zu lösen reales Problem. Keiner war besonders komplex oder lang (der Löser war mit ~ 150 Zeilen bei weitem der längste). Es wurde jedoch entschieden, dass die Klassen zu viele "Verantwortlichkeiten" hatten, also begannen meine Mitarbeiter mit der Umgestaltung des Codes. Als sie fertig waren, waren meine 5 Klassen auf 25 Klassen erweitert worden, deren gesamte Codezeilen mehr als das Dreifache dessen waren, was sie ursprünglich waren. Der Ablauf des Codes war nicht mehr offensichtlich, noch war der Zweck der neuen Unit-Tests; Es fiel mir jetzt schwer, herauszufinden, was mein eigener Code tat.

Am selben Ort hatte fast jede Klasse nur eine einzige Methode (ihre einzige "Verantwortung"). Es war fast unmöglich, dem Ablauf innerhalb des Programms zu folgen, und die meisten Unit-Tests bestanden darin, zu testen, ob diese Klasse Code aus einer anderen Klasse nannte , deren Zweck für mich gleichermaßen ein Rätsel war. Es gab buchstäblich Hunderte von Klassen, in denen es (IMO) nur Dutzende geben sollte. Jede Klasse hat nur eine "Sache" gemacht , aber selbst mit Namenskonventionen wie "AdminUserCreationAttemptorFactory" war es schwierig, die Beziehung zwischen Klassen zu bestimmen .

An einem anderen Ort (der auch die Mentalität hatte, nur eine Methode zu haben ) versuchten wir, eine Methode zu optimieren, die während einer bestimmten Operation 95% der Zeit in Anspruch nahm. Nachdem ich es (ziemlich dumm) ein wenig optimiert hatte, wandte ich mich der Frage zu, warum es eine Bajillion Mal genannt wurde. Es wurde in einer Schleife in einer Klasse aufgerufen ... deren Methode in einer Schleife in einer anderen Klasse aufgerufen wurde .. die auch in einer Schleife aufgerufen wurde ..

Insgesamt gab es fünf Ebenen von Schleifen, die (im Ernst) auf 13 Klassen verteilt waren. Es war unmöglich festzustellen, was eine Klasse tatsächlich tat, wenn man sie sich nur ansah - man musste ein mentales Diagramm darüber erstellen, welche Methoden sie nannte und welche Methoden diese Methoden nannten und so weiter. Wenn alles in eine Methode zusammengefasst worden wäre, wären es nur etwa 70 Zeilen gewesen, wenn unsere Problemmethode in fünf unmittelbar offensichtlichen Schleifenebenen verschachtelt gewesen wäre.

Meine Bitte, diese 13 Klassen in eine Klasse umzugestalten, wurde abgelehnt.

Nun, da Sie Clean Code erwähnt haben, obwohl es einige gute Ideen enthält, denke ich, dass seine Besessenheit, alle Methoden in Submethoden und jene in Submethoden usw. umzuwandeln, viel zu weit gegangen ist. Anstelle von ein paar Zehn-Zeilen-Methoden solltest du zwanzig (angeblich gut benannte) Einzeiler bevorzugen. Offensichtlich denkt jemand, dass es sauber ist, aber für mich scheint es viel schlimmer zu sein als die Originalversion.

Auch das Ersetzen einfacher elementarer Dinge wie

0 == memberArray.length

innerhalb einer Klasse mit einem Aufruf der klasseneigenen Methode wie

isEmpty()

ist eine fragwürdige "Verbesserung" IMHO. Zusatz: Der Unterschied besteht darin, dass die erste Prüfung genau das tut, was sie sagt: prüft, ob die Arraylänge 0 ist. Ok, isEmpty()prüft möglicherweise auch die Arraylänge. Es könnte aber auch so implementiert werden:

return null != memberArray ? 0 == memberArray.length : true;

Das heißt, es beinhaltet eine implizite Nullprüfung! Dies mag für eine öffentliche Methode ein gutes Verhalten sein - wenn das Array null ist, ist sicherlich etwas leer -, aber wenn es sich um Klasseninternale handelt, ist dies nicht so gut. Während die Kapselung nach außen ein Muss ist, müssen die Internen der Klasse genau wissen, was in der Klasse vor sich geht. Sie können die Klasse nicht in sich selbst einkapseln . Explizit ist besser als implizit.

Das soll nicht heißen, dass es nicht gut ist, lange Methoden oder logische Vergleiche aufzuschlüsseln. Natürlich ist es das, aber bis zu welchem ​​Grad - wo der Sweet Spot ist - ist offensichtlich eine Frage des Geschmacks. Das Aufbrechen einer langen Methode führt zu mehr Methoden, und das ist nicht kostenlos. Sie müssen im Quellcode herumspringen, um zu sehen, was wirklich los ist, wenn Sie es auf einen Blick sehen könnten, wenn all diese Dinge in einer einzigen Methode wären.

Ich würde sogar so weit gehen zu sagen, dass eine 1-Zeilen-Methode in einigen Fällen zu kurz ist , um eine Methode zu verdienen.

"Seien Sie liberal mit Kommentaren"

Kommentare sind definitiv eine gute Sache, aber zu viele sind genauso schlecht, wenn nicht schlimmer als nicht genug. Warum? Leute neigen dazu, Kommentare auszuschalten, wenn sie zu viele unnötige Kommentare sehen. Ich sage nicht, dass Sie perfekt selbstdokumentierenden Code haben können, aber es ist besser, Code zu verwenden, der zur Erklärung Kommentare benötigt.

GoTo als schädlich eingestuft

Wenn Sie eine Zustandsmaschine implementieren, kann eine GOTO-Anweisung sinnvoller sein (Lesbarkeit und effizienter Code) als ein Ansatz der "strukturierten Programmierung". Es hat einige Kollegen sehr beunruhigt, als das erste Stück Code, das ich in einem neuen Job geschrieben habe, nicht nur eine, sondern mehrere goto-Anweisungen enthielt. Zum Glück waren sie intelligent genug, um zu erkennen, dass dies in diesem speziellen Fall die beste Lösung war.

Jedes "Best Practice", das keine vernünftigen und dokumentierten Ausnahmen von seinen Regeln zulässt, ist einfach beängstigend.

Die Opfer, die wir bringen, um Code testbar zu machen

Ich springe durch viele Rahmen, um meinen Code testbar zu machen, aber ich tue nicht so, als ob ich keine Wahl hätte. Ich höre jedoch oft Leute, die die Idee vertreten, dass dies "Best Practices" sind. Diese Praktiken beinhalten (in der Sprache von .Net geschrieben, aber auch für andere Sprachen) :

• Erstellen einer Schnittstelle für jede Klasse. Dies verdoppelt die Anzahl der zu verarbeitenden Klassen (Dateien) und dupliziert den Code. Ja, die Schnittstellenprogrammierung ist gut, aber dafür sind die öffentlichen / privaten Spezifizierer gedacht.
• Jede Klasse, die beim Start nicht instanziiert wird, benötigt eine Factory. Das ist natürlich new MyClass()viel einfacher als das Schreiben einer Factory, aber jetzt kann die Methode, mit der sie erstellt wird, nicht isoliert getestet werden. Ohne diese Tatsache würde ich nur 1/20 der Anzahl der Werksklassen machen, die ich jetzt mache.
• Machen Sie jede Klasse öffentlich, was den Zweck zunichte macht, überhaupt über Zugriffsspezifizierer für Klassen zu verfügen. Auf nicht öffentliche Klassen kann jedoch nicht aus anderen Projekten zugegriffen (und somit getestet) werden. Die einzige andere Option besteht darin, den gesamten Testcode in dasselbe Projekt zu verschieben (und ihn daher mit dem Endprodukt freizugeben).
• Abhängigkeitsspritze. Offensichtlich hat zu geben jede andere Klasse ich ein Feld und einen Konstruktor-Parameter verwenden , wird deutlich mehr Arbeit , als sie nur zu schaffen , wenn ich sie brauche; aber dann kann ich diese klasse nicht mehr isoliert testen.
• Das Prinzip der Einzelverantwortung, das mir so viele Kopfschmerzen bereitet hat , hat mich zu einer eigenen Antwort bewegt .

Was können wir also tun, um das zu beheben? Wir brauchen eine drastische Änderung in der Spracharchitektur:

• Wir brauchen die Fähigkeit, Klassen zu verspotten
• Wir würden die Fähigkeit benötigen, private Methoden interner Klassen aus einem anderen Projekt heraus zu testen (dies mag wie eine Sicherheitslücke erscheinen, aber ich sehe kein Problem, wenn der Proband gezwungen ist, seine Testerklassen zu benennen) .
• Die Abhängigkeitsinjektion (oder der Servicestandort) sowie etwas, das unserem bestehenden Fabrikmuster entspricht, müsste ein Kernbestandteil der Sprache sein.

Kurz gesagt, wir brauchen eine Sprache, die von Grund auf unter dem Gesichtspunkt der Testbarkeit entwickelt wurde .

Teilen von Anwendungen in Ebenen; Datenschicht, Business-Schicht, UI-Schicht

Der Hauptgrund, warum ich das nicht mag, ist, dass die meisten Orte, die dieser Methode folgen, sehr spröde Frameworks verwenden, um dies zu erreichen. IE UI Layer ist handcodiert, um mit Business Layer-Objekten umzugehen. Business Layer-Objekte sind handcodiert, um mit Business Rules und Datenbanken umzugehen. Die Datenbank ist SQL und ist bereits ziemlich spröde und wird von der "DBA" -Gruppe verwaltet, die Änderungen nicht mag.

Warum ist das so schlimm? Die häufigste Verbesserungsanforderung lautet wahrscheinlich "Ich benötige ein Feld auf Bildschirm X mit Y." Knall! Sie haben nur eine neue Funktion, die sich auf jede einzelne Ebene auswirkt, und wenn Sie Ebenen mit verschiedenen Programmierern trennen, wurde dies für eine sehr einfache Änderung zu einem großen Problem, an dem mehrere Personen und Gruppen beteiligt waren.

Außerdem weiß ich nicht, wie oft ich in solchen Auseinandersetzungen gestritten habe. "Das Namensfeld ist auf eine maximale Länge von 30 begrenzt. Handelt es sich um eine Benutzeroberflächen- oder Geschäftsschicht- oder Datenschicht-Ausgabe?" Und es gibt hundert Argumente und keine richtige Antwort. Die Antwort ist die gleiche, sie wirkt sich auf alle Ebenen aus, Sie möchten die Benutzeroberfläche nicht dumm machen und müssen alle Ebenen durchgehen und in der Datenbank versagen, nur damit der Benutzer feststellt, dass seine Eingabe zu lang ist. Wenn Sie es ändern, wirkt es sich auf alle Ebenen usw. aus.

Die "Schichten" neigen ebenfalls zum Auslaufen; Wenn eine Ebene physisch durch Prozess- / Maschinengrenzen getrennt ist (IE-Webbenutzeroberfläche und Geschäfts-Backend-Logik), werden die Regeln dupliziert, damit alles einigermaßen gut funktioniert. Das heißt, einige Geschäftslogiken landen in der Benutzeroberfläche, obwohl es sich um eine "Geschäftsregel" handelt, da der Benutzer die Benutzeroberfläche benötigt, um darauf zu reagieren.

Wenn das verwendete Framework oder die verwendete Architektur gegenüber kleinen Änderungen und Leckagen, dh basierend auf Metadaten, unempfindlich ist und dynamisch über alle Ebenen angepasst wird, kann dies weniger schmerzhaft sein. Bei den meisten Frameworks ist dies jedoch ein großer Aufwand, der für jede kleine Änderung Änderungen an der Benutzeroberfläche, in der Geschäftsschicht und in der Datenbank erforderlich macht und mehr Arbeit und weniger Hilfe verursacht, als die Technik bewirken soll.

Ich werde wahrscheinlich dafür zugeschlagen werden, aber da ist es :)

JavaBeans

Die Verwendung von JavaBeans in Java. Siehe meine Frage Warum sollte ich keine unveränderlichen POJOs anstelle von JavaBeans verwenden? auf StackOverflow.

User Stories / Use Cases / Personas

Ich verstehe die Notwendigkeit für diese, wenn Sie für eine Branche programmieren, mit der Sie nicht vertraut sind, aber ich denke, wenn sie in vollem Umfang implementiert werden, werden sie zu unternehmerisch und zu einer Zeitverschwendung.

80 Zeichen / Zeilengrenzen sind dumm

Ich verstehe, dass einige Kompromisse gemacht werden müssen, um der Geschwindigkeit des langsamsten Läufers auf der GUI-Seite zu entsprechen (Einschränkungen der Bildschirmauflösung usw.), aber warum gilt diese Regel für die Code-Formatierung?

Es gab diese kleine Erfindung namens horizontale Bildlaufleiste, die erstellt wurde, um den virtuellen Bildschirmbereich außerhalb der am weitesten rechts liegenden Pixelgrenze zu verwalten. Warum nicht Entwickler, denen es gelungen ist, produktivitätssteigernde Tools wie Syntaxhervorhebung und automatische Vervollständigung zu erstellen?

Klar, es gibt CLI-Editoren, die von * nix-Dinosauriern religiös verwendet werden und den müden alten Einschränkungen ihrer VT220-Terminals folgen, aber warum halten wir uns an den gleichen Standard?

Ich sage, schraube die 80 Zeichen Grenze. Wenn die Dinosaurier episch genug sind, um den ganzen Tag über Emacs / Vim zu hacken, warum kann dann nicht eine Erweiterung erstellt werden, die automatisch Zeilen umbricht oder ihren CLI-IDEs horizontale Bildlauffunktionen verleiht?

Monitore mit 1920 x 1080 Pixeln werden irgendwann zur Norm und Entwickler auf der ganzen Welt leben immer noch unter den gleichen Einschränkungen, ohne dass es darauf ankommt, warum sie dies tun.

80-Zeichen-Limits sind keine Best Practice, sondern eine Nischenpraxis für eine sehr geringe Anzahl von Programmierern und sollten als solche behandelt werden.

Bearbeiten:

Es ist verständlich, dass viele Entwickler die horizontale Bildlaufleiste nicht mögen, weil sie eine Mausbewegung erfordert. Erhöhen Sie die Spaltenbreitenbeschränkung für diejenigen von uns, die moderne Bildschirme verwenden, auf eine höhere Zahl (als 80).

Als 800x600-Computermonitore für die meisten Benutzer zur Norm wurden, erhöhten Webentwickler ihre Website-Breite, um der Mehrheit gerecht zu werden ... Warum können Entwickler nicht dasselbe tun?

Messen, Messen, Messen

Also gut, messe weg, aber um Leistungsfehler zu isolieren , funktioniert das Messen genauso gut wie die sukzessive Beseitigung. Hier ist die Methode, die ich benutze.

Ich habe versucht, die Quelle der Maßnahme-Maßnahme "Weisheit" aufzuspüren. Jemand mit einer Seifenkiste, die groß genug ist, hat es gesagt, und jetzt reist es.

Mein Lehrer verlangt, dass ich alle meine Bezeichner (ohne Konstanten) mit Kleinbuchstaben beginne, z myVariable.

Ich weiß, es scheint eine Kleinigkeit zu sein, aber viele Programmiersprachen erfordern Variablen, die mit Großbuchstaben beginnen. Ich schätze Konsistenz, deshalb ist es meine Gewohnheit, alles mit Großbuchstaben zu beginnen.

Verwenden Sie Singletons

Wenn Sie nur eine Instanz von etwas haben sollten. Ich kann nicht mehr widersprechen . Verwenden Sie niemals einen Singleton und weisen Sie ihn nur einmal zu und übergeben Sie den Zeiger / das Objekt / die Referenz nach Bedarf. Es gibt absolut keinen Grund, dies nicht zu tun.

Verwenden von Int ohne Vorzeichen als Iterator

Wann werden sie erfahren, dass die Verwendung von signiertem Int viel sicherer und weniger fehleranfällig ist. Warum ist es so wichtig, dass der Array-Index nur eine positive Zahl sein kann, dass jeder froh ist, die Tatsache zu übersehen, dass 4 - 5 4294967295 ist?

Methoden sollten nicht länger als ein einzelner Bildschirm sein

Ich stimme dem Prinzip der Einzelverantwortung vollkommen zu, aber warum meinen die Leute, dass "eine Funktion / Methode auf der feinsten Ebene der logischen Granularität nur eine einzige Verantwortung haben kann"?

Die Idee ist einfach. Eine Funktion / Methode sollte eine Aufgabe erfüllen. Wenn ein Teil dieser Funktion / Methode anderweitig verwendet werden kann, teilen Sie ihn in eine eigene Funktion / Methode auf. Wenn es an anderer Stelle im Projekt verwendet werden kann, verschieben Sie es in eine eigene Klasse oder in eine Utility-Klasse und machen Sie es intern zugänglich.

Eine Klasse mit 27 Hilfsmethoden, die nur einmal im Code aufgerufen werden, ist dumm, eine Verschwendung von Speicherplatz, eine unnötige Erhöhung der Komplexität und eine massive Zeitersparnis. Es klingt eher nach einer guten Regel für Leute, die beschäftigt sein wollen, Code umzugestalten, aber nicht viel produzieren wollen.

Hier ist meine Regel ...

Schreiben Sie Funktionen / Methoden, um etwas zu erreichen

Wenn Sie dabei sind, Code zu kopieren oder einzufügen, fragen Sie sich, ob es besser ist, eine Funktion / Methode für diesen Code zu erstellen. Wenn eine Funktion / Methode nur einmal in einer anderen Funktion / Methode aufgerufen wird, ist es wirklich sinnvoll, sie an erster Stelle zu haben (wird sie in Zukunft häufiger aufgerufen). Ist es sinnvoll, während des Debuggens mehr Sprünge in / aus Funktionen / Methoden einzufügen (dh macht der hinzugefügte Sprung das Debuggen einfacher oder schwieriger)?

Ich stimme voll und ganz zu, dass Funktionen / Methoden mit mehr als 200 Zeilen überprüft werden müssen, aber einige Funktionen nur eine Aufgabe in so vielen Zeilen ausführen und keine nützlichen Teile enthalten, die für den Rest des Projekts abstrahiert / verwendet werden können.

Ich betrachte es aus der Perspektive eines API-Entwicklers ... Wenn sich ein neuer Benutzer das Klassendiagramm Ihres Codes ansehen würde, wie viele Teile dieses Diagramms wären innerhalb des gesamten Projekts sinnvoll und wie viele würden ausschließlich als existieren Helfer zu anderen Teilen innerhalb des Projekts.

Wenn ich zwischen zwei Programmierern wählen würde: Der erste hat die Tendenz, Funktionen / Methoden zu schreiben, die versuchen, zu viel zu tun; der zweite bricht jeden Teil jeder Funktion / Methode auf die feinste Granularitätsebene; Ich würde die ersten Hände runter wählen. Der erste würde mehr erreichen (dh mehr Fleisch von der Anwendung schreiben), sein Code wäre leichter zu debuggen (aufgrund weniger Sprünge in / aus Funktionen / Methoden während des Debuggens) und er würde weniger Zeit damit verschwenden, fleißige Arbeit zu vervollkommnen, wie Der Code sieht besser aus als zu perfektionieren, wie der Code funktioniert.

Begrenzen Sie unnötige Abstraktionen und verschmutzen Sie die automatische Vervollständigung nicht.