Heute ist ein sonniger Tag. Sie fahren die Straße entlang zu Ihrem Dorf, in dem all Ihre Freunde, Ihre Familie und Ihr geliebter Hund leben. Ein wunderschöner Tag! Plötzlich hört man einen schrecklichen Alptraumschrei, der die Umgebung zerreißt. Die riesige ekelhafte Hydra nähert sich dem Dorf, um es zu zerstören! Du nimmst ein Schwert (natürlich hast du ein Schwert!) Und versuchst, jeden zu beschützen, den du liebst. Aber es gibt ein kleines Problem: Das Monster hat viele Köpfe, und wenn Sie einen davon abhacken, wächst schnell ein neuer!

Es scheint, dass Sie diesen Kampf nicht gewinnen können. Vielleicht kannst du lange genug mit Hydra spielen, damit das ganze Dorf Zeit hat, vor einer schrecklichen Bedrohung davonzufliegen? Endlich wirst du ein echter Held der ganzen Welt! Wer will das nicht?

Die Rolle von Hydra ist Entropie in Software: Es ist Ihr Feind, er erschöpft Sie, aber Sie können es nie ganz loswerden. Sie müssen jedoch noch mit ihm kämpfen, damit Ihre Bewerbungen (und Kollegen) gesund und vernünftig bleiben.

Wir werden herausfinden:

1. Was ist Entropie in Software und wie merkt man das in Ihrem Code?
   
2. Was sind die möglichen Ursachen und wie kann man die Entropie niedrig halten?
   

Genug geredet, auf den Punkt!

Kenne deinen Feind

Was ist Entropie und wie kam es zu meiner Bewerbung?

Manchmal ist es nützlich, die Etymologie der verwendeten Wörter herauszufinden, insbesondere solche wie Entropie. Aus dem Griechischen übersetzt bedeutet es "Transformation". Ändern Sie. Daran sollten Sie sich als Softwareentwickler gewöhnen.

Die Entropie bezieht sich auf den zweiten Hauptsatz der Thermodynamik. Es heißt, dass in einem geschlossenen, isolierten System das Chaos mit der Zeit nicht abnimmt. Es bleibt stabil oder wächst.
Die Idee der Entropie in Software entstand durch das Buch Object-Oriented Software Engineering . Je mehr sich das Programm ändert, desto mehr Chaos herrscht, desto größer wird die Entropie.

Das Erste, was arme Entwickler uns klar machen müssen, ist die tragische Wahrheit: Wir können die Menge an Entropie in unseren Programmen bekämpfen, aber wir können sie niemals loswerden.

Bilden Sie das beste Team (natürlich mit Ihrer Teilnahme!), Das beste Umfeld, das beste Management, die beste Unternehmenskultur, das beste Projekt. Was wird im Laufe der Zeit passieren?

1. Sie werden jeden Morgen summen: "Dies ist das beste Projekt!" Ein grünes Projekt, das aussieht wie ein wunderschönes Feld, beleuchtet von einem wunderschönen Sonnenaufgang.
   
2. Sie und das Team werden immer mehr Funktionen hinzufügen. Da Sie die Besten der Besten sind, sieht für eine Weile alles gut aus.
   
3. Monate oder Jahre vergehen. Niemand will mehr an einem Projekt arbeiten. Auch wenn es gut entworfen wurde, die Technologie veraltet ist, das Projekt zu viel Aufwand und Zeit erfordert, um es zu verstehen, ist es teuer zu skalieren. Es ist zu schwierig, sein gutes mentales Modell aufzubauen.
   

Wie haben Sie diese Komplexität geschaffen? Sie müssen nur das Projekt skalieren. Mehr Elemente bedeuten oft mehr Abhängigkeiten und höhere Komplexität. Ich habe bereits einen ausführlichen Artikel darüber geschrieben.

Wenn Sie dies Lyokha, Ihrem Mitentwickler, erklären, wird er antworten:

"Nifiga! Du bist dumm? Chaos und Unordnung haben in meiner schönen App keinen Platz! Mein Ruf wird nicht durch irgendeinen Unsinn getrübt! Ich bin der Meister meines Schicksals! Wenn ich mein Programm nicht ändere, wird die Komplexität nicht größer, und im Zusammenhang mit diesem Widerspruchsbeweis erkläre ich, dass Sie sich geirrt haben, und ich bin der Beste! “

