Gibt es spezifische "technische Schulden", die sich nicht lohnen?

Question

Es gibt (mindestens) zwei Möglichkeiten, wie technische Schulden in Projekte einfließen. Das erste ist durch bewusste Entscheidung. Einige Probleme sind es einfach nicht wert, an vorderster Front angegangen zu werden, daher dürfen sie sich bewusst als technische Schulden akkumulieren. Die zweite ist durch Unwissenheit. Die Personen, die an dem Projekt arbeiten, wissen nicht oder nicht, dass sie technische Schulden haben. Diese Frage beschäftigt sich mit der zweiten. Gibt es technische Schulden, die du in dein Projekt einbringen würdest, die trivial wären ("Wenn ich nur gewusst hätte ..."), aber sobald sie in das Projekt eingebettet waren, wurden sie dramatisch teurer?

Answer 1

Kein Web-Projekt starten mit einem Javascript-Framework und Hand implementieren Sachen, die bereits verfügbar war. Die Pflege der handschriftlichen Javascript wurde genug von einem Schmerz, dass ich am Ende rippte und es mit dem Rahmen wiederholen.

Answer 2

Ein Beispiel hierfür ist das Ausführen einer Datenbank in einem Modus, der Unicode nicht unterstützt. Es funktioniert bis zu dem Zeitpunkt, zu dem Sie Unicode-Zeichenfolgen in Ihrer Datenbank unterstützen müssen. Der Migrationspfad ist abhängig von Ihrer Datenbank nicht trivial.

Zum Beispiel hat SQL Server eine feste maximale Zeilenlänge in Bytes. Wenn Sie also Ihre Spalten in Unicode-Zeichenfolgen konvertieren (NCHAR, NVARCHAR usw.), ist möglicherweise nicht genügend Platz in der Tabelle, um die Daten zu speichern bereits. Jetzt muss Ihr Migrationscode eine Entscheidung über die Kürzung treffen, oder Sie müssen das Tabellenlayout vollständig ändern. So oder so, es ist viel mehr Arbeit, als nur mit allen Unicode-Strings zu beginnen.

Answer 3

Nicht ein zusammenhängendes Design im Vordergrund neigt dazu, zu ihm zu führen. Sie können es bis zu einem gewissen Grad überwinden, wenn Sie sich die Zeit nehmen, häufig zu refaktorieren, aber die meisten Menschen greifen immer wieder auf ein Gesamtdesign zurück, das nicht ihren wechselnden Anforderungen entspricht. Dies kann eine allgemeinere Antwort sein, als was Sie suchen, aber neigt dazu, eine der beliebtesten Ursachen für technische Schulden zu sein.

Answer 4

Bei einer früheren Firma verwendeten und erzwungene COM für Sachen, für die es nicht benötigt wurde.

Eine andere Firma mit einer C++ Codebasis erlaubte STL nicht. (WTF ?!)

Ein anderes Projekt, auf dem ich war, machte MFC nur für die Sammlungen - No UI war beteiligt. Das war schlecht.

Die Auswirkungen natürlich für diese Entscheidungen waren nicht groß. In zwei Fällen hatten wir grundlos Abhängigkeiten von erbärmlichen MS-Technologien und die anderen zwangen die Menschen, schlechtere Implementierungen von Generika und Sammlungen zu verwenden.

Ich klassifiziere diese als "Schulden", da wir aufgrund der idiotischen Entscheidungen im Vorfeld Entscheidungen und Abwägungen in den Projekten treffen mussten. Die meiste Zeit mussten wir die Mängel beheben.

Answer 5

Auch wenn nicht jeder zustimmen kann, denke ich, dass der größte Beitrag zu technischen Schulden von der Schnittstelle jeder Art von Anwendung ausgeht und im Stapel läuft. Ich bin zu der Erkenntnis gelangt, dass die Wahrscheinlichkeit einer Abweichung von den Projektzielen durch die Kombination von TDD und DDD geringer ist, da die Kernfunktionalität immer noch entwickelt und getestet werden kann, wobei die Schnittstelle zum Icing wird.

