🏜️ 📕 👩‍👩‍👧‍👦 Gesetze der Programmierung 👩🏾‍💼 😧 🤴🏻

Gesetze, Theorien, Prinzipien und Muster, die für Entwickler nützlich sind

Einführung

Repository-Übersetzung github.com/dwmkerr/hacker-laws

In Diskussionen im Zusammenhang mit der Softwareentwicklung wird häufig über unterschiedliche Gesetze gesprochen. In diesem Repository werden Links und Beschreibungen einiger der bekanntesten von ihnen gespeichert.

Es enthält Erklärungen einiger Gesetze, Prinzipien und Gesetze, aber es gibt keine Aufregung zu ihren Gunsten. Sie zu benutzen oder nicht, ist immer ein strittiger Punkt, und alles hängt davon ab, woran Sie arbeiten.

Die Gesetze

Amdahls Gesetz

Amdahls Gesetz ist eine Formel, die das Potenzial zur Beschleunigung einer Rechenaufgabe demonstriert, die mit einer Erhöhung der Menge an Systemressourcen erreicht werden kann. Es wird normalerweise beim parallelen Rechnen verwendet und kann die tatsächlichen Vorteile einer Erhöhung der Anzahl der Prozessoren unter Berücksichtigung der Parallelitätsbeschränkungen des Programms vorhersagen.

Wir geben ein Beispiel. Wenn das Programm aus zwei Teilen besteht - Teil A, der auf einem Prozessor ausgeführt werden muss, und Teil B, der parallelisiert werden kann, ist klar, dass die Vorteile des Hinzufügens mehrerer Prozessoren zu dem System, das das Programm ausführt, begrenzt sind. Möglicherweise kann dies Teil B stark beschleunigen - die Geschwindigkeit von Teil A ändert sich jedoch nicht.

Das folgende Diagramm zeigt Beispiele für mögliche Geschwindigkeitsgewinne:

Wie Sie sehen, sind die Vorteile des Hinzufügens von mehr als 10 separaten Prozessoren vernachlässigbar, selbst wenn 50% des Programms parallelisiert werden können. Wenn das Programm zu 95% parallelisiert werden kann, werden die Verbesserungen auch nach dem Hinzufügen von Tausenden von Prozessoren spürbar.

Mit der Verlangsamung des Moore'schen Gesetzes und der Beschleunigung des Prozessors wird die Parallelisierung zum Schlüssel zur Verbesserung der Effizienz. Die Grafikprogrammierung ist ein gutes Beispiel: Mit der modernen Programmierung auf Basis von Shadern können Sie Fragmente des Bildes parallel zeichnen, sodass Sie in modernen Grafikkarten Tausende von Prozessorkernen (GPUs oder Shader-Module) finden.

Theorie der zerbrochenen Fenster

Die Theorie der zerbrochenen Fenster besagt , dass sichtbare Anzeichen von Kriminalität (oder mangelnde Sorge um die Umwelt) eine Zunahme der Anzahl und Schwere der Kriminalität (und eine weitere Verschlechterung der Umwelt) zur Folge haben.

Diese Theorie wurde auf die Softwareentwicklung angewendet, was darauf hindeutet, dass eine schlechte Codequalität (oder die sogenannte " technische Verschuldung ") das Gefühl hervorrufen kann, dass alle Versuche, die Qualität zu verbessern, ignoriert oder unterschätzt werden, was zum Auftreten von neuem fehlerhaftem Code führt. Dieser Effekt entwickelt sich in einer Kaskade, weshalb sich die Qualität mit der Zeit verschlechtert.

Brooks Law

Das Hinzufügen zusätzlicher Humanressourcen zu einem verspäteten Projekt verzögerte seine Leistung noch mehr.

Das Brooks-Gesetz besagt, dass in vielen Fällen Versuche, die Veröffentlichung eines bereits verspäteten Projekts zu beschleunigen, indem zusätzliche Personen hinzugefügt werden, dazu führen, dass das Projekt noch später veröffentlicht wird, als es könnte. Brooks betont jedoch, dass dies eine übermäßige Vereinfachung des Problems darstellt. Er argumentierte wie folgt: Angesichts der Kosten für die Zeit, die für die Beauftragung neuer Ressourcen und die Kommunikation der Menschen untereinander erforderlich ist, sinkt kurzfristig die Entwicklungsrate des Projekts. Außerdem können viele Aufgaben möglicherweise nicht getrennt werden, dh sie können nicht einfach auf Ressourcen verteilt werden, deren Menge erhöht wurde, sodass die potenzielle Geschwindigkeitssteigerung nicht so signifikant ist.

Das allgemeine Sprichwort "Neun Frauen können in einem Monat kein Baby zur Welt bringen" bezieht sich auf das Brooks-Gesetz, insbesondere weil einige Arten von Arbeit nicht geteilt oder parallelisiert werden können.

Dies ist das Hauptthema des Buches Mythical Man-Month.

Conway Gesetz

Das Gesetz von Conway besagt, dass die technischen Einschränkungen des entworfenen Systems die Struktur der Organisation widerspiegeln. Er wird oft erinnert, wenn er versucht, die Organisation zu verbessern. Das Gesetz besagt, dass wenn eine Organisation in viele kleine, nicht verwandte Module strukturiert ist, das von ihr erstellte Programm dasselbe ist. Wenn die Organisation basierend auf bestimmten Funktionen oder Diensten auf Branchen aufgebaut ist, spiegelt die Software diese Tatsache wider.

Cunningham Law

Der beste Weg, um im Internet die richtige Antwort zu finden, besteht nicht darin, eine Frage zu stellen, sondern eine absichtlich falsche Antwort zu veröffentlichen.

