Programmierphilosophie 7 - Praktik

    Software-Praxis.

    In diesem Artikel versuche ich, das Konzept der „Programmpraktikabilität“ in Umlauf zu bringen und es mehr oder weniger formal zu definieren, aber gleichzeitig in einer einfachen, lesbaren Sprache.

    Erstens, die grundlegenden Konzepte, die in diesem Artikel verwendet werden und deren Zweck und nur diese dienen. Diese Konzepte sind nur im Kontext dieses Artikels gültig und sinnvoll.

    Werkzeug.

    Ein Tool ist wiederverwendbarer, wiederverwendbarer Code, normalerweise eine Bibliothek, ein Compiler, eine Datenbank, ein Befehlszeilendienstprogramm, ein Framework usw.

    Sprache.

    Sprache ist ein konzeptioneller Apparat, der von einer Person verwendet wird, die dieses Werkzeug verwendet. Zum Beispiel ist die Sprache des Befehls ls (oder dir) eine Menge von Wörtern. An erster Stelle stehen die Wörter file und directory.

    IPA.

    IPA ist der Programmcode, den der Benutzer eingeben muss, um auf die vom Tool bereitgestellten Funktionen zugreifen zu können.

    BALL.

    BAL ist eine Abkürzung für "Basisalgorithmus", z. B. Quick-Sort-Algorithmus, Binärbaum. Eine bestimmte Funktion - um die herum der Rest der Funktionalität des Tools aufgebaut ist. Oder eine Reihe solcher Funktionen. BAL enthält in der Regel nicht viel Code, ist jedoch sehr komplex und wird manchmal über Jahrzehnte von akademischen Wissenschaftlern, Fachleuten und Bastlern auf der ganzen Welt verbessert.

    Kleber.

    Der Rest des von der API bereitgestellten Toolcodes verbindet die BAL und die API. Es ist Kleber, der normalerweise den Großteil des Codes im Tool ausmacht. Zum Beispiel sind BALS in dem oben erwähnten ls-Befehl die Funktionen readdir () und fstat (), sie lesen tatsächlich Dateien und Verzeichnisse. Alles andere ist Leim, der Dutzende von Befehlszeilenschlüsseln (API) bereitstellt, die Formatierung der Ausgabe (obwohl das Aufteilen der Liste der Dateinamen in Spalten natürlich auch BAL ist) und die Fülle der API und der Sprache dieses Befehls.

    Praktikabilität des Programms ist also BAL-Zentriertheit.

    Regel eins: Kleber sollte so klein wie möglich sein.

    Im Idealfall sollte der Klebstoff genau genug sein, um dem Benutzer Zugriff auf die BALS zu gewähren, nicht mehr und nicht weniger.

    Regel 2: Die API sollte so nah wie möglich an der BAL-Schnittstelle sein, auf der dieses Tool basiert. In der Regel ist es umgekehrt. Zuerst wird eine IPA erfunden, um ihre Probleme zu lösen. Dann wird nach BALs gesucht, auf deren Grundlage ein solches Tool geschrieben werden kann. Manchmal wird eine BAL verworfen und stattdessen eine andere, wobei die IPA unverändert bleibt oder minimiert wird erfordert neue Parameter oder Funktionen.

    Sie haben beispielsweise einen bestimmten Container für die API geschrieben und ihn um ein Array erstellt. Dann hat sich herausgestellt, dass die verknüpfte Liste besser für die Aufgabe geeignet ist. Sie haben das Array durch eine verknüpfte Liste ersetzt. Da die verknüpfte Liste jedoch die Möglichkeit bietet, vorwärts und rückwärts zu navigieren, haben wir die Funktionen next () / prev hinzugefügt () die vorher nicht waren. Es stellt sich heraus, dass die IPA einerseits auf externen Überlegungen, der Sprache des Benutzers, den beabsichtigten Anwendungen beruht und andererseits von der internen Struktur des Instruments abhängt, in erster Linie von den verwendeten BALs.

    Regel Drei: BALS muss High-End sein, das Beste von dem, was Sie bekommen können.

    Diese Regel ist das genaue Gegenteil des oft angewendeten Ansatzes, bei dem die Hauptanstrengungen auf die Entwicklung von Klebstoff gerichtet sind. Es gibt jedoch keine binäre Suche nach beispielsweise einer sehr effektiven Zeitsuche von Weltklasse, da sie auf das BAL-Knie geschrieben und an den Rest des Codes angepasst wird. Aufgrund seiner Ineffizienz kann es nicht überall verwendet werden, und an Stellen, an denen es nicht passt, ist etwas anderes geschrieben. Die Hauptlogik der Entwicklung wird im Kleber gehalten, und BALs werden von verschiedenen Seiten angebracht, um diesen Koloss zu stützen. Ein erstklassiger Algorithmus stammt von GitHub, ist aber nicht ideal für die Entscheidungen, die bereits im Tool getroffen wurden. Daher wird er durch Wrapper vervollständigt oder gewichtet. Anstelle von:

    Regel 4: Jeder Code (oder Kleber in der Terminologie dieses Artikels) muss balozentrisch sein. Wenn die Inkompatibilität der BAL und Ihres selbst erstellten Codes erkannt wird, wird die BAL als Arbiter, als höchste Autorität, wahrgenommen und der Code ändert sich, um den Funktionen des zugrunde liegenden Algorithmus zu entsprechen.

    Regel 5: Die Sprache, in der die Benutzer des Tools die Grundprinzipien grundlegender Algorithmen verwenden müssen. Und zumindest der Rest.

    Das heißt, anstelle von "Telefon", "Basis", "Adressen", "Alles anzeigen" usw. stellen Sie APIs nicht nur auf Schlüssel- / Wertbasis zur Verfügung, sondern der Benutzer muss auch in derselben Sprache argumentieren, in der die grundlegenden Algorithmen erstellt wurden. Die effektive Nutzung des Basisalgorithmus ist nur im Rahmen der konzeptionellen Apparatur dieses Basisalgorithmus möglich. Einfach ausgedrückt, wenn Sie als Benutzer nicht wissen, was ein schwarz-roter Baum ist, und das von Ihnen verwendete Tool darauf aufbaut, wird das Tool nicht effizient genug eingesetzt.

    Sie können ständig den Wunsch der Programmierer beobachten, die Implementierungsdetails unter der Motorhaube zu verbergen und der Person ein Lenkrad und ein Pedal zu geben. Aber zusammen mit dem Lenkrad und den Pedalen müssen Sie ihm eine Sprache mit den Grundkonzepten "Kupplungsscheibe", "Griff", "Bremsweg" geben. Das Nichtbeachten des Geräteverständnisses führt zu einem Unfall.

    Infolgedessen konzentriert sich die gesamte Aktivität bei der Entwicklung des Tools auf grundlegende Algorithmen, in denen die besten Beispiele vorgestellt oder eigene, einzigartige entwickelt werden. Die Arbeit wird viel technischer und die Gespräche werden spezifischer.

    Ein gutes Beispiel für die Praktikabilität von Software ist DB Redis.

    Anstelle der üblichen „bequemeren“ abstrakten Sprache gibt es APIs, bei denen sogar die Namen der Befehle die verwendeten Algorithmen widerspiegeln: Set, List, Key / Value (Hash-Tabelle). Obwohl es nach Prinzip 5 möglich war, wurde ZList Skiplist genannt, weil genau die ZList auf dem Skiplist-Algorithmus basiert und das Verständnis dieser Tatsache für den Benutzer seine Anwendung noch effektiver machen würde. Und da ist überhaupt nichts mehr, es gibt BALs, grundlegende Algorithmen und eine Reihe von Funktionen für sie.

    Sie können sogar Folgendes sagen: Wenn Sie einen Client haben und er Aufgaben hat, die von einem grundlegenden Algorithmus gut gelöst werden, sollten Sie dem Client beibringen, die Sprache dieses Algorithmus zu sprechen, und nicht umgekehrt.

    Praktikabilität ist nicht unbedingt Minimalismus, insbesondere wenn mehrere BALs in einem Instrument verbunden sind, und es wird zu einer ernsten Aufgabe, dem Benutzer konsistenten Zugriff auf alle ihre Funktionen auf einmal zu ermöglichen. Wie in demselben Redis können Sie Set und List in derselben Abfrage verwenden. In diesem Fall kann der Code, der mehrere BALs verbindet, eine schwierige Entwicklung für sich sein und zu einer neuen BAL führen. Beispielsweise besteht die LZ-Komprimierung aus zwei grundlegenden Algorithmen, der Wiederholung der Gleitfenstersuche und der Huffman-Komprimierung, und es war sehr aufwendig, diese beiden Algorithmen zur dritten zu kombinieren, die heute die Standard-BAL vieler Systeme ist.

    Übrigens, ein gutes Beispiel: gzip ist ein nützliches Tool, das im Gegensatz zum Dienstprogramm pkzip, das mit einer Vielzahl von Funktionen überladen ist, nur einen minimalen Zugriff auf die Funktion gzip () bietet. Natürlich ist der Vergleich hier nur teilweise, da pkzip über zwei grundlegende Algorithmen verfügt, nämlich die Komprimierung und Archivierung mehrerer Dateien und die reine Komprimierung von gzip.

    Es gibt eine andere Regel im Minimalismus: Wenn Ihre API selten verwendete Funktionen hat, entfernen Sie diese. Dies ist ein völlig anderer Ansatz, der häufig zu Problemen führt. Die Besonderheit der Praktikabilität liegt genau in der Tatsache, dass Sie einen vollständigen Satz von Funktionen bereitstellen, die mit grundlegenden Algorithmen verbunden sind.

    Wenn Sie bei der Entwicklung Ihres eigenen Werkzeugs verwirrt sind, versuchen Sie, alles außer den grundlegenden Algorithmen daraus zu schütteln und es nach den Prinzipien des "balozentrischen" Software-Praktikums wieder zusammenzusetzen.

    Der Praxisbezug entspricht nicht dem globalen Trend der Modularität, der normalerweise wie folgt lautet: "Lassen Sie das Instrument eine Sache tun und machen Sie es gut." Einige Ähnlichkeiten mit den Prinzipien des Praktizierens lassen sich erkennen, aber der Ausgangspunkt ist anders. Die Praktikabilität schlägt vor, von den grundlegenden Algorithmen selbst auszugehen, da sie auf der Tatsache beruhen, dass Sie sich unabhängig von Ihrer Tätigkeit und der von Ihnen implementierten Funktionalität auf die grundlegenden verlassen werden Algorithmen kommen Sie auf keinen Fall davon los. Nehmen Sie sie aus Open Source, Wikipedia oder erstellen Sie originelle, es ist logisch, ein System um sie herum aufzubauen, als sie ständig zu bekämpfen.

    Der Autor schlägt vor, den Schwerpunkt bei der Entwicklung von Systemen zu ändern. Der zeitaufwendigste und wertvollste Code sind die grundlegenden Algorithmen. In der Regel wird ihnen jedoch nur sehr wenig Beachtung geschenkt, anstatt zu versuchen, sie in den Vordergrund zu stellen und alles andere um sie herum zu erstellen.

    Zusammenfassend: Weniger Kleber, Förderung von BALs. Jeder Konflikt zwischen ihnen zugunsten von BALs, IPAs und Terminologie steht in direktem Zusammenhang mit BALs.

    Der Autor dieses Artikels argumentiert nicht, dass ein solcher Programmieransatz der beste ist oder besser als andere, dass dies eine Art Wahrheit ist, es ist nur ein anderer Ansatz, der sich mit klaren Regeln und einem konzeptionellen Rahmen etabliert hat.

    Jetzt auch beliebt: