1 Unix-Philosophie

Die Unix-Philosophie legt Wert auf die Praktikabilit?t, die auf reichhaltiger Erfahrung beruht, und ist nicht durch traditionelle Methoden oder Standards eingeschr?nkt. Dieses Wissen ist eher latent und halbinstinktiv. Das Wissen, das Unix-Programmierer durch Entwicklungserfahrung sammeln, kann anderen Programmierern zugute kommen.

(1) Jedes Programm sollte sich auf die Erledigung einer Aufgabe konzentrieren und bei einer neuen Aufgabe von vorne beginnen, um zu vermeiden, dass dem ursprünglichen Programm neue Funktionen hinzugefügt werden, was zu einer erh?hten Komplexit?t führt. (2) Unter der Annahme, dass die Ausgabe eines Programms zur Eingabe eines anderen Programms wird, stellen Sie sicher, dass die Ausgabe keine irrelevanten Informationen enth?lt, auch wenn das n?chste Programm noch nicht bekannt ist. (3) Testen Sie die entworfene und geschriebene Software so früh wie m?glich und verzichten Sie entschieden auf minderwertigen Code und schreiben Sie ihn neu. (4) Verwenden Sie Tools vor ineffizienten Hilfsmitteln, um die Belastung durch Programmieraufgaben zu verringern. Um Spitzenleistungen anzustreben, müssen Sie Tools sinnvoll nutzen.

2 Codierungsprinzipien

Die Essenz der Unix-Philosophie ist nicht nur das, was die Weisen mündlich vermittelten, sondern spiegelt sich vielmehr in ihren Praktiken und dem Design des Unix-Systems selbst wider. Diese Philosophie l?sst sich in einigen Kernpunkten zusammenfassen:

Wenn Sie zum ersten Mal Software-Engineering lernen, sollten Sie ein tiefes Verst?ndnis dieser Prinzipien haben. Obwohl die meisten Artikel diese Prinzipien f?rdern, mangelt es vielen Systemen an praktischen Werkzeugen und Traditionen, die Programmierer daran hindern, diese Prinzipien umzusetzen. Sie werden oft durch schlechte Tools, schlechtes Design, überarbeitung und redundanten Code behindert.

2.1 Modulprinzip: Einfache Schnittstellen nutzen, um einfache Komponenten zusammenzubauen

Der Kern der Programmierung ist die Bew?ltigung der Komplexit?t. Das Beheben von Fehlern nimmt den Gro?teil der Entwicklungszeit in Anspruch. Der Erfolg eines nutzbaren Systems ist mehr ein Ergebnis von Versuch und Irrtum als nur von Talent oder Designf?higkeiten.

Assemblersprache, kompilierte Sprache, Flussdiagramme, prozedurale Programmierung, strukturierte Programmierung, objektorientierte und Softwareentwicklungsmethoden werden überm??ig angepriesen. Sie erh?hen jedoch die Komplexit?t des Programms über die Verarbeitungsf?higkeiten des menschlichen Gehirns hinaus.

Um komplexe Software erfolgreich zu entwickeln, ist die Reduzierung der Gesamtkomplexit?t und die Kombination einfacher Module durch klare Schnittstellen von entscheidender Bedeutung. Dadurch bleibt das Problem auf einen bestimmten Teil beschr?nkt, was es einfacher macht, es zu verbessern, ohne das Ganze zu beeintr?chtigen.

2.2 Klarheitsprinzip: Klarheit ist besser als Klugheit

Schreiben Sie Code unter Berücksichtigung zukünftiger Wartungskomplexit?t und -kosten. Code sollte leicht lesbar und verst?ndlich sein, sodass er bei Bedarf von anderen oder Ihnen selbst problemlos ge?ndert und gepflegt werden kann.