Sie können Lyokha ruhig, überzeugend und entschlossen erklären, dass sich alles ändern wird, auch wenn Sie das Programm nicht ändern. Wenn Bibliotheken von Drittanbietern nicht aktualisiert werden, treten Sicherheitsprobleme auf. Und wenn Sie sie aktualisieren, öffnet sich die Tür für Veränderung und Entropie.

Wenn Sie eines Tages nach langer Zeit etwas an Ihrer Software ändern müssen, werden Sie sich nicht mehr an alle Details erinnern. Und selbst die beste Dokumentation wird Ihnen nicht helfen. Die Welt hat sich verändert, und was gestern wahr war, kann niemals wahr sein, sowohl auf technologischer als auch auf geschäftlicher Ebene.

Solche Veränderungen bringen sofort eine große Menge an Entropie mit sich.

Die Frage ist also nicht, es loszuwerden, sondern in Maßen. Dies ist eine echte Schlacht, in die wir Entwickler geraten.

Definition von Entropie in Software

Software-Qualität

Wie stellen Sie fest, dass Ihre Anwendung ein hohes Maß an Entropie aufweist? Ein guter Indikator ist die Qualität des Codes.

Was ist das und wie kann man es messen? Laut Accelerate: Die Wissenschaft hinter den Entwicklern :

• Wenn das Verhältnis von Änderungen / Fehlern zunimmt, nimmt die Qualität ab. Verfolgen Sie Änderungen, Fehler und Abstürze und vergleichen Sie sie miteinander. Wenn jede Änderung zu neuen Fehlern oder Abstürzen führt, erhöht sich die Entropie in Ihrem Programm.
  
• Eine wichtige Rolle spielt dabei die subjektive Wahrnehmung des Projekts durch die Entwickler. Wenn jeder das Gefühl hat, dass es immer schwieriger wird, die Anwendung zu skalieren, ohne sie zu brechen, ist die Entropie wahrscheinlich hoch. Diese Empfindung sollte jedoch weit verbreitet sein.
  
• Wenn das Team viel Zeit damit verbringt, Fehler zu beheben oder Fehler zu beheben, muss Entropie ein Nest in Ihrer Anwendung erstellt haben.
  

Wenn Sie Informationen über das Verhältnis von Änderungen und Fehlern erhalten und Zeit damit verbringen, Fehler zu beheben, können Sie einen guten Zeitplan erstellen, um das Management von der Notwendigkeit einer Umgestaltung zu überzeugen.

Dämon der Schwierigkeit

Selbst wenn Sie Code von höchster Qualität haben, kann sich die Komplexität leicht erhöhen, wenn es um die eigentlichen Funktionen des Programms geht. Das Geschäft selbst ist eine Quelle der notwendigen Komplexität , die Sie nicht loswerden können.

Angesichts der übermäßigen Komplexität des Geschäfts müssen Entwickler viel Mühe aufwenden, um ein gutes mentales Modell des Geschäfts des Unternehmens zu erstellen. Daher werden sie Fehler machen, wenn sie versuchen, Geschäftsanforderungen in Code zu übersetzen.

Sprechen wir genauer über die Komplexität des Geschäfts: Brauchen wir wirklich all diese komplexen Funktionen, die uns im Stich lassen?

Der Grund für die Entropie und wie man damit umgeht

Entropie-Wasserfall

Das problem

Mehr oder weniger offensichtlich sind die Entwickler selbst die Hauptursache für Entropie in Software. Sie sind faul, sie sind nicht qualifiziert, besonders Sanka, mit der Sie arbeiten. Er stellt so viele Fragen!

Ich stimme dieser Meinung überhaupt nicht zu. Meiner Erfahrung nach ist der Hauptgrund für die Entropie die Führung, insbesondere in Unternehmen mit einem Wasserfallmanagementstil.

Wie Gerald Weinberg in The Secret of Consulting feststellte:

Auch wenn es sich um ein rein technisches Problem handelt, kann sein Ursprung immer auf die Handlung oder Untätigkeit des Managements zurückgeführt werden.

Ich weiß, was Sie dachten: „Sie irren sich! Das Management ist nicht immer für alles verantwortlich! Es ist nur praktisch für Entwickler, die Chefs für alles verantwortlich zu machen! “

