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.
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.
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.
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.
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.
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.
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.
„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.
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]
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.
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.
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.
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.
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.
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]
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.
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.
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.
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.
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.
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!
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