Stephen McGeady sagt, dass Ward Cunningham ihm in den frühen 1980er Jahren Ratschläge gab: "Der beste Weg, die richtige Antwort im Internet zu finden, besteht nicht darin, eine Frage zu stellen, sondern eine absichtlich falsche Antwort zu veröffentlichen." McGeady nannte es "Cunninghams Gesetz", obwohl Cunningham es selbst leugnet und sagt, er sei "falsch zitiert". Obwohl sich der Ausdruck ursprünglich auf die Kommunikation im Usenet bezog, wurde das Gesetz seitdem verwendet, um Arbeit und andere Gemeinschaften (Wikipedia, Reddit, Twitter, Facebook) zu beschreiben.

Dunbar Nummer

Die Anzahl der Dunbar ist eine Grenze für die Anzahl der dauerhaften sozialen Bindungen, die eine Person aufrechterhalten kann. Dies bezieht sich auf Beziehungen, die das Wissen über die Besonderheiten eines bestimmten Individuums beinhalten, dessen Verbindung aufrechterhalten werden muss, seinen Charakter sowie seinen sozialen Status und seine Verbindungen zu anderen Menschen.

Die genaue Anzahl solcher Beziehungen ist unbekannt. Dunbar selbst schlug vor, dass eine Person nicht mehr als 150 solcher Verbindungen bequem unterstützen kann. Er beschrieb es in einem sozialeren Kontext: "Die Anzahl der Personen, denen Sie ohne Einladung zum gemeinsamen Trinken ohne zu zögern beitreten, wenn Sie ihnen versehentlich an der Bar begegnen." Schätzungen dieser Zahl variieren normalerweise zwischen 100 und 250.

Wie bei stabilen Beziehungen zwischen Personen erfordert die Aufrechterhaltung der Beziehung eines Programmierers zum Code viel Aufwand. Wenn wir mit großen und komplexen Projekten oder mit dem Besitz vieler kleiner Projekte konfrontiert werden, verlassen wir uns auf bestimmte Vereinbarungen, Richtlinien und Verfahren. Es ist wichtig, die Dunbar-Nummer nicht nur bei der Erhöhung der Mitarbeiterzahl zu berücksichtigen, sondern auch bei der Bestimmung des Teamumfangs oder des Zeitpunkts, zu dem das System zusätzliche Tools zur Modellierung und Automatisierung der Logistik erwerben sollte. Im technischen Kontext ist dies die Anzahl der Projekte (oder die normalisierte Komplexität eines Projekts), für die Sie sicher in die Code-Support-Gruppe aufgenommen würden.

Goll Gesetz

Ein funktionierendes komplexes System kam notwendigerweise von einem funktionierenden einfachen System. Ein komplexes System, das von Grund auf neu entwickelt wurde, funktioniert nie und es ist unmöglich, es so zu reparieren, dass es funktioniert. Sie müssen mit einem einfachen Arbeitssystem neu beginnen.

Golls Gesetz legt nahe, dass Versuche, ein sehr komplexes System zu entwickeln, höchstwahrscheinlich scheitern werden. Systeme mit hoher Komplexität werden selten in einer Sitzung erstellt - sie entstehen aus einfacheren.

Ein klassisches Beispiel ist ein weltweites Netzwerk. Im gegenwärtigen Zustand ist es ein System von hoher Komplexität. Es wurde jedoch ursprünglich als eine einfache Möglichkeit zum Austausch von Inhalten zwischen Institutionen identifiziert. Sie hat diese Ziele sehr erfolgreich gemeistert und sich im Laufe der Zeit zu einem komplexeren entwickelt.

Goodhart-Gesetz

Jedes beobachtete statistische Muster neigt dazu, zusammenzubrechen, sobald Druck auf es ausgeübt wird, um es zu kontrollieren.

Es wird auch oft formuliert als:

Wenn eine Maßnahme zum Ziel wird, ist sie keine gute Maßnahme mehr.
Marilyn Strain

Das Gesetz sieht vor, dass eine Optimierung aufgrund bestimmter Maßnahmen zur Abschreibung dieser Maßnahmen führen kann. Übermäßig selektive Messungen (KPIs), die blind auf einen Prozess angewendet werden, führen zu Verzerrungen. Menschen bemühen sich, den Prozess lokal zu optimieren und das System zu „täuschen“, um eine bestimmte Metrik zu erfüllen, anstatt auf das globale Ergebnis ihrer Handlungen zu achten.

Beispiele:

Tests ohne Ansprüche erfüllen die Erwartungen an die Codeabdeckung, obwohl eine solche Metrik erstellt wurde, damit das Programm gut getestet wurde.
Die Beurteilung der Effektivität des Entwicklers anhand der Anzahl der zum Projekt beigetragenen Zeilen führt zu einer ungerechtfertigten Aufblähung des Codes.

Hanlon Rasiermesser

Führen Sie niemals Bosheit auf das zurück, was vollständig durch Dummheit erklärt wird.

Das Prinzip besagt, dass Handlungen, die zu einem negativen Ergebnis führen, nicht mit schlechten Absichten durchgeführt werden dürfen. Das negative Ergebnis ist eher darauf zurückzuführen, dass diese Maßnahmen und ihre Folgen nicht gut verstanden wurden.

Hofstaders Gesetz

Die Ausführung einer Aufgabe dauert immer länger als erwartet, auch wenn Sie das Gesetz von Hofstader berücksichtigt haben.

Möglicherweise stoßen Sie auf Verweise auf dieses Gesetz, wenn Sie Schätzungen der für ein Projekt aufgewendeten Zeit vornehmen. Auf dem Gebiet der Softwareentwicklung scheint es eine Binsenweisheit zu sein, dass wir die für die Fertigstellung des Projekts benötigte Zeit nicht sehr gut abschätzen können.