Ich sage nicht, dass die Führung für alles verantwortlich ist, aber er hat immer ein gewisses Maß an Verantwortung . Hat der Entwickler etwas Schlimmes getan? Sie müssen den Einstellungsprozess überprüfen. Die Spezifikationen wurden schlecht umgesetzt? Vielleicht wissen einige der Führer nicht, was sie wirklich wollen, und deshalb sind ihm die Spezifikationen egal.

Deshalb ist es so schwierig, ein Führer zu sein! Je größer Sie in der Hierarchie sind, desto schwieriger ist es.

Wie stark beeinflussen Sie als Entwickler die Entscheidungsfindung? Wenn 100%, dann Glückwunsch, sind Sie für alles schuld. Wenn bei 0%, dann ist Ihre Schuld nicht. Zwischen diesen Polen liegt das gesamte Einflussspektrum. Und der Wasserfall impliziert nicht viel davon.

Verwenden Sie Scrum, Kanban und Poker Planning? Natürlich benutzt du den Wasserfall nicht! Sie verwenden Agile wie ein Kind, das mit einem Schraubenzieher ein Haus baut.

Natürlich sind Tools wichtig, aber ihre Bedeutung ist viel geringer als die Bedeutung Ihrer Denkweise , die für die korrekte Softwareentwicklung erforderlich ist. So zitieren Sie das Agile-Manifest:

Persönlichkeiten und Interaktionen sind wichtiger als Prozesse und Werkzeuge.

Das Verwenden von Scrum bedeutet nicht, dass Sie Agile verwenden, insbesondere wenn Sie nicht der Meinung sind, dass diese Methode zu lehren versucht.

Mit dem Management von Wasserfällen trifft jemand, der über Ihnen liegt, eine Entscheidung, andere treffen neue Entscheidungen und so weiter.

Auf den unteren Ebenen der Hierarchie befinden sich Mitarbeiter, deren Fluch darin besteht, alle getroffenen Entscheidungen zu verfolgen. Was ist ihre Aufgabe? Zu machen, als ob Arbeiter am Fließband einer Autofabrik arbeiten. Sie müssen nicht denken, sie müssen Autos bauen .

Schlechte Nachrichten: Als Entwickler stehen Sie ganz unten in der Hierarchie.

Wenn jemand an der Spitze Entscheidungen über die Funktionen der Anwendung trifft und Sie praktisch keine Gelegenheit haben, den Entscheidungsprozess zu beeinflussen, dann heißen wir Sie am Wasserfall willkommen! Leider sieht die Geschäftsleitung in den meisten Fällen nicht, dass es in der Welt der Softwareentwicklung keine Produktionsphase gibt . Entwickler sind mit der Konstruktion des Systems beschäftigt , und diese Aufgabe ist weit entfernt von der Förderanordnung der Kabine.

Warum? Denn im Gegensatz zum Auto ändern sich die Anwendungen ständig! Sie müssen sie korrekt entwerfen , damit sie funktionieren, den Anforderungen der Benutzer entsprechen, dass Anwendungen eine akzeptable Leistung aufweisen, skalierbar und veränderungsresistent sind und gleichzeitig die Entropie auf einem niedrigen Niveau bleibt. Zu diesem Zweck müssen Sie viele Entscheidungen darüber treffen, wie Sie die Geschäftskenntnisse in Ihrem Code widerspiegeln .

Wenn Sie die Komplexität, die die Führung für Sie darstellt, nicht beeinträchtigen, müssen Sie sich viel Mühe geben, um sie im Code zu verwalten. Dies wird als eine „notwendige“ Komplexität angesehen, die nicht vermieden werden kann.

Mögliches Ergebnis? Entropieniveaus können sehr, sehr schnell wachsen.

Mögliche Lösung

Das Unternehmen muss die gemeinsame Entscheidungsfindung und Verantwortung so aktiv wie möglich üben.

Wenn Sie Ihre Firma in dem von mir beschriebenen Wasserfallmodell wiedererkennen, müssen Sie mit denen sprechen, die die Entscheidungen treffen:

• Geben Sie Daten und überzeugende Argumente an, warum und wie Sie Feature X oder Y vereinfachen können. Erläutern Sie den möglichen Preis für die Entwicklung eines komplexen Features jetzt und in Zukunft .
  
• Erklären Sie, warum die agile Softwareentwicklung bedeutet, dass Menschen zusammenarbeiten müssen. Manager, Designer, Entwickler und alle anderen sollten in Abhängigkeit von den geschäftlichen Anforderungen Teil des Entscheidungsprozesses sein.
  