In der Unix-Tradition gilt dieses Prinzip nicht nur für Codekommentare. Bei den Best Practices von Unix wird au?erdem Wert darauf gelegt, bei der Auswahl von Algorithmen und Implementierungen die zukünftige Skalierbarkeit zu berücksichtigen. Obwohl es verlockend sein mag, technische Komplexit?t und Verwirrung hinzuzufügen, um die Programmleistung geringfügig zu verbessern, ist dieser Ansatz den Gewinn nicht wert. Das liegt nicht nur daran, dass komplexer Code anf?llig für Fehler ist, sondern auch daran, dass er künftig schwieriger zu lesen und zu warten ist. Im Gegenteil, eleganter und klarer Code ist nicht nur stabiler, sondern auch für andere einfacher zu verstehen und zu ?ndern. Dies ist von entscheidender Bedeutung, insbesondere da Sie m?glicherweise die Person sind, die diesen Code in Jahren noch einmal ?ndern muss.

Machen Sie sich nie die Mühe, einen unbekannten Code dreimal zu entschlüsseln. M?glicherweise kommen Sie beim ersten Mal damit durch, aber wenn Sie feststellen, dass Sie es noch einmal neu interpretieren müssen – das erste Mal ist zu lange her und Sie k?nnen sich nicht mehr an die spezifischen Details erinnern – dann ist es an der Zeit, den Code auszukommentieren dass das dritte Mal relativ weniger schmerzhaft sein wird.

2.3 Kombinationsprinzip: Berücksichtigen Sie beim Entwerfen das Splei?en und Kombinieren

Wenn Programme nicht effektiv miteinander kommunizieren k?nnen, bleibt die Software unweigerlich in der Komplexit?t stecken.

In Bezug auf Eingabe und Ausgabe befürwortet die Unix-Tradition nachdrücklich die Verwendung einfacher, textueller, streamorientierter und ger?teunabh?ngiger Formate. Unter klassischem Unix verwenden die meisten Programme so weit wie m?glich die Form einfacher Filter, dh sie verarbeiten einen Eingabetextstrom in einen einfachen Textstrom als Ausgabe. Entgegen der landl?ufigen Meinung bevorzugen Unix-Programmierer diesen Ansatz nicht, weil sie grafische Benutzeroberfl?chen hassen, sondern weil es ?u?erst schwierig ist, mit Programmen zu interagieren, wenn sie keine einfachen Texteingabe- und -ausgabestr?me verwenden.

Textstr?me in Unix sind für Tools das, was Nachrichten für Objekte in einer objektorientierten Umgebung sind. Die Einfachheit der Textflussschnittstelle verbessert die Kapselung des Tools. Viele ausgefeilte prozessübergreifende Kommunikationsmethoden, wie z. B. Remote-Prozeduraufrufe, neigen dazu, zu viele Prozesse einzubeziehen.

Um ein Programm zusammensetzbar zu machen, ist es notwendig, die Programme voneinander unabh?ngig zu machen. Programme an einem Ende des Textstroms sollten m?glichst keine Rücksicht auf Programme am anderen Ende des Textstroms nehmen. Es sollte einfach sein, ein Programm an einem Ende durch ein v?llig anderes zu ersetzen, ohne das andere Ende überhaupt zu st?ren. Eine grafische Benutzeroberfl?che kann eine gute Sache sein. Bevor Sie eine grafische Benutzeroberfl?che erstellen, sollten Sie darüber nachdenken, ob Sie das komplexe interaktive Programm von dem Algorithmusprogramm trennen k?nnen, das die grobe Arbeit erledigt, und dann einen einfachen Befehl verwenden k?nnen Fluss- oder Anwendungsprotokoll, um alles miteinander zu kombinieren.

Bevor Sie ein anspruchsvolles Datenübertragungsformat konzipieren, müssen Sie vor Ort prüfen, ob ein einfaches Textdatenformat verwendet werden kann Interpretieren Sie den Datenstrom.

Wenn ein Programm auf natürliche Weise keine serialisierten, protokollbasierten Schnittstellen verwenden kann, besteht das richtige Unix-Design zumindest darin, so viele Programmierelemente wie m?glich in einer Reihe wohldefinierter APIs zu organisieren. Auf diese Weise k?nnen Anwendungen zumindest über Links aufgerufen oder verschiedene Schnittstellen entsprechend den Anforderungen verschiedener Aufgaben zusammengefügt werden.