Zitat aus dem Buch " Gödel, Escher, Bach: Diese endlose Girlande ".

Hutber-Gesetz

Verbesserung ist gleichbedeutend mit Zerstörung.

Dieses Gesetz besagt, dass die Verbesserung eines Teils des Systems zur Zerstörung anderer Teile führt oder andere Arten der Zerstörung verbirgt, was im Allgemeinen zu einer Verschlechterung des Systems im Vergleich zu seinem aktuellen Zustand führt.

Beispielsweise kann das Verringern der Antwortzeit in einem bestimmten Teil des Systems zu einer Erhöhung seines Durchsatzes und infolgedessen zu Problemen mit der Kapazität irgendwo im Pfad des Anforderungsflusses führen, die sich auf ein anderes Subsystem auswirken können.

Der Kreislauf von Hype und Amars Gesetz

Wir neigen dazu, die Auswirkungen der Technologie kurzfristig zu überschätzen und langfristig zu unterschätzen.

Der Hype-Zyklus ist eine Visualisierung der Begeisterung und Entwicklung der Technologie im Laufe der Zeit, die ursprünglich von Gartner entwickelt wurde. Die Grafik zeigt dies am besten:

Nach dem Aufkommen der Technologie erreicht ihre Popularität den Höhepunkt aufgeblähter Erwartungen, taucht dann in die Höhle der Enttäuschung ein, steigt entlang des Abhangs der Erleuchtung und erreicht das Plateau der Produktivität

Kurz gesagt, der Zyklus argumentiert, dass in der Regel eine Quelle der Begeisterung für neue Technologien und ihre möglichen Folgen entsteht. Teams sind oft schnell von diesen Technologien abhängig und von den Ergebnissen oft enttäuscht. Vielleicht liegt dies daran, dass die Technologie noch nicht ausreichend entwickelt ist oder die Methoden für ihre Anwendung noch nicht durchdacht sind. Nach einer gewissen Zeit nehmen die Fähigkeiten der Technologie zu und die Anzahl der praktischen Anwendungen wächst, wonach die Teams endlich produktiv werden können.

Hirams Gesetz

Wenn Sie eine ausreichende Anzahl von API-Benutzern erreichen, spielt es keine Rolle, welche Funktionen Sie allen versprochen haben: Für alle möglichen Funktionen des Verhaltens Ihres Systems gibt es einen Benutzer, der davon abhängt.

Hirams Gesetz postuliert, dass, wenn Ihre API genügend Benutzer hat, es einen Benutzer geben wird, der von einem der möglichen Verhaltensweisen Ihres Systems abhängig ist (nicht einmal im öffentlichen Auftrag beschrieben). Ein triviales Beispiel wären nicht funktionierende API-Funktionen wie die Antwortzeit. Ein subtileres Beispiel sind Verbraucher, die sich darauf verlassen, die Art des Fehlers zu bestimmen, indem sie die Regex-Funktion auf ihre Beschreibung anwenden. Selbst wenn der öffentliche Vertrag nichts über den Inhalt der Nachricht aussagt und impliziert, dass Benutzer den Fehlercode verwenden müssen, entscheiden sich einige von ihnen möglicherweise für die Verwendung der Nachricht, und durch Ändern der Nachricht wird die API für diese Benutzer beschädigt.

Kernigan Law

Das Debuggen von Code ist zweimal schwieriger als das Schreiben. Wenn Sie also Code bis an die Grenzen Ihrer geistigen Fähigkeiten schreiben, verfügen Sie per Definition nicht über genügend Intelligenz, um ihn zu debuggen.

Kernigans Gesetz ist nach Brian Kernigan benannt und stammt aus einem Buch, das er und Plauger geschrieben haben: "Elemente eines Programmierstils".

Jeder weiß, dass das Debuggen von Code zweimal schwieriger ist als das Schreiben. Wenn Sie also beim Schreiben von Code alle Ihre mentalen Anstrengungen unternehmen, wie werden Sie ihn dann debuggen?

Obwohl das Gesetz eine Übertreibung ist, behauptet es, dass es besser ist, einfachen Code als komplexen zu verwenden, da das Debuggen von Problemen, die in komplexem Code auftreten, zu teuer oder sogar unmöglich sein kann.

Metcalfs Gesetz

In der Netzwerktheorie wächst der Nutzen eines Netzwerks ungefähr als Quadrat der Anzahl seiner Benutzer.

Das Gesetz basiert auf der Anzahl möglicher paarweiser Verbindungen innerhalb des Systems und ist eng mit dem Reedschen Gesetz verbunden. Odlyzhko und andere argumentierten, dass die Gesetze von Reed und Metcalf den Wert des Systems übertrieben hätten, ohne die Einschränkungen der menschlichen Fähigkeit zu berücksichtigen, das Netzwerk zu verstehen. siehe Dunbar Nummer.

Moores Gesetz

Die Anzahl der auf einem integrierten Schaltkreischip platzierten Transistoren verdoppelt sich ungefähr alle 24 Monate.

Moores Vorhersage , die oft verwendet wurde, um die enorme Geschwindigkeit der Verbesserung der Halbleiter- und Chipherstellungstechnologien zu demonstrieren, war überraschend genau und funktionierte von den 1970er bis Ende der 2000er Jahre. In den letzten Jahren hat sich der Trend insbesondere aufgrund der physikalischen Einschränkungen der Miniaturisierung von Bauteilen leicht verändert. Parallelisierungsfortschritte und möglicherweise revolutionäre Veränderungen in der Halbleitertechnologie und in Quantencomputern können jedoch dazu führen, dass das Mooresche Gesetz für die nächsten Jahrzehnte gültig bleibt.