• Wenn Ihre Führung das Angebot automatisch ablehnt, müssen Sie verstehen, warum es geschah. Fragen stellen.
  
• Sprechen Sie darüber, was Entscheidungsträger für das Wichtigste halten: Geld und Zeit. Zeigen Sie ihnen, dass agiles Denken (und nicht nur Tools) Sie beide retten kann.
  

Es ist jedoch schwierig, das Problem zu lösen, wenn Sie nicht danach gefragt wurden. Viele Manager sind sehr zufrieden mit dem Wasserfallmodell und wissen oft nicht einmal, dass sie es befolgen. Sie brauchen viel Diplomatie und Fingerspitzengefühl.

In Anbetracht dessen rate ich Ihnen, einen anderen Job zu suchen, wenn Sie der Meinung sind, dass Geschäftslösungen Ihrer Anwendung zu viel Komplexität verleihen und Sie selbst dann nichts dagegen unternehmen können, wenn Sie es versuchen. Es ist anstrengend - jeden Tag mit hoher Entropie zu arbeiten und aus Vergnügen ein aufgeblähtes Produkt zu machen, ist nicht genug ... oder es zu benutzen. Dies kann Ihnen einen Hinweis auf den Erfolg geben, den Ihr Produkt erwartet.

Und das Letzte: Was auf Unternehmensebene kompliziert aussehen kann, lässt sich vereinfachen, wenn Sie die Geschäftsprozesse gut kennen. Das ist extrem wichtig. Erfahren Sie daher mehr über die Aktivitäten Ihres Unternehmens, was sie tun und was nicht. Dies vereinfacht die Funktionen und die Codebasis.

Während wir unsere Architektur ausdrücken, erklären wir dem Computer etwas. Und dafür müssen wir gut verstehen, was wir erklären.

Donald Whip

Codequalität und technische Pflicht

Das problem

Zusätzlich zu der „notwendigen“ Komplexität, die das Geschäft mit sich bringt, hängt die Entropie in Software eng mit der Codequalität und der technischen Verschuldung zusammen.

Was sind technische Schulden? Einfach ausgedrückt, dies sind Vereinfachungen (Hacks), die Sie verwenden, um Zeit zu sparen, da Sie wissen, dass dies später auf Sie zurückkommen kann. Besonders in Fällen, in denen andere Funktionen von diesen Hacks abhängen: Sie müssen sie mit Zinsen wie mit echten Schulden in Form von Schwierigkeiten und Kopfschmerzen beheben.

Abhängig von der Aufgabe Ihrer Anwendung kann die technische Verschuldung mehr oder weniger akzeptabel sein. Wenn das Programm ein paar Monate durchhält, kann man überhaupt nicht an technische Schulden, Entropie oder Qualität denken. Fügen Sie einfach die Code-Teile zusammen und Sie sind fertig!

Dies kann beispielsweise eine vorübergehende Lösung sein, bevor eine komplexere Anwendung von Grund auf erstellt wird. Oder Sie können schnell einen Prototyp schreiben, um die Idee zu veranschaulichen, und dann alles neu schreiben oder das Konzept aufgeben.

Andererseits möchten Unternehmen in der Regel Anwendungen entwickeln, die eine längere Lebensdauer haben. Dies ist sinnvoll: Das Neuschreiben einer Anwendung kann sehr teuer sein (insbesondere, wenn sie groß ist), und niemand kann garantieren, dass ihr Entropie-Level niedriger ist. Kopieren ist ein sehr riskantes Geschäft.

In solchen Fällen müssen Sie mit der technischen Leistung und der Codequalität sehr vorsichtig sein. Dies ist ein wichtiger Teil Ihrer Arbeit als Entwickler.

In dem berühmten Buch The Pragmatic Programmer (in dem unter anderem das DRY-Prinzip vorgestellt wird) wird eine interessante Analogie der technischen Verschuldung angegeben. Hier wird eine Studie beschrieben, die die Zerstörung städtischer Gebäude mit ... Fenstern vergleicht, die aus ihnen herausgeschlagen wurden. Das zerbrochene Fenster vermittelt den Eindruck von Verlassenheit und inspiriert jeden Mobber in der Gegend. Infolgedessen werden Gebäude mit zerbrochenen Fenstern schneller zerstört als Gebäude mit ganzen Fenstern.

