Wie weit sollten wir Code und Daten umbenennen, wenn sich die Nomenklaturen der Endbenutzer ändern?

Vor langer Zeit haben wir eine Funktion hinzugefügt, mit der unsere Benutzer ein Bild "akzeptieren" konnten, nachdem es einer Workflow-Warteschlange hinzugefügt wurde. Es stellte sich heraus, dass wir den falschen Begriff verwendet haben und die Benutzer das Bild tatsächlich "genehmigen".

Das Ändern von Akzeptieren in Genehmigen auf unserer Benutzeroberfläche ist einfach. Ersetzen Sie einfach ein Wort. Wir haben jedoch alle Ebenen mit dem Wort "accept" programmiert, vom CSS-Klassennamen bis zu den Datenbankwerten.

• Die CSS-Klasse, mit der die Schaltfläche grün angezeigt wird: ".accepted";
• Die Modellmethode, die das Klassenattribut auf dem DOM-Knoten überprüft und bindet: "isAccepted";
• JavaScript-Statusattribut: Array mit "nicht überprüft", "akzeptiert" und "veröffentlicht";
• Mysql-Statusspalte: ENUM mit "nicht überprüft", "akzeptiert" und "veröffentlicht";
• Testnamen;

Es ist trivial (besonders wenn Sie Tests haben), die meisten Vorkommnisse von Accept zu Approve zu ersetzen. Etwas schwieriger ist es, die Daten zu migrieren, zumal sie mit der Bereitstellung synchronisiert werden müssen.

Dieser spezielle Fall ist einfach, aber ich habe während meiner Karriere ähnliche, aber komplexere Fälle erlebt. Wenn eine Datei ebenfalls umbenannt wird und die Bereitstellung auf Dutzenden von Servern erfolgt oder wenn Proxy-Caching, Memcached und MySQL beteiligt sind.

Auf jeder anderen Ebene mit Ausnahme der Benutzeroberfläche "akzeptiert" zu lassen, ist eine schlechte Idee, da neue Programmierer, die dem Team beitreten, möglicherweise nicht die historischen Gründe kennen, die zu dieser Entscheidung geführt haben wurde in "Warteschlange für das nächste Statustreffen" umbenannt, was sicherlich keinen Sinn ergeben würde. Und wenn wir hier und da Kompromisse eingehen, werden die Konzepte der Benutzeroberfläche in einigen Iterationen keinen Einfluss auf die Systeminternen haben, und ich möchte auf keinen Fall an einem System arbeiten, bei dem die Hälfte der Ausgabe keine Verbindung zu den Innereien hat.

Benennen Sie also bei Bedarf immer alles um? Wenn Ihnen das passiert ist und Sie entschieden haben, dass sich der Kompromiss nicht gelohnt hat, ist es dann zurückgekommen, um Sie zu beißen? Reichen Codekommentare oder Entwicklerdokumentationen aus, um dieses Problem zu vermeiden?

Für mich ist es definitiv das Beste, alles zu ändern, was mit dem fraglichen Gegenstand zu tun hat.

Es ist eine Form der Code-Verschlechterung, und während 1 Element, das nicht geändert wird, möglicherweise keine große Sache ist, gibt es den Ton für die Codebasis vor.

Dies könnte auch in Zukunft zu Verwirrung führen und es neuen Entwicklern erschweren, die Codebasis / -domäne zu verstehen.

Anhand der Frageninhalte und Tags gehe ich davon aus, dass Sie eine allgegenwärtige Sprache verwenden.

Meiner Erfahrung nach ist UL großartig, kann aber, wie Sie bereits erwähnt haben, mit der Weiterentwicklung der Sprache zu zusätzlichen Wartungsaufgaben führen. Das ist an sich keine schlechte Sache. Sicher, es ist unpraktisch, aber es wird auch erwartet.

Was ich normalerweise getan habe (und gesehen habe), ist entweder:

• 1-Schuss-Refactoring im Voraus: Refactoring aller Ebenen der Anwendung, um die aktualisierte Sprache zu übernehmen. oder
• Technische Schulden protokollieren: Sie können den benutzerbezogenen Code sofort ändern und dann Aufgaben für technische Schulden protokollieren, um den Rest der Anwendungsebenen mit der aktualisierten Sprache in Einklang zu bringen. Dies führt in der Regel zu einer Handvoll langweiliger (aber handhabbarer) Aufgaben. (Perfekt für 17 Uhr!)

Ich denke, der Schlüssel ist, dass Sie technische Schulden beschreiben und als solche anerkannt werden sollten.

Ich hatte Manager, die argumentiert haben, dass wir keine Zeit mit so einfachen Aufgaben verschwenden sollten, die keine sichtbaren Funktionen hinzufügen. Dies ist, wenn die Schulden Analogie wirklich nützlich ist. Es läuft darauf hinaus:

Das Team entschied sich für DDD mit Ubiquitous Language. Wenn Sie von diesem Ansatz abweichen, indem Sie den Code in einem inkonsistenten Zustand belassen, wird Verwirrung gestiftet und viele der Vorteile, die DDD und UL bieten, werden beseitigt. In Bezug auf den Manager erhöht dies die Projektkosten. Die Verwaltung des Codes wird schwieriger (teurer) und für neue Entwickler verwirrender (teurer).

Möglicherweise möchten Sie sich die Optionen für die Lokalisierung (l10n) ansehen. Es mag nicht so drastisch erscheinen, als würde man vom Englischen ins Spanische wechseln, aber Sie haben es mit einem anderen Begriff für dasselbe Konzept zu tun. Wenn dies häufig vorkommt, können Sie mit l10n schnell ändern, was auf der Benutzeroberfläche angezeigt wird, ohne den im Code verwendeten Begriff ändern zu müssen.