Murphys Gesetz

Alles, was schief gehen kann, wird schief gehen.

Murphys Gesetz, verfasst von Edward A. Murphy, postuliert, dass alles, was schief gehen kann, notwendigerweise schief gehen wird.

Dieses Sprichwort wird oft von Entwicklern verwendet. Manchmal passieren unerwartete Dinge während der Entwicklung, des Testens oder sogar in der Produktion. Es kann mit dem Gesetz der Gemeinheit in Verbindung gebracht werden, das in Großbritannien häufiger angewendet wird [tatsächlich ist es auch in Russland bekannt / ca. übersetzt.]:

Wenn etwas schief gehen kann, wird es passieren und im schlimmsten Moment.

Normalerweise werden diese "Gesetze" in einem humorvollen Sinne verwendet. Phänomene wie Bestätigungsverzerrungen und systematische Auswahlfehler können jedoch dazu führen, dass die Menschen übermäßig an diesen Gesetzen interessiert sind (in den meisten Fällen bemerkt dies niemand, wenn alles so funktioniert, wie es sollte, aber Fehler sind auffälliger und ziehen mehr Diskussionen an).

Ockhams Rasiermesser

Sie sollten die Dinge nicht unnötig multiplizieren.

Occams Rasiermesser behauptet, dass von den wenigen möglichen Lösungen die Lösung, die die geringste Menge an Konzepten und Annahmen enthält, am wahrscheinlichsten ist. Diese Lösung ist die einfachste und löst nur das gegebene Problem, ohne zufällige Schwierigkeiten und mögliche negative Folgen mit sich zu bringen.

Parkinson-Gesetz

Die Arbeit füllt die ihr zugewiesene Zeit aus.

Im ursprünglichen Kontext basierte das Gesetz auf der Untersuchung der Bürokratie. Pessimistisch kann es auf die Softwareentwicklung angewendet werden, vorausgesetzt, das Team arbeitet ineffizient, bis sich die Projektfrist nähert, und es wird dann eilig sein, es pünktlich zu liefern, was das spezifische Enddatum eher willkürlich macht.

Wenn Sie es mit dem Gesetz von Hofstader kombinieren, erhalten Sie eine noch pessimistischere Sichtweise: Die Arbeit wird erweitert, bis sie die gesamte für ihre Fertigstellung erforderliche Zeit ausfüllt und dennoch mehr als erwartet dauert.

Der Effekt einer vorzeitigen Optimierung

Vorzeitige Optimierung ist die Wurzel allen Übels.

In Donald Knuths Arbeit „Strukturierte Programmierung mit GoTo“ schrieb er: „Programmierer verbringen viel Zeit damit, über die Geschwindigkeit der Ausführung unkritischer Teile von Programmen nachzudenken und sich Sorgen zu machen, und der Versuch, sie effektiver zu machen, wirkt sich stark negativ aus, wenn Sie über das Debuggen und Unterstützen nachdenken. Wir müssen die unwichtige Effizienz von 97% der Zeit vergessen: Vorzeitige Optimierung ist die Wurzel aller Übel. In kritisch kritischen 3% der Fälle sollten wir jedoch unsere Chance nicht verpassen. “

Vorzeitige Optimierung kann jedoch auch als Versuch beschrieben werden, etwas zu optimieren, bevor wir verstehen, was wir tun müssen.

Patt Law

Der Technologiesektor wird von zwei Arten von Menschen dominiert: denen, die verstehen, dass sie nicht kontrollieren, und denen, die kontrollieren, was sie nicht verstehen.

Für das Gesetz sollte Patta Patta oft schließen:

In jeder technischen Hierarchie entwickelt sich im Laufe der Zeit eine Umkehrung der Kompetenz.

Diese Aussagen deuten darauf hin, dass es aufgrund unterschiedlicher Auswahlkriterien und Gruppenorganisationstrends immer eine bestimmte Anzahl erfahrener Personen auf den Arbeitsebenen der technischen Organisation geben wird, und es wird immer Personen auf der Führungsebene geben, die keine Ahnung von der Komplexität und den Problemen der von ihnen verwalteten Arbeit haben.

Es ist jedoch hervorzuheben, dass solche Gesetze eine sehr grobe Verallgemeinerung darstellen und möglicherweise für einige Arten von Organisationen gelten und für andere nicht.

Reeds Gesetz

Der Nutzen großer Netzwerke, insbesondere sozialer Netzwerke, wächst exponentiell mit dem Wachstum der Netzwerkgröße.

Dieses Gesetz basiert auf der Graphentheorie, bei der der Nutzen als Anzahl möglicher Untergruppen skaliert und schneller wächst als die Anzahl der Teilnehmer oder mögliche paarweise Verbindungen. Odlyzhko und andere argumentierten, dass die Gesetze von Reed und Metcalf den Wert des Systems übertrieben hätten, ohne die Einschränkungen der menschlichen Fähigkeit zu berücksichtigen, das Netzwerk zu verstehen. siehe Dunbar Nummer.

Das Gesetz der Erhaltung der Komplexität (Tesler-Gesetz)

Das Gesetz besagt, dass das System eine gewisse Komplexität aufweist, die nicht reduziert werden kann.

Ein Teil der Komplexität des Systems kann unbeabsichtigt auftreten. Dies ist das Ergebnis einer schlechten Struktur, von Fehlern oder einer erfolglosen Modellierung des zu lösenden Problems. Unbeabsichtigte Komplexität kann reduziert oder beseitigt werden. Einige Arten von Komplexität sind jedoch eine wesentliche Folge der Komplexität der Aufgabe selbst. Diese Komplexität kann verschoben, aber nicht beseitigt werden.