Technische Schulden sind eine Vereinfachung oder ein Hack in Ihrem Code, ein zerbrochenes Fenster. Wenn ein anderer Entwickler, oder sogar Sie selbst, dies bemerken, besteht die Versuchung, noch mehr technische Schulden zu machen, weil "es hier immer noch einen schlechten Code gibt, warum also ein Dampfbad nehmen?"

Beispiel: Sie haben eine Problemumgehung für einen komplexen Fehler geschrieben, da keine Zeit war, danach zu suchen. Ein anderer Entwickler (oder Sie selbst später) kann zusätzlich zu dieser Problemumgehung einen anderen Code schreiben, um ein anderes Problem zu lösen. Es werden mehrere Problemumgehungen entstehen, die niemand so schnell herausfinden wird.

Lösung

Erstens, woher wissen Sie, ob ein Code technische Schulden hat?

Fragen Sie sich:

• Kann ich einfach und logisch erklären, was der Code bewirkt?
  
• Werden hier die richtigen Namen verwendet? Helfen sie dabei zu erklären, was der Code bewirkt?
  
• Treffen lange Namen mit "und" zu, wie "deleteUserAndShutDown"? Dies ist ein gutes Zeichen dafür, dass Sie eine Funktion, eine Methode oder eine andere Konstruktion trennen müssen.
  
• Fühlt es sich an, als ob ein Code aus Faulheit hinzugefügt wurde? Verstößt es gegen Logik und beeinträchtigt das Verständnis?
  

Je mehr Ihr Wissen und Ihre Erfahrung zunehmen, je neugieriger Sie sind und je häufiger Sie mit anderen Entwicklern gute Gespräche führen, desto häufiger werden Sie Muster technischer Verschuldung bemerken. Dies ist ein Code mit einer Drossel .

Wenn Sie auf solche Muster stoßen, betrachten Sie sie bitte nicht als Erlaubnis, noch mehr technische Schulden hinzuzufügen:

1. Eine Erhöhung der technischen Dauer wird zu neuen Problemen führen. Sie werden zurückkehren und Sie (und Ihr Team) noch mehr verfolgen.
   
2. Eine technische Schuld beglichen, umgestalten. Dies ist die beste Option. Wenn Sie keine Zeit oder Energie haben, fügen Sie einfach einen Kommentar hinzu // TODO: refactor aus diesem und diesem Grund. Melden Sie ein Problem, lassen Sie es nicht in der Codebasis verborgen.
   

Vergessen Sie nicht, dass Sie parallel zur Entwicklung anderer Features eine Umgestaltung vornehmen müssen, damit sie mit der aktuellen Architektur übereinstimmen. Vereinfacht gesagt sollte die Reparatur von technischen Schulden keine eigenständige Aufgabe sein, sondern ein fortlaufender Prozess, der möglicherweise nicht mit der aktuellen Aufgabe zusammenhängt. Gewähren Sie sich bei der Entwicklung eines Features das Recht, die aufgetretenen technischen Probleme zu beheben.

Überarbeiten Sie jeweils kleine Codestücke und führen Sie häufig Tests durch, um sicherzustellen, dass sich das System wie erwartet verhält.

Schließlich benötigen Sie beim Refactoring möglicherweise einige gute Argumente:

1. Erstens für dich. Es ist leicht zu glauben, dass Ihr Kollege nicht programmieren kann und dass Sie es besser wissen als andere. Wenn Sie jedoch die spezifischen Vorteile des Refactorings nicht erkennen, tun Sie dies nicht. Vielleicht liegt das Ganze nur in deinem Ego und du kannst etwas ruinieren.
   
2. Wenn sich das Refactoring auf den Codestil bezieht, hat Ihr Team ihn nicht klar definiert. Treffen Sie sich und entscheiden Sie gemeinsam, welchen Codestil Sie übernehmen möchten. Dies muss irgendwo aufgeschrieben werden, damit jeder nach Bedarf damit umgehen kann. Bearbeiten Sie die Vereinbarung gemäß den Anforderungen des Teams. Andernfalls wird Ihr Code mit Kommentaren wie „Wir verwenden Tabulatoren !!! NICHT SPACES !!!!! 11! 1 !!! ”. Dies ist ein unnützes Geräusch.
   
3. Wenn Sie jemand fragt, warum Sie seinen schönen Code geändert haben, haben Sie schließlich echte Argumente, um Ihre Entscheidung zu erklären.
   