Zugegeben, es ist keine technische Schuld an sich, aber ich habe festgestellt, dass Top-down-Entwicklung eher eine offene Tür ist, die zu Entscheidungen, die nicht gut durchdacht sind - alles um etwas zu tun Das sieht cool aus. Außerdem verstehe ich, dass nicht jeder zustimmen wird oder dass es sich genauso anhört, so dass Ihre Meilenzahl in diesem Fall variieren könnte. Teamdynamik und -fähigkeiten sind ebenfalls ein Teil dieser Gleichung.

Answer 6

Sicherheitsprobleme vollständig ignorieren.

Cross-Site-Scripting ist ein solches Beispiel. Es gilt als harmlos, bis Sie alert('hello there!') in der Admin-Oberfläche erscheinen (wenn Sie Glück haben - Skript kann auch still kopieren alle Daten, die Administratoren Zugriff haben, oder dienen Malware zu Ihren Kunden).

Und dann brauchen Sie 500 Vorlagen behoben gestern. Übereiliges Fixieren führt dazu, dass Daten doppelt maskiert werden und nicht alle Sicherheitslücken schließen.

Answer 7

ich mit diesem einen wirklich zu kämpfen, versuchen YAGNI Gleichgewicht versus „Ich habe auf dieses eine Mal zu oft verbrannt worden“

Meine Liste der Dinge, die ich bei jeder Anwendung eine Bewertung

1. Lokalisierung:
   2. Wird die Zeitzone jemals wird wichtig sein? Wenn ja, Datum/Uhrzeit in UTC beibehalten.
   3. Werden Nachrichten/Text lokalisiert? Wenn ja, Nachrichten externalisieren.
2. Plattform Unabhängigkeit? Wählen Sie eine einfach zu portierende Implementierung aus.

Andere Bereiche, in denen technische Schuld entstehen werden können, gehören:

• Schwarz-Loch Datensammlung: Alles geht in, geht nie etwas aus. (Kein langfristiger Plan zum Archivieren/Löschen alter Daten)
• Fehler bei der Trennung von MVC oder Tiers während der Anwendungslebensdauer - z. B. zu viel Logik, um in die View zu gelangen und eine Schnittstelle für mobile Geräte oder Web-Services viel teurer.

Ich bin sicher, dass es andere sein ...

Answer 8

Speichern von Daten in einer Datenbank in der lokalen Zeitzone. Irgendwann wird Ihre Anwendung in eine andere Zeitzone migriert und Sie werden in Schwierigkeiten geraten. Wenn Sie jemals gemischte Daten haben, werden Sie nie in der Lage sein, sie zu entwirren. Speichern Sie sie einfach in UTC.

Answer 9

Skalierbarkeit - insbesondere datengesteuerte Geschäftsanwendungen. Ich habe mehr als einmal gesehen, dass alles gut zu laufen scheint, aber wenn die UAT-Umgebung schließlich mit Datenbanktabellengrößen aufgehalten wird, die sich Produktionen nähern, fallen die Dinge rechts und links nach unten. Es ist einfach für einen Online-Bildschirm oder Batch-Programm zu laufen, wenn die Datenbank im Grunde alle Zeilen im Speicher hält.

Answer 10

Unit Testing - Ich denke, dass das Verfehlen von Tests, wie Sie gehen, eine riesige Schulden macht, die schwer zu machen ist. Obwohl ich ein TDD-Fan bin, ist es mir egal, ob Sie Ihre Tests vor oder nach der Implementierung des Codes schreiben ... solange Sie Ihre Tests mit Ihrem Code synchronisieren.

Answer 11

Das Klischee ist, dass vorzeitige Optimierung ist die Wurzel allen Übels ist, und das ist sicherlich richtig für micro -optimierung. Es kann jedoch eine schlechte Idee sein, die Leistung auf Design-Ebene in einem Bereich, in dem es eindeutig darauf ankommt, völlig zu ignorieren.