Eines der interessanten Elemente dieses Gesetzes ist die Annahme, dass selbst mit der Vereinfachung des gesamten Systems seine interne Komplexität nicht abnimmt, sondern an den Benutzer geht, der es schwerer hat, sich zu verhalten.

Das Gesetz der fließenden Abstraktionen

Alle nicht trivialen Abstraktionen unterliegen einem gewissen Fluss.

Dieses Gesetz besagt, dass Abstraktionen, die normalerweise in der IT verwendet werden, um die Arbeit mit komplexen Systemen zu vereinfachen, in bestimmten Situationen auslaufen und die Elemente der ihnen zugrunde liegenden Systeme nach oben fließen lassen, weshalb sich die Abstraktion unvorhersehbar verhält.

Ein Beispiel ist das Herunterladen einer Datei und das Lesen ihres Inhalts. Die Dateisystem-API ist eine Abstraktion von Kernelsystemen niedrigerer Ebene, die selbst eine Abstraktion der physischen Prozesse sind, die mit dem Ändern von Daten auf einer Magnetplatte (oder in einem SSD-Flash-Speicher) verbunden sind. In den meisten Fällen funktioniert eine Abstraktion, die eine Datei als Strom von Binärdaten darstellt. Das sequentielle Lesen von Daten von einer Magnetplatte erfolgt jedoch schneller als der zufällige Zugriff darauf, SSDs haben jedoch keine derartigen Probleme. Sie müssen die Details verstehen, die in der Tiefe liegen, um diese Fälle zu behandeln (z. B. sind Indexdatenbankdateien so strukturiert, dass die Zeit für den wahlfreien Zugriff verkürzt wird), wenn die Abstraktion ein Leck an Implementierungsdetails enthält, über die der Entwickler Bescheid wissen muss.

Das obige Beispiel kann beim Hinzufügen neuer Abstraktionen komplizierter werden. Unter Linux können Sie über das Netzwerk auf Dateien zugreifen, diese werden jedoch lokal als "normal" angezeigt. Diese Abstraktion tritt bei Netzwerkproblemen aus. Wenn der Entwickler sie als „normal“ behandelt und nicht berücksichtigt, dass sie anfällig für Probleme mit Verzögerungen und Netzwerkfehlern sind, ist seine Lösung suboptimal und fehlerhaft.

In dem Artikel, der das Gesetz beschreibt, wird angenommen, dass eine übermäßige Abhängigkeit von Abstraktionen in Verbindung mit einem schlechten Verständnis der zugrunde liegenden Prozesse in einigen Fällen sogar den Prozess der Problemlösung erschwert.

Beispiele: Langsamer Start von Photoshop. Ich bin auf dieses Problem gestoßenin der Vergangenheit. Photoshop wurde sehr langsam gestartet, manchmal dauerte es einige Minuten. Anscheinend bestand das Problem darin, dass beim Start standardmäßig Informationen über den aktuellen Drucker gelesen werden. Wenn dieser Drucker jedoch ein Netzwerkdrucker ist, kann dies extrem lange dauern. Die Abstraktion, nach der der Netzwerkdrucker dem lokalen ähnlich ist, verursachte dem Benutzer Probleme bei schlechter Kommunikation.

Gesetz der Trivialität

Das Gesetz besagt, dass Gruppen viel mehr Zeit und Aufmerksamkeit für die Erörterung kosmetischer oder trivialer Fragen aufwenden als für ernsthafte und umfassende.

Ein Beispiel ist in der Regel die Arbeit eines Ausschusses, der Pläne für ein Kernkraftwerk genehmigt, in dem die Struktur des Fahrradabstellplatzes meistens erörtert wird, als die wichtigeren Fragen bei der Gestaltung der Station selbst. Es kann schwierig sein, einen wertvollen Beitrag zur Diskussion sehr großer und komplexer Themen zu leisten, ohne über umfassende Kenntnisse zu diesem Thema zu verfügen. Die Leute möchten jedoch für wertvolle Kommentare zur Kenntnis genommen werden. Ab hier entsteht die Tendenz, sich auf kleine Details zu konzentrieren, über die leicht zu sprechen ist, die aber für das gesamte Projekt nicht unbedingt wichtig sind.

Aus dem oben angegebenen fiktiven Beispiel entstand der Begriff „Fahrradschuppen-Effekt“, der den Zeitverlust bei der Erörterung trivialer Details beschreibt. Es gibt einen ähnlichen Begriff, "Yak-Haarschnitt", der eine scheinbar nicht verwandte Aktivität beschreibt, die Teil einer langen Kette notwendiger Vorbereitungsschritte ist.

Unix-Philosophie

Die Unix-Philosophie lautet, dass Softwarekomponenten klein sein und sich darauf konzentrieren sollten, eine bestimmte Aufgabe gut zu erledigen. Dies erleichtert den Prozess des Aufbaus von Systemen, indem aus kleinen, einfachen und genau definierten Modulen rekrutiert wird, anstatt große, komplexe, multifunktionale Programme zu verwenden.

Moderne Praktiken wie die „Microservice-Architektur“ können als Anwendung dieser Philosophie angesehen werden. Die Services sind klein und konzentrieren sich auf eine bestimmte Aufgabe, sodass Sie aus einfachen Bausteinen ein komplexes Verhalten erstellen können.

Spotify-Modell

Der Ansatz zur Teamstruktur und -organisation, den Spotify fördert . In diesem Modell sind Teams nach Programmfunktionen organisiert, nicht nach Technologie.

Das Modell fördert auch die Konzepte von Stämmen, Gilden, Zweigen - andere Komponenten der Organisationsstruktur.

Wadlers Gesetz

