Ziel ist wichtiger als Code

Das Programm hat ein Ziel, das manchmal vergessen wird

Bild eines Hammers, der auf einer Tafel liegt. Eine Schraube steckte im Brett, die sie dort hart erzielten

Es scheint, dass Programmierer den Zweck von Software vergessen haben - reale Probleme zu lösen.

Vor 50 Jahren, 1968, organisierte das NATO-Wissenschaftskomitee eine Arbeitskonferenz zum Thema Software-Engineering . Dann bemerkten sie, dass Software ein grundlegender Bestandteil der Gesellschaft wurde. Gleichzeitig wird es schwieriger zu verstehen. Nach dieser Konferenz begann sich die Programmierung zu einer echten Industrie zu entwickeln. Es begann außer Kontrolle zu geraten.

Unabhängig vom Schicksal der Branche gibt es immer noch ein Problem mit der Trennung von Geschäft und Softwareentwicklung - oder „Engineering“, wie auf der Konferenz erstmals angekündigt wurde. Wenn sich Programmierer zu eng auf die Entwicklung konzentrieren, verfehlen sie möglicherweise das Ziel, für das das Programm erstellt wird. Sie vermissen möglicherweise versteckte Lösungen, für die überhaupt kein Code erforderlich ist.

Hier ist ein Beispiel.

Ein Startup erstellte ein Gerät, das über Bluetooth die Tür zu einem Haus öffnete. Grafische Oberfläche für die Kommunikation mit dem Gerät - ein Widget auf einem gesperrten Telefonbildschirm. Er hat einen Knopf namens "Öffne die Tür."

Wenn sich der Benutzer dem Haus nähert, nimmt er das Telefon, findet das Widget und drückt die Taste.

Jemand sah diesen Mechaniker an und fragte:

Wenn wir Bluetooth verwenden und davon ausgehen, dass der Besitzer des Telefons das Haus betreten kann, warum sollte er dann gezwungen werden, das Telefon zu holen und die Taste zu drücken? Lassen Sie die Tür sich entriegeln, wenn sich das Telefon in einem Umkreis von 1 Meter befindet. Verschwenden Sie keine Zeit mit Design und GUI-Code!

Dies ist ein hervorragendes Beispiel für einen engen Fokus: Ziel war es, das Schloss mit minimalem Aufwand zu öffnen. Es macht keinen Sinn, eine grafische Oberfläche zu erstellen, wenn die Sensoren drahtlos sind.

Wenn Sie die geschäftlichen Herausforderungen und Benutzeranforderungen kennen, können Sie dieses Wissen mit Ihrem technologischen Wissen kombinieren. Nur dann haben Sie genügend Informationen, um eine bessere Lösung zu finden und zu verstehen, dass das Programm keine Schnittstelle benötigt.

Ein großartiges Beispiel dafür, wie ein Softwareproblem ohne eine einzige Zeile neuen Codes gelöst werden kann , zusätzlich zum Code zum tatsächlichen Öffnen des Schlosses. Aber wie die technische Pflicht kann nichts die unnötige Programmierung von allem anderen rechtfertigen .

Nicht jeder Code ist es wert, geschrieben zu werden.

Manchmal ist es nicht die Hauptaufgabe, einen schwerwiegenden Fehler zu beheben. Wenn Sie ein Kryptowährungsaustausch sind und das System eine doppelte Einzahlung zulässt, ist menschliches Eingreifen möglicherweise die beste Lösung in Bezug auf das Kosten-Nutzen-Verhältnis, wenn die Kosten der Lösung hoch sind.

Dieser Kompromiss zwischen Wichtigkeit und Priorität erinnert mich an ein Modell, das kürzlich von einem Kollegen gezeigt wurde. Es wird als Prioritätsmatrix bezeichnet - ein zweidimensionales Modell , mit dem Fehler anhand des Schweregrads und der Anzahl der betroffenen Benutzer priorisiert werden können.


Zweidimensionale Prioritätenmatrix. Die vertikale Achse repräsentiert die Anzahl der "Opfer" mit den Werten "eins", "mehrere" und "alle". Die horizontale Achse steht für "Ernsthaftigkeit" mit den Werten "kosmetisch", "unangenehm" und "funktioniert nicht mehr". Die Priorität des Fehlers wird durch die Position auf den Achsen bestimmt. Wenn der Fehler beispielsweise kosmetischer Natur ist und einen Benutzer betrifft, beträgt die Priorität 4 (Minimum). Wenn ein Fehler einige Benutzer stoppt, ist die Priorität 1. Wenn alle Benutzer gestoppt werden, hat er die höchste Priorität.

Das oben erwähnte Problem der doppelten Einzahlung fällt in die Kategorie der Unannehmlichkeiten , die einen Benutzer betrafen. Daher Priorität 3.

Nicht jeder Fehler ist es wert, behoben zu werden.

Entwickler versuchen oft, alle Fälle vorherzusehen. Einige sich wiederholende Aufgaben verdienen jedoch möglicherweise keine Automatisierung. Sie müssen keine Zeit mit dem Schreiben von Skripten verschwenden, wenn dadurch wichtige Kenntnisse über die Arbeit des Hauptteams verborgen bleiben.

Es gibt einen Unterschied zwischen der Verkapselung komplexer Logik und der Abstraktion nützlichen Wissens. Manchmal können nur klare Informationen verstanden werden. Wenn wir es abstrahieren, können wir den gegenteiligen Effekt erzielen: Verständnis ist schwierig.

Es ist nützlicher, einige Arten von Befehlen auf niedriger Ebene in der CLI zu verwenden als Befehle auf höherer Ebene mit abstraktem Wissen, wie Git-Aliase .

Nicht jedes Team ist die Beschreibung wert.

Vor vielen Jahren arbeitete ich an einem Projekt mit inkrementeller Lieferung . Es war ein Identitätsprüfungssystem, das den Benutzer aufforderte, einige personenbezogene Daten zur Überprüfung durch Dritte bereitzustellen.

Und dort wollte das Team eine ungewöhnliche Feldvalidierungsfunktion codieren. Diese Validierung wurde jedoch bei jedem Pflanzgefäß zurückgeschoben, als sich die Frist näherte. Am Ende entschieden sie, dass diese ungewöhnliche Funktion überhaupt keinen Sinn ergibt.

Und hier ist der Grund: Die Validierung ist bereits erzwungen!

Die Bereitstellung zuverlässiger Informationen lag im Interesse des Benutzers. Wenn er falsche Daten angegeben hat, bestehen diese die Überprüfung nicht und er kann das System nicht verwenden. Darüber hinaus unterstützen die meisten Browser eine recht gute Standard-HTML-Validierung.

Wenn der Benutzer im schlimmsten Fall nicht überprüft werden kann, ruft er den Support für die manuelle Überprüfung an.

Nicht jede Funktion ist eine Codierung wert

Wenn Sie die Essenz des zu lösenden Problems verstehen, können Sie als Entwickler besseren Code finden, und manchmal können Sie überhaupt auf Code verzichten. Sie sind kein Byldoder, der dafür bezahlt wird, Zeilen für die Aufgabe zu schreiben. Sie sind ein Profi, der für die Lösung von Problemen bezahlt wird.

Es ist jedoch nicht erforderlich, Probleme mit Technologien gedankenlos zu lösen, als wäre der Programmcode eine universelle Lösung für alles. Andernfalls haben Sie Probleme, die Bedürfnisse des Kunden zu verstehen und großartige Ideen zu generieren.

Ihr Ziel und die Aufgabe des Codes ist es, Werte zu schaffen und die Welt zu einem besseren Ort zu machen und Ihre egozentrische Vorstellung davon, wie die Welt sein sollte, nicht zu befriedigen.

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

Es ist besser, zuerst einen Nagel zu sehen, um die Notwendigkeit eines Hammers zu berücksichtigen.

Wenn Sie diesen Nagel wirklich hämmern müssen.