2.4 Trennungsprinzip: Trennung von Strategien von Mechanismen, Trennung von Schnittstellen von Motoren

Strategie und Mechanismus ?ndern sich in unterschiedlichen Zeitskalen, und die Strategie ?ndert sich viel schneller als der Mechanismus. Die Kombination von Strategie und Mechanismus hat zwei negative Auswirkungen: Erstens wird die Strategie starr und l?sst sich nur schwer an ver?nderte Benutzerbedürfnisse anpassen. Zweitens bedeutet dies auch, dass jede ?nderung der Strategie wahrscheinlich den Mechanismus ins Wanken bringt. Im Gegenteil reicht es m?glicherweise nicht aus, diese beiden Faktoren zu beseitigen, um den Mechanismus bei der Erforschung neuer Strategien zu durchbrechen. Darüber hinaus ist es einfacher, bessere Tests für den Mechanismus zu schreiben.

Eine M?glichkeit, das Strippen zu erreichen, besteht darin, die Anwendung in Front-End- und Back-End-Prozesse zu unterteilen, die über ein dediziertes Anwendungsprotokoll auf der oberen Schicht des Sockets zusammenarbeiten und kommunizieren k?nnen. Front-End-Implementierungsstrategie, Back-End-Implementierungsmechanismus. Verglichen mit der Gesamtimplementierung, die nur einen einzigen Prozess verwendet, reduziert dieses doppelseitige Design die Gesamtkomplexit?t erheblich und soll Fehler reduzieren, wodurch die Lebenszykluskosten des Programms gesenkt werden.

2.5 Prinzip der Einfachheit: Das Design sollte einfach und die Komplexit?t so gering wie m?glich sein

Druck aus vielen Aspekten macht das Programm oft komplizierter (wodurch das Programm teurer wird und mehr Fehler aufweist). Einer der Belastungen kommt von technischer Eitelkeit. Programmierer sind schlau und oft stolz auf ihre F?higkeit, mit komplexen Dingen und abstrakten Konzepten zu spielen, und das zu Recht. Aus diesem Grund konkurrieren sie oft mit ihren Kollegen darum, wer an den kompliziertesten und sch?nsten Dingen basteln kann. Ihre Designf?higkeiten übersteigen ihre Implementierungs- und Debugging-F?higkeiten bei weitem, und das Ergebnis ist teurer Ausschuss.

?Kompliziert sch?ne Dinge“ klingt wie ein Widerspruch. Unix-Programmierer konkurrieren miteinander darum, wer ?einfach und sch?n“ sein kann. Obwohl dies in diesen Regeln nur implizit enthalten ist, lohnt es sich, es ?ffentlich zu erw?hnen und hervorzuheben.

Zumindest in der Welt der kommerziellen Software ergibt sich eine überm??ige Komplexit?t oft aus Projektanforderungen, und diese Anforderungen basieren oft auf Verkaufsgespr?chen und nicht auf Kundenbedürfnissen und dem, was die Software tats?chlich leisten kann. Viele gute Designs werden durch eine gro?e ?Feature-Liste“ zerst?rt, die für das Marketing erforderlich ist, aber tats?chlich werden diese Features fast nie genutzt. Dann beginnt ein Teufelskreis, um ausgefallener zu sein als andere, indem man selbst noch ausgefallener wird. Bald wurde Bloat zum Industriestandard. Jeder verwendete aufgebl?hte Software mit so vielen Fehlern, dass selbst Softwareentwickler es nicht wagten, sie ernst zu nehmen.

Die einzige M?glichkeit, diese Fallstricke zu vermeiden, besteht darin, eine alternative Softwarekultur zu f?rdern, in der Einfachheit Sch?nheit bedeutet. Dies ist eine Ingenieurstradition, die Wert auf einfache L?sungen legt, immer versucht, ein Programmsystem in kleine Teile zu zerlegen, die zusammenarbeiten k?nnen, und sich instinktiv jedem Versuch widersetzt, ein Programm mit zu vielen Spielereien zu besch?nigen.