Beim Entwerfen einer Sprache ist die Gesamtzeit, die für die Erörterung eines Features aus dieser Liste aufgewendet wird, proportional zur Potenz der Positionsnummer dieses Features in der Liste.
0. Semantik.
1. Die Syntax.
2. Lexikalische Syntax.
3. Die lexikalische Syntax von Kommentaren.

Das heißt, für jede Stunde, die für die Semantik aufgewendet wird, werden 8 Stunden für die Syntax von Kommentaren aufgewendet.

Wie das Gesetz der Trivialität postuliert Wadlers Gesetz , dass beim Entwerfen einer Sprache der Zeitaufwand für Sprachstrukturen im Vergleich zur Bedeutung dieser Strukturen unverhältnismäßig hoch ist.

Wheatons Gesetz

Sei keine Ziege.

Dieses präzise, einfache und umfassende Gesetz, das von Will Wheatan formuliert wurde, zielt darauf ab, die Harmonie und den Respekt innerhalb einer professionellen Organisation zu erhöhen. Es kann in Gesprächen mit Kollegen, bei der Durchführung einer Expertenbewertung des Kodex, bei der Suche nach Einwänden gegen andere Gesichtspunkte, bei der Kritik und allgemein bei der professionellen Kommunikation zwischen Personen verwendet werden.

Prinzipien

Grundsätze werden am häufigsten mit Ratschlägen zur Gestaltung von Programmen in Verbindung gebracht.

Dilbert-Prinzip

In Unternehmen besteht die Tendenz, inkompetente Mitarbeiter zu Managern zu machen, um sie aus dem Arbeitsprozess auszuschließen.

Managementkonzept, entwickelt von Scott Adams (Schöpfer der Dilbert-Comics), inspiriert von Peters Prinzip. Nach dem Dilbert-Prinzip werden Mitarbeiter, die nicht als kompetent angesehen werden konnten, zu Managern befördert, um den möglichen Schaden für das Unternehmen zu begrenzen. Adams erklärte dieses Prinzip erstmals 1995 in einem Artikel für das Wall Street Journal und beschrieb es dann ausführlich in seinem 1996 erschienenen Buch The Dilbert Principle.

Pareto-Prinzip (80/20-Regel)

Zum größten Teil ist alles im Leben ungleich verteilt.

Das Pareto-Prinzip besagt, dass in einigen Fällen ein kleinerer Teil der Investition für die meisten Ergebnisse verantwortlich ist:

80% des Programms können in 20% der Zeit geschrieben werden (und die schwierigsten 20% nehmen die restlichen 80% der Zeit in Anspruch).
20% des Aufwands ergeben 80% des Ergebnisses.
20% der Arbeit machen 80% des Gewinns aus.
20% der Fehler führen zu 80% der Programmabstürze.
20% der Funktionen werden in 80% der Fälle verwendet.

In den 1940er Jahren begann Joseph Juran, ein amerikanischer Ingenieur rumänischer Herkunft, der oft als Vater des Qualitätsmanagements bezeichnet wird, das Pareto-Prinzip auf Qualitätsprobleme anzuwenden.

Auch dieses Prinzip ist in der Regel 80/20 das Gesetz des wichtigsten Kleinen, das Prinzip des Mangels an Faktoren, bekannt.

Beispiele: Im Jahr 2002 berichtete Microsoft, dass nach der Behebung von 20% der häufigsten Fehler 80% der damit verbundenen Probleme und Abstürze von Windows und Office behoben werden.

Peter-Prinzip

Im hierarchischen System hat jeder Einzelne die Tendenz, auf das Niveau seiner Inkompetenz aufzusteigen.

Das von Lawrence Johnston Peter entwickelte Managementkonzept stellt fest, dass Menschen, die gute Arbeit leisten, befördert werden, bis sie ein Niveau erreichen, mit dem sie nicht mehr fertig werden („Inkompetenzniveau“). Da sie hoch genug geklettert sind, ist es bereits weniger wahrscheinlich, dass sie entlassen werden (es sei denn, sie erzeugen einen vollständigen Unsinn), sodass sie in dieser Position bleiben, für die ihnen die erforderlichen Fähigkeiten fehlen, da ihre Verhaltensfähigkeiten in der Organisation nicht unbedingt übereinstimmen mit den Fähigkeiten, die für eine erfolgreiche Arbeit in dieser Position erforderlich sind.

Dieses Prinzip ist besonders interessant für Ingenieure, die mit rein technischen Rollen arbeiten, aber häufig eine Karriere aufbauen, die zum Management anderer Ingenieure führt - was völlig andere Fähigkeiten erfordert.

Das Prinzip der Zuverlässigkeit (Postelsches Gesetz)

Seien Sie konservativ in Bezug auf Ihre Aktivitäten und liberal in Bezug auf die Beiträge anderer.

Dieses Prinzip wird häufig bei der Entwicklung von Serveranwendungen angewendet. Ihm zufolge sollten die Daten, die Sie an andere senden, so klein wie möglich und so gut wie möglich sein, um dem Standard zu entsprechen. Sie müssen jedoch selbst nicht vollständig standardisierte Daten als Eingabe akzeptieren, wenn Sie damit umgehen können.

Der Zweck des Prinzips besteht darin, zuverlässige Systeme zu erstellen, die schlecht formatierte Daten verarbeiten können, deren Bedeutung noch verstanden werden kann. Der Empfang nicht standardmäßiger Eingabedaten kann jedoch Konsequenzen im Zusammenhang mit einer Sicherheitsverletzung haben, insbesondere wenn der Empfang solcher Daten nicht gut getestet wurde.

