Oft wurde ich gefragt, warum ich lieber Programmiersprachen wie Haskell und Rust verwende, weil Sie sind nicht die am weitesten verbreiteten und beliebtesten Werkzeuge. Dieser Beitrag wurde mit der Absicht geschrieben, zu entmystifizieren, was in meinem Kopf vorgeht, wenn ich über Technologieentscheidungen nachdenke.
Die Softwareentwicklung mit den Anforderungen eines langfristigen Betriebs und einem gewissen Maß an Zuverlässigkeit ähnelt in gewisser Weise einem Schachspiel. Varianten der Entwicklung von Ereignissen in beiden sind für das menschliche Gehirn ziemlich schwer zu verstehen, die Rolle der Erfahrung ist von großer Bedeutung und jede Bewegung / Wahl kann kritisch sein. Die Ähnlichkeit setzt sich in dem Sinne fort, dass die Entwicklung wie beim Schach sehr "positionell" ist - eine ganze Reihe von Zügen kann darauf abzielen, sich auf ein Manöver vorzubereiten, das zu einem Bauerngewinn führt. Es mag scheinen, dass dies nur ein Bauer ist, aber für ein ernstes Spiel kann dies ein bedeutender Vorteil sein. Ähnlich wie beim Positionsspiel des Schachbretts treffen wir bei der Planung und Entwicklung großer Projekte ständig Entscheidungen, die darauf abzielen, größere Probleme zu lösen oder die Anforderungen des Projekts zu erfüllen.Die Wirkung jeder Lösung, auch einer kleinen, neigt dazu, sich gegen Ende des Spiels oder zu dem Zeitpunkt, zu dem das Softwareprodukt in Betrieb ist, zu akkumulieren. Der Unterschied, der die Situation verschlimmert, besteht darin, dass die Softwareentwicklung im Gegensatz zu Schach nicht auf einem Computer gelöst wird und Sie nicht einfach die besten Schritte unternehmen können, indem Sie eine Computer-Engine ausführen. Daher müssen viele Entscheidungen getroffen werden, die uns schrittweise zu diesem Ziel führen, und alle Mittel, die unsere strategische "Position" verbessern, sind gut.und Sie können nicht einfach die besten Schritte finden, indem Sie eine Computer-Engine ausführen. Daher müssen viele Entscheidungen getroffen werden, die uns schrittweise zu diesem Ziel führen, und alle Mittel, die unsere strategische "Position" verbessern, sind gut.und Sie können nicht einfach die besten Schritte finden, indem Sie eine Computer-Engine ausführen. Daher müssen viele Entscheidungen getroffen werden, die uns schrittweise zu diesem Ziel führen, und alle Mittel, die unsere strategische "Position" verbessern, sind gut.
Lösungen können in verschiedene Kategorien unterteilt werden: architektonisch, methodisch und instrumentell. Architekten sprechen darüber, wie wir ein Projekt strukturieren. Die Methoden bestimmen, wie wir den Arbeitsprozess organisieren, stellen die Qualität und Richtigkeit der Implementierung sicher. Tools bestimmen, mit was das Entwicklungsteam arbeiten muss, um das Ergebnis zu erhalten. Für einen vollständigen Entwicklungszyklus wird heute eine große Anzahl von Tools verwendet: Sie müssen die Anforderungen, den Entwicklungsprozess formalisieren, Programmcode schreiben und testen, eine Version erstellen usw. Trotz dieser Fülle von Aufgaben müssen die Die Wahl einer Programmiersprache kann die wichtigste Rolle spielen, da sie eine Reihe der folgenden Parameter bestimmt:
- Basis für die Geschwindigkeit der Software.
- , .
- , . , .
- // , .
- , , .
- .
Darüber hinaus kann die Wahl einer Programmiersprache auch methodische Probleme erheblich beeinflussen. Beispielsweise können die Tools des Sprachökosystems bestimmen, wie und in welchem Umfang Unit-Tests geschrieben werden. Eine gute Infrastruktur für Eigenschaftstests kann einen Schub in diese Richtung geben, und das Fehlen einer guten Infrastruktur für Komponententests kann das Schreiben und Verwalten erschweren.
Die Tools wirken sich auch auf Architekturprobleme aus. Die Wiederverwendung von Modulen im System hängt davon ab, wie bequem es ist, Blöcke konzeptionell zu unterteilen und den Code zu strukturieren. Wenn Sie beispielsweise explizit mit Effektsystemen arbeiten, können Sie den Code stärker verallgemeinern und sicherstellen, dass das Codemodul keine E / A-Vorgänge ausführt, z. B. die Arbeit mit Netzwerk und Festplatte, sodass Sie über Sicherheit und Architektur nachdenken können.
Auf dieser Grundlage sollten Sie sich bewusst sein, dass die Auswahl der richtigen Programmiersprache für ein Projekt und ein Team weitreichende Konsequenzen haben kann. In Anbetracht der Schachanalogie denken wir daran, dass jedes kleine Plus an das Sparschwein der Sprache geht und eine bedeutende Rolle in einer großen Entwicklung spielen kann. Erwähnenswert ist auch, dass wir über die Auswahl eines Entwicklungswerkzeugs für Situationen sprechen, in denen es keine strengen Einschränkungen bei der Auswahl von Technologien gibt, beispielsweise in Verbindung mit einem großen Ökosystem, das bereits auf etwas geschrieben ist. Bei Typeable orientieren wir uns an den folgenden Überlegungen für Allzwecksprachen:
- . . , , .
- — , , . . - , , , .
- . GIL (Global Interpreter Lock) . .
- , . , , , .
- . , CS . « » , IT , .
- , .
Aus all diesen Gründen enthält unsere Toolbox genügend Blöcke, die es uns ermöglichen, in vielen Projekten eine sichere Position einzunehmen. Zurück zur Schachanalogie: Dies sind unsere Prinzipien, die es uns ermöglichen, ein Positionsspiel zu spielen. Positionsspiel ist ein Spiel, das darauf abzielt, eine langfristige Position zu schaffen, die dem Spieler Chancen eröffnet und Schwächen minimiert. Es ist im Gegensatz zu einem angreifenden, "scharfen" Spiel, bei dem ein großer Teil des Risikos besteht, und der angreifende Spieler versucht, dieses Spiel zu beenden, bevor sein Gegner eine gute Verteidigungsposition einnehmen kann. "Scharfe" Entwicklung ist Olympiadenprogrammierung, MVP für Marketingexperimente, viele Aufgaben in der Datenwissenschaft und häufig die Erstellung von Software, die mit Veröffentlichungen der Informatik einhergeht. Sie sind sich einig, dass sie oft keine langfristige Unterstützung benötigen.Sie müssen nur zu einem bestimmten Zeitpunkt arbeiten. Das Positionsspiel ist ein langfristiges Spiel, bei dem Wartbarkeit und Aufrüstbarkeit Schlüsselindikatoren sind. Dies ist, was wir tun, und wir brauchen eine gute Grundlage, um von der langfristigen Leistung der Software, die wir schreiben und aktualisieren, überzeugt zu sein. Solche Projekte können auch mit MVP beginnen, werden jedoch mit völlig anderen Voraussetzungen durchgeführt.
Warum ist die Liste der Überlegungen zur Auswahl von Technologien genau so? Dafür gibt es mehrere Gründe. Erstens ist es wünschenswert, die Themen Mode und Technologietrend auszuschließen, um die Vorhersagbarkeit über einen langen Zeitraum zu verbessern. Ein Compiler mit einer langen Geschichte und einer aktiven Community ist zwar eine konservative, aber verlässliche Wahl, im Gegensatz zu den glänzenden neuen Dingen, die von Jahr zu Jahr auftauchen. Sicherlich werden einige von ihnen von der letzten in die erste Kategorie wechseln, aber wir werden später, wahrscheinlich in Jahren, davon erfahren. Anstelle von Trends versuchen wir, grundlegende Informatik und eine große Menge an Forschung zu diesem Thema zu verwenden, die in den von uns verwendeten Programmiersprachen Anwendung gefunden hat. Zum Beispiel: Die Typentheorie ist eine verwandte Disziplin in Mathematik und CS, die sich mit den grundlegenden Fragen der Formalisierung von Anforderungen befasst. Genau das ist eswas wir brauchen, um Software zu schreiben. Darüber hinaus ist dies die kumulative Erfahrung anderer Leute, die sich mit den exakten Wissenschaften beschäftigen, und es ist meiner Meinung nach irgendwie dumm, diese Erfahrung zu vernachlässigen. Es ist besser, eine solche Disziplin als Grundlage zu nehmen, als nichts zu nehmen oder eine subjektive Meinung zu vertreten, die auf der Lebenserfahrung einer einzelnen Person basiert.
Zweitens suchen wir nach der Implementierung der meisten Prinzipien, die wir in Programmiersprachen und Compilern übernommen haben. Aus diesem Grund erscheint Rust zusätzlich zu unserem geliebten Haskell in unserer Toolbox. Aufgrund der Echtzeitanforderungen und der engen Begrenzung der Speichernutzung benötigen wir etwas, das niedrig genug ist. Die Schreibstringenz in C lässt immer noch zu wünschen übrig. Wenn es also möglich ist, Rust für eine solche Aufgabe zu verwenden, würden wir es vorziehen, dies zu tun.
Der dritte Grund: Wir stellen Software hauptsächlich für unsere Kunden her und möchten, dass sie vor unseren Vorurteilen geschützt werden. Daher darf das Risiko bei der Auswahl eines Instruments ein bestimmtes Niveau nicht überschreiten, das mit dem Kunden vereinbart werden muss. Aber selbst unter solchen Bedingungen haben wir ziemlich marginale Technologien wie GHCJS, weil Mit der kombinierten Analyse der Stärken und Schwächen war das Bild für uns und unsere Kunden immer noch attraktiv. Wir haben bereits darüber geschrieben, wie wir zu dieser Entscheidung gekommen sind: Elm vs Reflex .
Wenn Sie mit großen Codebasen und komplexer Software arbeiten, sind alle Mittel und theoretischen Begründungen gut, da Sie diese Komplexität irgendwie in Schach halten müssen. Unsere Idee des richtigen Ansatzes ist es, jeden Bauern zu verteidigen, seine Position reibungslos und genau zu verbessern, damit das Projekt in einem guten Zustand überleben kann, bis es eine entscheidende Rolle für das Geschäft unserer Kunden spielen kann. Das wünschen wir euch auch.