2.6 Prinzip der Geizigkeit: Schreiben Sie keine riesigen Programme, es sei denn, es gibt keinen anderen Weg

?Gro?“ hat zwei Bedeutungen: gro?e Gr??e und hohe Komplexit?t. Je gr??er das Programm, desto schwieriger ist die Wartung. Die Schwierigkeit, sich von etwas zu trennen, dessen Erstellung viel Mühe erforderte, führt zu einer Verschwendung von Investitionen in ein riesiges Programm, das zum Scheitern verurteilt ist oder nicht die beste L?sung darstellt. Vermeiden Sie unn?tigen Code und Logik und halten Sie Ihren Code schlank.

2.7 Transparenzprinzip: Design sollte zur überprüfung und Fehlerbehebung sichtbar sein

Da das Debuggen oft drei Viertel oder mehr der Entwicklungszeit in Anspruch nimmt, lohnt es sich, am Anfang etwas mehr Arbeit zu leisten, um sp?ter den Debugging-Aufwand zu reduzieren. Eine wirksame M?glichkeit, den Debugging-Arbeitsaufwand zu reduzieren, besteht darin, beim Entwurf vollst?ndig auf Transparenz und Sichtbarkeit zu achten.

Transparenz von Softwaresystemen bedeutet, dass Sie auf einen Blick sehen k?nnen, was die Software tut und wie sie es tut. Sichtbarkeit bedeutet, dass ein Programm seinen internen Zustand überwachen und anzeigen kann, sodass das Programm nicht nur gut l?uft, sondern auch gesehen werden kann, auf welche Weise es l?uft.

Wenn diese Anforderungen beim Entwurf vollst?ndig berücksichtigt werden, bringt dies Vorteile für den gesamten Projektprozess. Die Einstellung von Debugging-Optionen sollte nicht nachtr?glich erfolgen, sondern zu Beginn des Entwurfs berücksichtigt werden. Das Programm sollte nicht nur seine Korrektheit nachweisen k?nnen, sondern auch Nachzügler über die Probleml?sung des ursprünglichen Entwicklers informieren k?nnen Denkmodell.

Wenn ein Programm seine Korrektheit nachweisen m?chte, sollte es ein Eingabe- und Ausgabeformat verwenden, das einfach genug ist, um sicherzustellen, dass leicht überprüft werden kann, ob die Beziehung zwischen gültiger Eingabe und korrekter Ausgabe korrekt ist. Aus Gründen der Transparenz und Sichtbarkeit sollte auch eine einfache Schnittstelle gef?rdert werden, um anderen Programmen die Bedienung zu erleichtern, insbesondere Testüberwachungstools und Debugging-Skripten. Folgen Sie dem ?ffentlichen WeChat-Konto [Embedded System]

2.8 Robustheitsprinzip: Robustheit entsteht durch Transparenz und Einfachheit

Die Robustheit der Software bedeutet, dass die Software nicht nur unter normalen Umst?nden gut l?uft, sondern auch unter unerwarteten Bedingungen, die jenseits aller Vorstellungskraft liegen.

Die meisten Softwareprogramme vertragen keine Unebenheiten und weisen viele Probleme auf, weil sie zu komplex und schwierig sind, alles zu berücksichtigen. Wenn Sie die Logik eines Programms nicht richtig verstehen, k?nnen Sie nicht sicher sein, dass es korrekt ist, und Sie k?nnen es nicht beheben, wenn etwas schief geht. Der Weg, ein Programm robust zu machen, besteht darin, die interne Logik des Programms leichter verst?ndlich zu machen. Dafür gibt es im Wesentlichen zwei M?glichkeiten: Transparenz und Einfachheit.

Im Hinblick auf die Robustheit ist es auch wichtig, beim Design darauf zu achten, dass es extremen Belastungen standh?lt. Bei abnormalen Eingaben besteht eine sehr wichtige Strategie zur Gew?hrleistung der Robustheit der Software darin, Sonderf?lle im Code zu vermeiden. Fehler sind normalerweise im Code verborgen, der Sonderf?lle behandelt, und im Code, der die interaktiven Operationen verschiedener Sondersituationen abwickelt .

Durch die Transparenz der Software k?nnen Sie auf einen Blick erkennen, was vor sich geht. Ein Programm ist einfach, wenn ?was vor sich geht“ nicht komplex ist, das hei?t, wenn alle m?glichen Szenarien abgeleitet werden k?nnen, ohne sich den Kopf zu zerbrechen. Je einfacher und transparenter das Programm ist, desto robuster ist es.

Modularisierung (einfacher Code, einfache Schnittstelle) ist eine M?glichkeit, Programme zu organisieren, um pr?zisere Ziele zu erreichen.

2.9 Darstellungsprinzip: Wissen in Daten überlagern, um eine einfache und robuste Logik zu erreichen

Daten sind einfacher zu kontrollieren als Programmierlogik. Beim Design sollte die Komplexit?t des Codes aktiv auf Daten übertragen werden.

Diese überlegung ist nicht ursprünglich auf Unix zurückzuführen, aber viele Unix-Codes werden nachweislich davon beeinflusst. Insbesondere die Funktion der C-Sprache zur Steuerung der Verwendung von Zeigern f?rdert die dynamische ?nderung von Referenzstrukturen auf verschiedenen Codierungsebenen oberhalb des Kernels. Aufgaben, die mit sehr einfachen Zeigeroperationen in Strukturen erledigt werden k?nnen, erfordern oft komplexere Prozeduren in anderen Sprachen.

Bei der datengesteuerten Programmierung müssen Sie den Code und die Datenstruktur, auf die der Code einwirkt, klar trennen. Auf diese Weise müssen Sie beim ?ndern der Programmlogik nur die Datenstruktur und nicht den Code bearbeiten. Datengesteuerte Programmierung wird manchmal mit objektorientierter Programmierung verwechselt, einem anderen Stil, der sich auf die Datenorganisation konzentriert. Es gibt mindestens zwei Unterschiede zwischen ihnen. Erstens sind Daten bei der datengesteuerten Programmierung nicht nur der Zustand eines Objekts, sondern definieren tats?chlich den Kontrollfluss des Programms. Zweitens berücksichtigt die objektorientierte Programmierung zun?chst die Kapselung, w?hrend die datengesteuerte Programmierung das Schreiben von Werten berücksichtigt Weniger fester Code.

2.10 Beliebter Grundsatz: Vermeiden Sie Neuheiten im Interface-Design

Dies wird auch als ?Prinzip der geringsten überraschung“ bezeichnet. Das am einfachsten zu verwendende Programm ist dasjenige, bei dem der Benutzer am wenigsten neue Dinge lernen muss und das am besten zu den vorhandenen Kenntnissen des Benutzers passt. Daher sollte das Interface-Design ungerechtfertigte Neuheiten und Cleverness vermeiden.

Wenn Sie einen Taschenrechner programmieren, sollte ?+“ immer Addition bedeuten. Versuchen Sie beim Entwerfen von Schnittstellen, sie nach denselben funktionalen Schnittstellen und ?hnlichen Anwendungen zu modellieren, mit denen Benutzer am wahrscheinlichsten vertraut sind.

Konzentrieren Sie sich auf Ihre Zielgruppe, es k?nnen Endbenutzer, andere Programmierer oder Systemadministratoren sein. Am wenigsten überraschend bedeutet für diese verschiedenen Personengruppen unterschiedliche Bedeutungen. Konzentrieren Sie sich auf traditionelle Konventionen, die aus einem guten Grund existieren: um die Lernkurve zu erleichtern.

Die andere Seite des Prinzips der minimalen Innovation besteht darin, zu verhindern, dass Dinge ?hnlich erscheinen, sich aber tats?chlich geringfügig unterscheiden. Dies kann ?u?erst gef?hrlich sein, da scheinbare ?hnlichkeiten oft dazu führen, dass Menschen falsche Annahmen treffen. Es ist also besser, verschiedene Dinge zu haben, die sich deutlich unterscheiden, als dass sie fast identisch aussehen.