Gute Argumente spielen in Zukunft immer eine positive Rolle. Beispiel: Binden Sie eine Bibliothek eines Drittanbieters so ein, dass die Codebasis nicht beschädigt wird. Wenn Sie nicht verstehen, warum ich von einem Leck spreche, lesen Sie, was ich über Abstraktionen geschrieben habe .

Für uns Menschen ist es schwierig, mittel- und langfristig Vorhersagen zu treffen. Daher ist es nicht immer einfach, etwas mit Blick auf eine unbekannte Zukunft umzugestalten oder zu „verkaufen“.

Technische Pflicht spiegelt den Dualismus zwischen einfachem und richtigem Weg wider. Der erste ist schnell und attraktiv, der zweite macht Ihr Projekt skalierbar und einfach zu warten. Sie benötigen Selbstdisziplin , um den zweiten Weg so oft wie möglich zu wählen. Andernfalls wird die Zukunft mit Leiden gefüllt sein.

Wenn Sie zu müde, verärgert oder voller anderer Gedanken oder Emotionen sind, die Ihre Motivation verringern, den richtigen Weg einzuschlagen, und nicht den einfachen, ist es besser, noch nicht zu programmieren. Machen Sie einen Spaziergang, sprechen Sie mit Kollegen, machen Sie eine Pause. Kehren Sie mit frischen Köpfen zum Code zurück.

In den meisten Fällen wird die technische Verschuldung beim Debuggen hinzugefügt. Wenn Sie einen Fehler beheben, indem Sie eine Problemumgehung hinzufügen , haben Sie nichts behoben. Der Fehler bleibt bestehen, es ist nur schwieriger, ihn auszuführen und aus Versehen zu finden. Sie müssen Fehler beheben, indem Sie den Code umgestalten , ändern oder vollständig löschen . Testen Sie dann den Code, um sicherzustellen, dass der Fehler nicht erneut auftritt.

Zuletzt: Kollegen für Fehler zu beschuldigen, ist unproduktiv. Wenn Sie schlecht oder sarkastisch über Ihre Codebasis sprechen, werden die Probleme auch dadurch nicht gelöst, sondern nur die Situation verschlechtert. Zerstöre nicht den Teamgeist. Sie müssen die Entropie im Projekt reduzieren und dürfen sie nicht verbal zerstören.

Automatisierte Tests

Das problem

In der magischen Welt der Softwareentwicklung fasziniert mich etwas, insbesondere bei Startups: Viele Programmierer wollen noch immer keine automatisierten Tests schreiben.

Warum fasziniert es mich? In allen anderen Bereichen des Ingenieurwesens testen sie, was sie tun, indem sie einem strengen Prozess folgen. Wenn Sie eine Rakete bauen, müssen Sie viele Systeme testen, sonst fällt die Rakete. Gleiches gilt für Autos, Brücken, Flugzeuge - alles.

Geld sparen .

Ein einfaches Beispiel: Die NASA testet ihren Code gründlich (siehe Regel 5) .

, , , . , , .

. .

, , — , . ? , . , , ( ), , - .

, : , . , .

, .

Lösung

, , , .

. - 1,3 . , . «» .

:

• « ».
  
• « , ».
  
• « . , , ».
  

, , - ( ), :

• . , , .
  
• . , , - .
  
• . — , .
  
• , - . , - . !
  
• , . !
  

, .
, . , . , .

, , . .

, , . , , - .

, , . , , :

• , , .
  
• - , .
  

, . , . . , , , - , .

— , .

, .

,

:

• .
  
• , .
  
• , - .
  

. , , .

?

— . - , . , .

Das ist alles! , .

, , .

, , : « , , ? , . !».

: , . , . , .

, , , . , , . !

. :

• .
  
• , .
  
• .
  

, . , . , , .

, , . ?

, . , , .

:

• , . «, ?» — , « ! ! !».
  
• , . , , , , . «, , ?» « , 289 ».
  

, . , !

( !) .

. , , .

, — , , . !

!

, , , , . ? ? - ? ?

. , . -, . , , , .

, , . . — .

Also ?

• — . . , .
  
• — .
  
• . / .
  
• , , .
  
• , . , .
  
• , , (, ).
  

. . , . , — !

Nützliche Links:

• The Pragmatic Programmer
  
• Software Entropy Explained: Causes, Effects, and Remedies
  
• Entropy in software
  
• Software Rot, Entropy and the Broken Window Theory