Das Problem, das Sie lösen, ist wichtiger als der Code, den Sie schreiben

Programmierer scheinen vergessen zu haben, dass der eigentliche Zweck der Software darin besteht, echte Probleme zu lösen.

Vor 50 Jahren, 1968, wurde eine Arbeitskonferenz zum Thema Software Engineering organisiert, die mit Unterstützung des NATO-Wissenschaftskomitees organisiert wurde. Zu dieser Zeit bemerkten die Menschen, dass Software ein grundlegender Bestandteil der Gesellschaft wurde. Es wurde jedoch auch zu schwer zu verstehen. Nach dieser Konferenz ist die Programmierung zu einer Branche geworden. Und es begann sich von der Kontrolle von Geschäftsleuten zu entfernen.

Unabhängig davon, wie die Programmierung seitdem verlaufen ist, gibt es immer noch ein Problem mit der Trennung zwischen Business und Softwareentwicklung - oder „ENGINEERING“, wie die Konferenz es zuerst nannte. Wenn sich Entwickler zu sehr auf die Entwicklung konzentrieren, verfehlen sie möglicherweise das Ziel der von ihnen geschriebenen Software. Sie sehen möglicherweise keine versteckten Lösungen, für die kein Code erforderlich ist.

Hier ist ein Beispiel.

Es gab ein Startup, das ein Gerät entwickelte, mit dem eine Person die Tür ihres Hauses über Bluetooth öffnen konnte. Als visuelle Oberfläche wurde ein Widget verwendet, das auch bei gesperrtem Telefon sichtbar war. Er hatte einen einzigen Knopf namens "Öffne die Tür".

Als der Benutzer näher zu Hause kam, nahm er das Telefon, fand das Widget und drückte einen Knopf, um die Tür zu öffnen.

Jemand sah es sich an und fragte:

Wenn wir Bluetooth verwenden und unser Geschäftsmodell es jedem erlaubt, der ein Telefon hat, das Haus zu betreten, warum sollten wir dann jemanden zwingen, das Telefon zu nehmen und die Taste zu drücken? Lassen Sie die Tür öffnen, wenn sich das Gerät 1 Meter nähert. Wir müssen also nicht für die Entwicklung und Programmierung der visuellen Oberfläche bezahlen!

Diese Bluetooth-Geschichte ist ein großartiges Beispiel für einen engen Fokus: Ziel war es, die Tür mit minimalem Aufwand zu öffnen. Es macht keinen Sinn, eine visuelle Schnittstelle zu entwickeln, wenn die Sensoren drahtlos sind.

Wenn Sie wissen, welche Ziele das Unternehmen erreichen möchte und was für den Benutzer von Wert ist, können Sie dieses Wissen mit Ihrem technologischen Wissen kombinieren. Nur dann haben Sie genügend Informationen, um die besten Antworten zu finden und zu dem Schluss zu kommen, dass das Produkt keine Schnittstelle benötigt.

Dies ist ein großartiges Beispiel dafür, wie Sie ein technisches Problem lösen können, ohne neben dem Entsperrcode zusätzlichen Code schreiben zu müssen. Wie bei Tech Debt sollte jedoch nichts das Schreiben von beschissenem Code rechtfertigen .

Nicht jeder Code ist es wert, geschrieben zu werden.

Manchmal hat die Behebung eines schwerwiegenden Fehlers keine Priorität. Wenn Sie über einen Kryptowährungsaustausch verfügen und das System zweimal dieselbe Zahlung geleistet hat, ist menschliches Eingreifen möglicherweise die beste Lösung in Bezug auf Kosten und Nutzen, wenn die Kosten für die Lösung dieses Problems hoch sind.

Dieser Kompromiss zwischen Ernsthaftigkeit und Priorität erinnert mich an das Modell, das mir mein Kollege kürzlich gezeigt hat. Es wird als "Prioritätsmatrix" bezeichnet, ein zweidimensionales Modell , mit dem Fehler anhand der Anzahl der betroffenen Benutzer und des Schweregrads priorisiert werden können.