2.11 Prinzip des Schweigens: Wenn das Programm nichts zu sagen hat, schweigen Sie

Ein gut funktionierendes Programm sollte ger?uschlos arbeiten und niemals klappern. Stille ist Gold. Dieses Prinzip entstand aus der Tatsache, dass es bei der Geburt von Unix keine Videomonitore gab, die die kostbare Zeit des Benutzers verschlingen würden. Diese Situation gibt es nicht mehr, aber die sch?ne Tradition, alles einfach zu halten, wird bis heute fortgesetzt.

Einfachheit ist der Kernstil von Unix-Programmen. Sobald die Ausgabe eines Programms zur Eingabe eines anderen Programms wird, ist es einfach, die erforderlichen Daten herauszusuchen. Aus menschlicher Sicht sollten wichtige Informationen nicht mit ausführlichen Informationen über das interne Verhalten des Programms vermischt werden. Wenn die angezeigten Informationen alle wichtig sind, besteht keine Notwendigkeit, danach zu suchen. Ein gut gestaltetes Programm behandelt die Aufmerksamkeit des Benutzers als eine begrenzte und wertvolle Ressource, die nur bei Bedarf genutzt werden muss, um den Benutzer nicht mit unn?tigen Informationen zu bel?stigen.

2.12 Abhilfeprinzip: Wenn eine Ausnahme auftritt, beenden Sie den Vorgang sofort und geben Sie ausreichende Fehlerinformationen an

Die Software sollte beim Auftreten eines Fehlers über die gleiche transparente Logik verfügen wie im Normalbetrieb. Das beste Szenario ist natürlich, dass sich die Software anpassen und mit anormalen Abl?ufen umgehen kann; das schlimmste Szenario ist, wenn die Abhilfema?nahmen offensichtlich erfolglos bleiben, aber das Risiko von Abstürzen, die erst viel sp?ter aufgedeckt werden, stillschweigend verbirgt .

Deshalb muss die Software m?glichst gelassen mit diversen Fehleingaben und eigenen Lauffehlern umgehen. Sollte ihr dies nicht m?glich sein, lassen Sie das Programm so beenden, dass eine m?glichst einfache Fehlerdiagnose m?glich ist.

?Mit Toleranz empfangen und mit Vorsicht senden“. Selbst wenn die Eingabedaten nicht standardisiert sind, wird ein gut gestaltetes Programm versuchen, ihre Bedeutung zu verstehen und so weit wie m?glich mit anderen Programmen zusammenzuarbeiten. Dann wird es entweder lautstark zusammenbrechen oder strenge, saubere und korrekte Daten für das Programm ausgeben das n?chste Glied der Arbeitskette.

Beim Entwerfen sollte auf Toleranz geachtet werden und es dürfen keine allzu nachsichtigen Implementierungen verwendet werden, um die M?ngel der Standards auszugleichen. Andernfalls werden Sie h?sslich sterben, wenn Sie nicht aufpassen.

2.13 ?konomisches Prinzip: Es ist besser, einen Punkt für die Maschine zu verwenden als eine Sekunde für den Programmierer

In der frühen Minicomputer-?ra von Unix war dieser Standpunkt mit der Entwicklung der Technologie noch recht radikal, da Entwicklungsunternehmen und die meisten Benutzer billige Maschinen erhalten konnten, sodass die Rationalit?t dieses Prinzips selbstverst?ndlich ist.

Unter der Pr?misse, die Qualit?t sicherzustellen, versuchen Sie, Computerressourcen zur Erledigung von Aufgaben zu nutzen und die Belastung für Programmierer zu verringern. Eine weitere M?glichkeit, Programmierer erheblich Zeit zu sparen, besteht darin, der Maschine beizubringen, einfachere Programmierarbeiten durchzuführen. Folgen Sie dem ?ffentlichen WeChat-Konto [Embedded System]

2.14 Generierungsprinzip: Vermeiden Sie das Zerrei?en von Hand, versuchen Sie, Programme zu schreiben, um Programme zu generieren