Im Laufe der Zeit kann die Praxis, nicht standardisierte Daten zu empfangen, dazu führen, dass sich die Protokolle nicht mehr entwickeln, da diejenigen, die den Datenaustausch implementieren, sich auf die Liberalität der Programme verlassen und neue Funktionen schaffen.

SOLIDE

Das Akronym für die folgenden 5 Prinzipien:

S: Das Prinzip der Einzelverantwortung
O: Das offene / geschlossene Prinzip
L: Das Liskov-Substitutionsprinzip
I: Das Prinzip der Schnittstellentrennung [ Prinzip der Schnittstellentrennung]
D: Das

Prinzip der Abhängigkeitsinversion Dies sind die Schlüsselprinzipien der objektorientierten Programmierung. Solche Entwurfsprinzipien sollen Entwicklern helfen, Systeme zu erstellen, die einfacher zu warten sind.

Grundsatz der alleinigen Verantwortung

Jedes Objekt muss eine Verantwortung haben, und diese Verantwortung muss vollständig in der Klasse enthalten sein.

Das erste der Prinzipien von SOLID. Das Prinzip besagt, dass jedes Modul oder jede Klasse nur eines tun sollte. In der Praxis bedeutet dies, dass eine kleine, einzelne Änderung der Funktion eines Programms nur eine Änderung einer Komponente erfordern sollte. Um beispielsweise das Verfahren zum Überprüfen des Kennworts auf Komplexität zu ändern, muss das Programm nur an einer Stelle repariert werden.

Theoretisch gibt dies dem Code Zuverlässigkeit und vereinfacht seine Änderung. Die Tatsache, dass die zu ändernde Komponente die alleinige Verantwortung trägt, sollte bedeuten, dass es einfacher ist, diese Änderung zu testen. Das Ändern der Komponente zur Überprüfung der Kennwortkomplexität gegenüber dem vorherigen Beispiel sollte sich nur auf Funktionen auswirken, die sich auf die Kennwortkomplexität beziehen. Es ist viel schwieriger, darüber zu sprechen, was von einem Komponentenwechsel mit vielen Verantwortlichkeiten betroffen sein wird.

Das Prinzip der Offenheit / Nähe

Entitäten müssen für Erweiterungen geöffnet, für Änderungen jedoch geschlossen sein.

Das zweite der Prinzipien von SOLID. Das Prinzip besagt, dass Entitäten (Klassen, Module, Funktionen usw.) die Erweiterung ihres Verhaltens ermöglichen sollten, ihr aktuelles Verhalten jedoch nicht geändert werden sollte.

Ein hypothetisches Beispiel: Stellen Sie sich ein Modul vor, das ein Markdown-Markup-Dokument in ein HTML-Markup-Dokument verwandeln kann. Wenn das Modul so erweitert werden kann, dass es lernt, mit den neuen Funktionen des Markdown-Formats umzugehen, ohne seine internen Funktionen zu ändern, kann das Modul erweitert werden. Wenn das Modul die Verarbeitung der aktuellen Markdown-Funktionen nicht ändern kann, wird das Modul zur Änderung geschlossen.

Das Prinzip ist besonders eng mit der objektorientierten Programmierung verbunden, bei der Sie Objekte entwerfen können, die leicht zu erweitern sind. Sie sollten jedoch keine Objekte entwerfen, deren Innenräume sich unerwartet ändern.

Barbara Liskov Substitutionsprinzip

Es sollte möglich sein, den Typ durch einen Untertyp zu ersetzen, ohne das System zu beschädigen.

Das dritte der Prinzipien von SOLID. Das Prinzip besagt, dass, wenn eine Komponente von einem Typ abhängt, es möglich sein sollte, Untertypen dieses Typs zu verwenden, damit das System die Arbeit nicht verweigert oder keine Details dieses Untertyps benötigt.

Zum Beispiel haben wir eine Methode, die ein XML-Dokument aus einer Struktur liest, die eine Datei bezeichnet. Wenn die Methode die Basistypdatei verwendet, sollte die Funktion in der Lage sein, alles zu verwenden, was aus der Datei stammt. Wenn die Datei die umgekehrte Suche unterstützt und der XML-Parser diese Funktion verwendet, der abgeleitete Typ "Netzwerkdatei" jedoch nicht mit der umgekehrten Suche arbeitet, verstößt die "Netzwerkdatei" gegen dieses Prinzip.

Das Prinzip ist besonders eng mit der objektorientierten Programmierung verbunden, bei der Typhierarchien sehr sorgfältig modelliert werden müssen, um Verwirrung für den Systembenutzer zu vermeiden.

Prinzip der Schnittstellentrennung

Software-Entitäten sollten nicht von Methoden abhängen, die sie nicht verwenden.

Das vierte der Prinzipien von SOLID. Das Prinzip besagt, dass Verbraucher einer Komponente nicht von den Funktionen einer Komponente abhängen sollten, die sie nicht verwendet.

Zum Beispiel haben wir eine Methode, die ein XML-Dokument aus einer Struktur liest, die eine Datei bezeichnet. Es muss nur Bytes lesen und sich vorwärts oder rückwärts durch die Datei bewegen. Wenn diese Methode aufgrund von Änderungen in einer Dateistruktur, die nicht damit zusammenhängt, aktualisiert werden muss (z. B. aufgrund einer Aktualisierung des Zugriffssteuerungsmodells, das die Dateisicherheit darstellt), wird dieses Prinzip verletzt. Es ist besser, wenn die Datei die Schnittstelle "Suchbarer Stream" und die XML-Methode implementiert, um sie zu verwenden.

Das Prinzip ist besonders eng mit der objektorientierten Programmierung verbunden, bei der Schnittstellen, Hierarchien und abstrakte Typen verwendet werden, um Verbindungen zwischen Komponenten zu minimieren. Dieses Prinzip erzwingt die Verwendung der Ententypisierung , einer Methode, die explizite Schnittstellen eliminiert.