Das oben beschriebene Problem der erneuten Einzahlung fällt in die Kategorie der Unannehmlichkeiten, die einen Benutzer betreffen. Daher Priorität 3.

Nicht jeder Fehler ist es wert, behoben zu werden.

Dies ist eine sehr häufige Sache, wenn Entwickler versuchen, ein Skript für alles zu schreiben. Einige sich wiederholende Aufgaben sind jedoch keine Automatisierung wert. Sie müssen keine Zeit damit verbringen, Skripte zu programmieren, wenn Sie das erforderliche Wissen über die Arbeitsweise des Hauptteams verbergen möchten.

Es gibt einen Unterschied zwischen der Verkapselung komplexer Logik und der Abstraktion nützlichen Wissens. Manchmal müssen die Informationen klargestellt werden. Wenn Sie sie abstrahieren, haben sie möglicherweise den gegenteiligen Effekt und sind schwieriger zu verstehen.

Es ist nützlicher, einige Arten von Befehlen auf niedriger Ebene in der CLI zu verwenden, als einen Befehl auf hoher Ebene, der Wissen abstrahiert, wie z. B. Git .

Vor einigen Jahren arbeitete ich an einem Projekt mit inkrementeller Lieferung . Es war ein Identitätsprüfungssystem, bei dem der Benutzer einige personenbezogene Daten zur Überprüfung durch einen Drittanbieter bereitstellen musste.

Dies war eine spezielle Feldvalidierungsfunktion, die das Team erstellen wollte. Die Prüfungshistorie wurde jedoch bei der Planung jedes Sprints priorisiert, da die Frist immer näher rückte. Am Ende stellte das Team fest, dass eine bizarre Validierung überhaupt keinen Sinn hatte.

Und hier ist der Grund: Die Überprüfung war obligatorisch!

Es liegt im Interesse des Benutzers, zuverlässige Informationen bereitzustellen. Wenn der Benutzer falsche Daten angibt, werden diese nicht überprüft und können das System nicht verwenden. Darüber hinaus unterstützten die meisten Browser die Standard-HTML-Validierung, was ziemlich gut war.

Im schlimmsten Fall können Benutzer, die sich nicht verifizieren konnten, den Support anrufen, um alles manuell zu überprüfen.

Nicht jede Funktion ist programmierwürdig.

Wenn Sie ein Entwickler sind und das Problem verstehen, das Sie zu lösen versuchen, können Sie sich besseren Code einfallen lassen, und manchmal können Sie überhaupt ohne den Code auskommen. Sie sind kein " Code Monkey ", der dafür bezahlt wird, Zeichen auf den Bildschirm zu schreiben. Sie sind ein Profi, der für die Lösung von Problemen bezahlt wird.

Wenn Sie jedoch versuchen, alle Probleme mit Hilfe der Technologie zu lösen, ohne darüber nachzudenken, werden Sie Probleme haben, zu verstehen, was für den Kunden wertvoll ist, und großartige Ideen zu entwickeln.

Ihr Ziel und das Ziel des von Ihnen geschriebenen Codes ist es, Wert zu schaffen und die bestehende Welt zu einem besseren Ort zu machen, und Ihre egozentrische Sicht auf die Welt nicht zu befriedigen.

Es gibt ein Sprichwort: "Wenn Sie nur einen Hammer haben, sieht alles aus wie ein Nagel."

Es ist besser, zuerst einen Nagel zu haben, damit Sie die Notwendigkeit eines Hammers in Betracht ziehen können.

Das heißt, wenn Sie zuerst einen Nagel brauchen.

Vielen Dank für das Lesen des Artikels!

Wenn ich Fehler in der Übersetzung habe, schreibe bitte darüber in den Kommentaren!
Besuchen Sie auch meine Website, um schnell auf Javascript-Fragen und -Antworten zuzugreifen - JavaScript-Fragen und -Antworten

Ich werde Ihnen sehr dankbar und dankbar sein.

Ich bin auf Twitter und vk

Vielen Dank für Ihre Aufmerksamkeit!