Wir alle wissen, dass Menschen schlecht darin sind, harte Detailarbeit zu leisten. Jede manuelle Arbeit in einem Programm ist ein N?hrboden für Fehler und Verz?gerungen, und programmgenerierter Code ist fast immer billiger und vertrauenswürdiger als handgeschriebener Code.

Für Codegeneratoren k?nnen sich wiederholende und stumpfe Hochsprachencodes, die Handschrift erfordern, genau wie Maschinencodes in Massenproduktion hergestellt werden. Der Einsatz eines Codegenerators zahlt sich dann aus, wenn er den Abstraktionsgrad erh?ht, das hei?t, wenn die deklarativen Anweisungen des Generators einfacher sind als der generierte Code und der generierte Code eine aufw?ndige manuelle Verarbeitung überflüssig macht. Codegeneratoren werden unter Unix h?ufig verwendet, um detaillierte, fehleranf?llige Arbeiten zu automatisieren.

2.15 Optimierungsprinzip: Vor dem Schnitzen einen Prototyp machen, vor dem Laufen laufen lernen

Das grundlegendste Prinzip des Prototyping-Designs lautet: ?90 % der Funktionen k?nnen jetzt realisiert werden, was besser ist als 100 % der Funktionen, die nie realisiert werden k?nnen.“ Durch gutes Prototyping kann vermieden werden, zu viel Zeit zu investieren, nur um einen kleinen Gewinn zu erzielen.

?Wir sollten die Effizienzsteigerung nicht durch geringfügige Gewinne in Betracht ziehen. Vorzeitige Optimierung ist die Wurzel allen übels. Sich mit der Optimierung zu beeilen, ohne zu wissen, wo der Engpass liegt, kann der einzige Fehler sein, der dem Design mehr schadet als das Hinzufügen zuf?lliger Funktionen.“ Von deformiertem Code bis hin zu unorganisiertem Datenlayout führt das einseitige Streben nach Geschwindigkeit auf Kosten von Transparenz und Einfachheit zu unz?hligen Fehlern und verschlingt die Zeit von Millionen von Menschen. Dieser kleine Vorteil gleicht die anschlie?enden Fehlerbehebungskosten bei weitem nicht aus.

Eine vorzeitige lokale Optimierung kann die globale Optimierung tats?chlich behindern und dadurch die Gesamtleistung verringern. ?nderungen, die gr??ere Vorteile für das Gesamtdesign bringen würden, werden oft durch eine vorzeitige lokale Optimierung behindert, was zu einem Produkt mit schlechter Leistung und überm??ig komplexem Code führt.

In der Unix-Welt gibt es eine sehr klare und langj?hrige Tradition: Erst Prototypen erstellen, dann verfeinern. Stellen Sie vor der Optimierung sicher, dass es verwendet werden kann. Zuerst k?nnen Sie laufen und dann laufen lernen. Dies l?sst sich effektiv auf eine andere Kultur übertragen: Zuerst laufen, als N?chster der Richtige sein und zuletzt schnell sein.

Die Essenz all dieser W?rter bedeutet eigentlich dasselbe: Entwerfen Sie zun?chst eine nicht optimierte, langsam laufende, speicherintensive, aber korrekte Implementierung und nehmen Sie dann systematische Anpassungen vor, um diejenigen zu finden, mit denen Sie bessere Ergebnisse erzielen k?nnen, indem Sie auf minimale lokale Einfachheit verzichten verbessert wird.

2.16 Prinzip der Vielfalt: Glauben Sie niemals an die Behauptung der sogenannten ?einzigen Methode“

Selbst die beste Software wird oft durch die Vorstellungskraft ihrer Entwickler eingeschr?nkt. Niemand ist schlau genug, alles zu optimieren, noch kann er alle Einsatzm?glichkeiten von Software vorhersehen.

Beim Software-Design und der Implementierung ist es eine gute Sache an der Unix-Tradition, dass sie niemals an einen sogenannten ?Einheitsansatz“ glaubt. Unix strebt die weitverbreitete Nutzung mehrerer Sprachen, offener skalierbarer Systeme und Benutzeranpassungsmechanismen an; es absorbiert und greift auf verschiedene hervorragende Designideen zurück und verbessert kontinuierlich seine eigenen Designmethoden und -stile.