Prinzip der Abhängigkeitsinversion

Module der oberen Ebene sollten nicht von Modulen der unteren Ebene abhängen.

Fünftel der Prinzipien von SOLID. Das Prinzip besagt, dass Steuerungskomponenten höherer Ebenen die Details der Implementierung ihrer Abhängigkeiten nicht kennen sollten.

Zum Beispiel haben wir ein Programm, das Metadaten von einer Website liest. Vermutlich sollte die Hauptkomponente eine Komponente kennen, die den Inhalt einer Webseite herunterlädt, und eine Komponente, die Metadaten liest. Wenn wir das Prinzip der Abhängigkeitsinversion berücksichtigen, hängt die Hauptkomponente nur von der abstrakten Komponente ab, die Bytedaten empfängt, und wiederum von der abstrakten Komponente, die Metadaten aus dem Bytestrom lesen kann. Die Hauptkomponente weiß nichts über TCP / IP, HTTP, HTML usw.

Das Prinzip ist ziemlich kompliziert, da es die erwartete Abhängigkeit im System umkehrt. In der Praxis bedeutet dies auch, dass eine separate Steuerungskomponente die korrekte Implementierung abstrakter Typen gewährleisten muss (im vorherigen Beispiel muss der Metadatenleser der Komponente zum Herunterladen der Datei über HTTP und zum Lesen von Daten aus dem Meta-HTML-Tag bereitgestellt werden).

Wiederholen Sie sich nicht Prinzip

Jedes Wissen sollte eine eindeutige, konsistente und maßgebliche Darstellung innerhalb des Systems haben.

Wiederholen Sie sich nicht oder DRY hilft Entwicklern dabei, die Wiederholbarkeit von Code zu verringern und Informationen an einem Ort zu speichern. Es wurde 1999 von Andy Hunt und Dave Thomas in ihrem Buch Pragmatic Programmer erwähnt.

Das Gegenteil des DRY-Prinzips trocken] sollte das Prinzip von WET sein nass] - "Schreibe alles zweimal" oder "Wir tippen gerne" [Wir tippen gerne].

Wenn in der Praxis dieselben Informationen an zwei oder mehr Stellen in Ihnen dupliziert werden, verwenden Sie das DRY-Prinzip, indem Sie sie an einer Stelle zusammenführen und bei Bedarf wiederverwenden.

KISS-Prinzip

Halte es einfach, dumm [Nicht komplizieren, Dummkopf]

Das KISS-Prinzip besagt, dass die meisten Systeme besser funktionieren, wenn sie nicht kompliziert sind. Daher sollte Einfachheit ein zentrales Ziel bei der Entwicklung sein und unnötige Komplexität sollte vermieden werden. Es entstand 1960 in der US-Marine und wird dem Flugzeugdesigner Clarence Johnson zugeschrieben.

Es ist am besten, sich dies anhand eines Beispiels vorzustellen, als Johnson einem Team von Konstrukteuren einen kleinen Satz Werkzeuge gab und sie anwies, ein Flugzeug so zu entwerfen, dass ein durchschnittlicher Mechaniker es nur mit diesem Satz auf einem Schlachtfeld reparieren konnte. Dumm bezeichnet hier eher die Beziehung zwischen dem Zusammenbruch der Dinge und der Komplexität der Werkzeuge, die zur Reparatur zur Verfügung stehen, als die mentalen Fähigkeiten der Ingenieure.

YAGNI

Akronym für "Du wirst es nicht brauchen" [du wirst es nicht brauchen].

Implementieren Sie Funktionen immer nur dann, wenn Sie sie wirklich benötigen, und nicht, wenn Sie glauben, dass Sie sie in Zukunft benötigen.

Der Autor von Extreme Programming (XP) und das Buch „Installed Extreme Programming“, Ron Jeffries , schlagen vor, dass Entwickler nur die Funktionen implementieren sollten, die gerade benötigt werden, und nicht versuchen sollten, die Zukunft vorherzusagen, sondern die Funktionen implementieren sollten, die später möglicherweise benötigt werden.

Das Befolgen dieses Prinzips sollte die Menge an nicht verwendetem Code in der Datenbank sowie die Zeit- und Energieverschwendung für Funktionen reduzieren, die keine Vorteile bringen.

Missverständnisse des verteilten Rechnens

Auch als Irrtum des Netzwerk-Computing bekannt. Dies ist eine Liste von Annahmen in Bezug auf verteiltes Rechnen, die zu Softwarefehlern führen können. Dies sind die folgenden Annahmen:

Das Netzwerk ist zuverlässig.
Die Verzögerung ist Null.
Die Bandbreite ist endlos.
Das Netzwerk ist sicher.
Die Topologie ändert sich nicht.
Es gibt nur einen Administrator.
Die Versandkosten sind Null.
Das Netzwerk ist homogen.

Die ersten vier wurden 1991 von Bill Joy und Tom Lyon aufgelistet, und James Gosling klassifizierte sie zuerst als "Network Computing Misconceptions". Peter Deutsch fügte die 5., 6. und 7. Täuschung hinzu. In den späten 90ern fügte Gosling den 8. hinzu.

Eine Gruppe von Ingenieuren ließ sich von den damaligen Prozessen bei Sun Microsystems inspirieren.

Diese Fehler sollten bei der Entwicklung zuverlässigen Codes sorgfältig berücksichtigt werden. Jeder der Fehler kann zu einer falschen Logik führen, die die Realität und Komplexität verteilter Systeme nicht bewältigen kann.

Gesetze der Programmierung