Verwenden Sie dazu einfach die Begriffe in Ihrem Code, die am besten verstanden werden. Wählen Sie Namen aus der Domäne aus, wie Entwickler sie kennen und vielleicht erwarten.

Wenn Sie dies angemessen darstellen, ist es eine ziemliche Investition, Änderungen der Endbenutzernomenklatur in jedem Teil der Quelle zu verfolgen. Es lohnt sich jedoch auf jeden Fall, insbesondere für ein langlebiges Produkt, das von einer vollständigen Infrastruktur (mit Hotline, Testern usw.) entwickelt wurde.

Die Verfolgung der Endbenutzernomenklatur in der Quelle ist eine Investition, da es so viele Komponententypen gibt, in denen sie vorkommt, und kein Zauberstab gleichzeitig an all diesen Komponenten arbeitet. Vielleicht ist die Entwicklung eines solchen Zauberstabs von Komponente zu Komponente eine interessante Investition, die Sie über die gesamte Laufzeit des Projekts hinweg verwässern können.

Ich habe an einer 30 Jahre alten Codebasis gearbeitet, in der die Abweichung zwischen der Endbenutzernomenklatur und der internen Nomenklatur besonders groß wurde. Hier sind einige Nachteile dieser Situation, die den Arbeitsaufwand für alle erhöhen:

1. In Ermangelung einer angemessenen Richtlinie wird bei Neuentwicklungen in der Regel die derzeitige Endnutzernomenklatur verwendet. Daher kann dasselbe Konzept zwei oder mehr Namen in verschiedenen Komponenten haben. Da die Komponenten zusammenwirken, sind in einigen lokalen Teilen des Codes mehrere synonyme Namen gleichzeitig vorhanden.

2. Wenn die Hotline / das Helpdesk angerufen wird, notieren sie eine User Story unter Verwendung der Endbenutzernomenklatur. Der Entwickler, der für die Behebung des Problems verantwortlich ist, muss die Endbenutzernomenklatur entsprechend der Quellennomenklatur übersetzen. Natürlich ist es nicht archiviert und natürlich ist es ein Durcheinander. (Siehe 1.)

3. Wenn der Programmierer den Code debuggt, möchte er in relevanten Funktionen Haltepunkte setzen. Es ist schwierig, die geeigneten Funktionen zu finden, wenn die Endbenutzernomenklatur und die Quellennomenklatur nicht übereinstimmen. Es kann sogar schwierig oder unmöglich sein, sicher zu sein, dass eine Auflistung der relevanten Funktionen vollständig ist. (Siehe 1.)

4. In Ermangelung einer angemessenen Richtlinie wird durch die Pflege der Quelle unter Verwendung einer überholten Nomenklatur diese überholte Nomenklatur von Zeit zu Zeit wieder den Benutzern zur Verfügung gestellt. Dies erzeugt einen schlechten Eindruck und verursacht Overhead.

Ich habe bereits zwei Tage lang die Stelle ausfindig gemacht, an der einige Daten aus der Datenbank gelesen und in eine Komponente dieser Codebasis eingefügt wurden. Weil weder ich noch jemand in der Firma, in der ich gearbeitet habe, einen Namen finden konnte, der zu diesem Ort führte, entließ ich mich schließlich und beschloss, eine andere Lösung für dieses Problem zu finden.

Obwohl die Kosten für eine Wartung von mehr als [1] zwei Tagen ohne Ergebnis (kein Wissen, keine Fehlerbehebung, nichts) wahrscheinlich so hoch wie möglich sind, erhöhen Abweichungen zwischen der Anwendernomenklatur und der Quellennomenklatur den Aufwand für viele Routineaufgaben bei der Wartung von eine Software.

Es ist wichtig zu bemerken, dass die Gemeinkosten mit dem Unternehmen, das die Software herstellt, steigen. In einem großen Unternehmen kommt ein Problembericht erst dann auf Ihrem Schreibtisch an, wenn er von mehreren Kollegen geprüft wurde und der Fix möglicherweise getestet werden muss.

[1] Da mehr als ein Entwickler beteiligt ist.

Ich benenne Code und Daten nicht immer um, da einige Pakete von Kunden gemeinsam genutzt werden. Sie benutzen im Grunde dasselbe, nennen es aber anders. Beispiel: In einem CMS nennt ein Client seinen Kunden "Kunde" und ein anderer "Client". Aus diesem Grund haben wir Kunden an der Oberfläche für einen Kunden durch Kunden ersetzt, aber CMS wird immer ein Kundenmanagementsystem sein.

Ein weiteres Beispiel ist die Benutzerverwaltung mit Begriffen wie "Berechtigungen" oder "Zugriffssteuerungsliste", "Administrator" oder "Manager". Für Neueinsteiger kann dies verwirrend sein. Für Kernkomponenten wie diese gibt es jedoch in der Regel Kernentwickler, die sicherstellen, dass diese Komponenten für alle Clients und Benutzer funktionieren auch von anderen Entwicklern einfach zu implementieren (zB durch Erstellung konfigurierbarer Labels).

Es könnte hilfreich sein, sich vorzustellen, dass Sie diese Änderung hoffentlich nicht noch einmal vornehmen müssen, wenn dasselbe Teil von einem anderen Kunden verwendet wird, sodass es im Grunde genommen zu einem Produkt wird.