2.17 Expansionsprinzip: Entwerfen Sie mit Blick auf die Zukunft, die Zukunft ist immer schneller als erwartet

Lassen Sie Spielraum für die Erweiterung von Datenformaten und Code, sonst werden Sie oft durch unkluge Originalentscheidungen blockiert, da Sie diese nicht ?ndern und gleichzeitig die Kompatibilit?t mit dem Original wahren k?nnen.

Wenn Sie ein Protokoll oder Dateiformat entwerfen, achten Sie darauf, dass es ausreichend selbstbeschreibend ist, damit es erweiterbar ist. Fügen Sie entweder eine Versionsnummer ein oder verwenden Sie unabh?ngige, selbstbeschreibende Anweisungen, die so organisiert sind, dass jederzeit neue eingefügt und alte ausgetauscht werden k?nnen, ohne den Code zu besch?digen, der das Format liest. Die Unix-Erfahrung zeigt, dass Sie durch eine geringfügige Erh?hung des Overheads für die selbstbeschreibende Datenbereitstellung skalieren k?nnen, ohne das Ganze zu zerst?ren, und dass sich ein kleiner Aufwand tausendfach auszahlen kann.

Beim Entwerfen des Codes sollte dieser gut organisiert sein, damit zukünftige Entwickler neue Funktionen hinzufügen k?nnen, ohne die gesamte Architektur abzurei?en oder neu aufzubauen. Dieses Prinzip bedeutet nicht, dass Sie Funktionen hinzufügen k?nnen, die nicht verwendet werden, sondern dass Sie beim Schreiben von Code zukünftige Anforderungen berücksichtigen sollten, um das Hinzufügen von Funktionen in Zukunft zu erleichtern. Die Programmoberfl?che sollte flexibel sein. Fügen Sie dem Code den Kommentar ?Wenn eine Erweiterung erforderlich ist“ hinzu. Sie sind verpflichtet, denjenigen, die den von Ihnen geschriebenen Code verwenden, etwas Gutes zu tun Erstellen Sie den Code in Zukunft selbst und gestalten Sie ihn mit Blick auf die Zukunft. Was Sie sparen, ist m?glicherweise Ihre eigene Energie.

3 Anwenden der Unix-Philosophie

Diese philosophischen Prinzipien sind keineswegs vage und allgemein. In der Unix-Welt stammen diese Prinzipien direkt aus der Praxis und bilden spezifische Regeln.

Mit der Unix-Philosophie sollten Sie st?ndig nach Exzellenz streben. Softwaredesign ist ein Handwerk, das Weisheit, Kreativit?t und Leidenschaft verdient. Andernfalls werden Sie nicht über diese einfachen und altmodischen Designs und Implementierungen hinausgehen; Sie werden sich beeilen, zu programmieren, wenn Sie denken sollten, Sie werden das Problem verkomplizieren, wenn Sie rücksichtslos das Komplexe weglassen und vereinfachen sollten, und Sie werden sich darüber beschweren, warum Der Code ist so aufgebl?ht und schwer zu debuggen.

Um die Unix-Philosophie optimal zu nutzen, handeln Sie niemals rücksichtslos; verwenden Sie mehr Geschick und sparen Sie Ihre Energie für den Einsatz bei Bedarf. Nutzen Sie Tools und automatisieren Sie alles so weit wie m?glich.

4 Haltung

Softwaredesign und -implementierung ist eine Kunst voller Freude, ein Spiel auf hohem Niveau. Warum sollten Sie sich mit Software-Design besch?ftigen und nicht mit etwas anderem? Vielleicht geht es jetzt nur darum, Geld zu verdienen oder sich die Zeit zu vertreiben, oder vielleicht dachten Sie einmal, dass Software-Design die Welt ver?ndert und die Leidenschaft wert ist.

Das obige ist der detaillierte Inhalt vonProgrammierprinzipien der Unix-Philosophie. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!