Schlechter Code, übermäßig komplizierter Erstellungsprozess, veraltete Technologien, schreckliche Programmiersprache - all diese und viele andere Probleme begleiten jedes ausreichend erfolgreiche Großprojekt, jeden Softwareentwicklungsprozess in jeder Organisation. Wie die Praxis zeigt, verschlechtert sich die Situation in den meisten Fällen nur mit der Zeit - kleinere Unannehmlichkeiten entwickeln sich zu unangenehmen „Merkmalen unserer Arbeit“, die Punktzahl steigt bei der Planung von Aufgaben ständig an und die Qualität des fertigen Produkts beginnt zu leiden. Der letzte Schliff für dieses Bild ist die Nichteinhaltung von Fristen und Plänen, da es entweder unmöglich ist, Funktionen zu debuggen oder sie sogar an die Arbeitsumgebung zu liefern. In solchen Situationen sagen wir oft, dass sich technische Schulden angesammelt haben.
Diese Verschuldung entsteht auf ganz natürliche Weise und verfolgt alle Systeme, egal wie erfolgreich sie sind, wenn das Produkt selbst, seine Benutzer und Kommunikationskanäle mit ihnen vorhanden sind. Es spielt keine Rolle, ob das Produkt direkt verkauft wird oder ob es ein Hilfsteil des Geschäfts des Unternehmens ist, es ist wichtig, dass es schon lange in Betrieb ist. Benutzer möchten neue Funktionen erhalten (vielleicht zahlen sie sogar dafür), das Management möchte den Benutzern diese so schnell wie möglich zur Verfügung stellen, da die Entwicklungsabteilung unter dem Druck von Fristen die erforderlichen Änderungen umsetzt. Der Vorgang wird viele Male wiederholt, und früher oder später wird jemand laut sagen: "Es scheint, wir haben eine Schuld, vielleicht eine technische!"
Jeder bemerkte, dass jede neue Aufgabe schwieriger ist als die vorherige, und dies ist kein Unfall mehr, die Komplexität wächst exponentiell. Es gibt „fragile“ Stellen im Code, die besser nicht berührt werden dürfen, häufiger Fehler von Benutzern und Alarme des Systems zur Überwachung der Arbeitsumgebung „ankommen“. Zunächst werden Initiativen zur Einführung neuer Technologien und Praktiken zur Verbesserung der Qualität des gesamten Produkts verschoben und dann völlig vergessen. Es entsteht die allgemeine Idee, dass etwas schief geht, die Suche nach den Gründen für das, was passiert und wer schuld ist, beginnt. Natürlich gibt es in diesem Zustand nichts Gutes, umso mehr - das Negative beginnt die Atmosphäre des Teams zu vergiften.
, , — , , , , , , , , , , .
, , , , , , . , — , ? , .
, . , . , , , - — , ? , ? ? , ? . , , , , — , . — .
— , , , , . , , . — . , IDE , , . .
— , :
- , ? - , .
- - , - , .
- , , .
- , .
- , , , , .
- - , , .
- , - , .
, — , , . . , — , , . , — , , .
. , , . — , . — . — ? .
“ ?”. ! , 100% — , - , , . , , , — 50/50, 60/40, . — , , .
, , — , , . ! ! ! — . .
, , — , .
, — , , , — . , — ? , , . , Flash — , , . , , — . , , , .
. — , , — , . , , . , … , .
, . , , , , , . , , - . , , , — , , , , “ ”, . ? , , . , , , — .
? — . , — . , , , . , .
— , : , , , .. , , . , , , . . , , , , , — , . , — , . — , . — , , , , .
— , , , . . , , , . , , , , — .
, , . — , , , . , . - Terra incognita, . - - , , , - ( ) . - , - , . , , .
, , . . , . , API. http- . — , - , offline-, - Selenium-, UI, . , API.
, , . — . , . API , , -, ? , ? , , — , — .
. , , , , — . , , — . , :
- ,
- ? - — . — , . “, ”: “ , , , , ”. , , “ ” , , , — , “” , . , ?
, — , API, .. — , - . . , , , , , , . , , .
, . — , , , . , , , , , , , , . , — , . , , - , , , , . , , , , , , — , . .
— , , . , , , , : , , . — , .
, , , , — , . , — , .
, , - . . — “”, “”. , , .
, , , . , , web-, , — , . , , , — “”? ? , ? , . , , ?
, , , — . Twitter, , , , , . , , . , Ruby on Rails, JVM, . .
, — , . , , , . , , , , . , (-, ) . , . , .
. , , . — , , , , . , . — , , — .
P.S.
Alles, was oben geschrieben wurde, gilt natürlich für große, funktionierende Softwareprodukte mit einer aktiven Benutzerbasis. Und nur in den Fällen, in denen es unmöglich ist, einfach eine neue Version des Produkts zusammen mit der alten zu veröffentlichen, wie es beispielsweise bei Basecamp und bei allen sogenannten war. "Boxed" Software.