Dieser Artikel wurde maschinell übersetzt.

Codebereinigung

Neun nützliche Strategien zur Tilgung „technischer Schulden“

David Laribee

In der Ausgabe von Dezember 2009 MSDN Magazine habe ich Ratschläge zum Identifizieren und Erstellen einer Anfrage an den technischen Schulden zu lösen.Zusammenfassend lässt sich sagen glauben ich es ist wichtig, die Schulden zu identifizieren, die Wahrscheinlichkeit, dass Sie in der Nahen Zukunft Schaden ist.Einführung in die technischen hervorragende Leistung selten berührt Teile Ihrer Codebasis wird nicht Sie höheren Produktivität durch den Einsatz Morgen dabei unterstützen, zu realisieren.

Ich hoffe, auch, dass Sie der Bedeutung verstehen der Lizenz beziehen und kaufen-in von Verwaltung die Bedeutung der bezahlen wieder Schulden und einige einfache Tools haben für die Erstellung einer Anfrage Rock einfarbige für dasselbe.

Jetzt unsere Aufmerksamkeit auf Taktiken, mit denen Sie technische Schulden mit hohen Zinsen wieder bezahlen können let’s zu aktivieren.Es gibt zahlreiche bewährte Taktiken im Umgang mit technischen Schulden.Ein vollständiger Katalog an die Muster, Tools und Techniken für die wrangling schwierig Code ist ebenfalls Gegenstand dieses Artikels.Stattdessen werde ich einige der Tricks mehr anwendbare angeben ich meine Repertoire im Laufe der Jahre hinzugefügt haben.

Erfahren Sie, erfahren Sie, erfahren Sie

Wenn Sie wissen, dass Sie Probleme haben, aber Sie sind nicht sicher sind, zu deren Lösung, ist es möglicherweise zu erwerben, neue Kenntnisse und Fähigkeiten, mit die Sie den Code aus dem Muck auslösen können.Es ist unerlässlich, lernen, wie Ihre Identität offen legen.

Lernen kann viele Formen annehmen.Sie müssen möglicherweise externe Hilfe in Form von Berater oder von einem Kursleiter durchgeführte Schulung.Sie Bücher zu erhalten, indem Sie möglicherweise zu.

Versuchen Sie, Ihr Team in der Lernprozess beinhalten.Möglicherweise konnte ein Buch Club innerhalb Ihres Teams gestartet werden.Vielleicht können Sie die Vorteile eines Kurses oder einer Konferenz in Form einer aufschlussreich Präsentation wieder.

Ein für die Zusammenarbeit und praktische Verfahren für das im Zusammenhang mit das gesamte Team ist der Coding Dojo.Eine grundlegende Coding Dojo umfasst eine Programmierung Herausforderung Kommissionierung und des übernehmen, die als Gruppe.Ich habe mit einem rotierenden Paar durch ein Peanut Katalog gesehen experimented.Bei dieser Methode zwei Mitglieder des Teams gemeinsam bearbeiten eine Programmieraufgabe mit “ Tag ” Intervalle, in denen andere Mitglieder des Teams der Dojo Geben Sie eine andere Person verlässt.

Wenn Sie erfahren Sie am besten in Ihrem eigenen Tempo oder ein Buch Club starten möchten, gibt es einige gute Texte, empfehle ich zu diesem Thema die Wartbarkeit der veralteten Code zu verbessern.

Michael Feathers treffend Betitelte Volume, Working Effectively mit ältere Code (Prentice Hall 2004), bietet es sich um einen Muster basierenden Ansatz für teasing aus Legacycode.Der Autor nimmt der Anweisung, dass älterer Code nicht getesteten Code ist.Es ist schwierig, ändern und kann nicht sicher, dass Ihre Änderungen werden nicht Einführung Regression Mängel in sein.In diesem Buch finden Sie eine Reihe von gezielten Strategien und Taktik zum Verringern der Kopplung in Ihrem Code und macht es mehr getestet werden.

Kyle Baley und Donald Belcham haben die neuesten Bücher in der Szene Brownfield-Anwendungsentwicklung in .NET T (Manning Publikationen 2010).Sie benötigen einen Systemfehler Ansatz zum Verbessern der so genannte Brownfield (im Vergleich zur Entwicklung neuer.oder Greenfield) die CodeBase.Ein Vorteil dieses Buch ist, dass während der Ansätze, die wird, diese empfohlen, umfassend anwendbaren, deren Codebeispiele um Microsoft .NET Framework einen wahrscheinlich Vorteil für Leser dieses Artikels dienen.Ich gerne ganz wie Sie einen Team-Methoden sowie Ansatz wählen.Das heißt, während Sie Änderungen in der wilden Codebasis vornehmen, das Vertrauen erhalten Sie von einigen Grundlagen wie beispielsweise kontinuierliche Integration implementieren und Versionskontrolle lohnt sich seine Stärke in Gold.

Diplomacy

Es ist eine hohe Wahrscheinlichkeit der unübersichtlich, Sie haben für den Umgang mit, Code von einer Person derzeit in Ihrem Team aus geschrieben wurde.Es ist wichtig, dass Sie dies bei berücksichtigt werden über den Code in seinem gegenwärtigen Zustand Überlegungen.Schaden Gefühle führen zu Defensiveness, die wiederum führt um zu verlangsamen, auf die Verbesserung trainieren.

Versuchen Sie die Deaktivierung der Situation mit Anecdotes von Fehlern, die Sie in der Vergangenheit vorgenommen haben.Professionelle bleiben, persönliche Angriffe zu vermeiden und fördern des Autors des ursprünglichen Codes stellen Vorschläge dazu, wie Sie zum Verbessern der Sie wechseln können.

Dann erneut, es ist durchaus möglich Sie sind ein Entwickler, die beigetragen haben, Ihre Chaos.Ich möchte Sie hinter mir Wiederholen: “ Ich nicht mein Code.Ich bin täglich erlernen und bin ausschließlich für eine bessere Möglichkeit wieder vorwärts zu suchen.Ich lässt nicht zu meiner Kollegen Critiques oder eigene stehen in der Hilfe der mein Team Bemühungen zur Verbesserung der Ego. ”

In Wahrheit dauert es Zeit, um diese Probleme zu erhalten.Ich finde die beste Möglichkeit, Ursache und sprechen Sie über Verbesserungen zu konzentrieren, am aktuellen und zukünftigen statt der Vergangenheit in der Nähe ist.Was könnte dieses Codes sein?Was möchten Sie es in weiterentwickelt finden Sie unter?

Ein wenig Diplomacy und Überlegungen für andere Personen emotionalen Investitionen in die Arbeit, die bereits zugesichert wird wurde wechseln eine lange lange Weise in Richtung nach vorne verschieben.

Geben Sie eine Einführung in eine Form

Teil des Codes ist also horrendous ist es schwierig zu verstehen, was überhaupt passiert ist.Möglicherweise sind alle Klassen in einem einzigen Namespace.Möglicherweise ist die Codebase in solchen ein tangled Web von Abhängigkeiten, die hinter des Stapels erheblich die kurzfristige Speicher Möglichkeit überschreitet, Ihren Ort aufbewahren.

Symptome wie diese implizieren oftmals eine Diagnose von Schulden an der Architektur und Entwurf Ebenen statt nur auf einer Implementierungsebene.Aus diesem Grund weit bin ich besorgt, ist die am häufigsten heimtückische Art der Schulden und in der Regel führt zu den größten Kosten der Änderung.

Brian Foote und Joseph Yoder aufrufen Architekturen keine erkennbaren-Shape, wo alles Alles andere, die “ Groß Ball Matsch ” abhängt (laputan.org/mud):

“ Ein großer Ball Matsch ist eine selten verwendete, sogar planlos strukturierten System.Ihre Organisation, wird Wenn eine es, die aufgerufen werden kann durch Expediency als Entwurf mehr vorgegeben.Noch sein nicht seiner Popularität seit lediglich eine allgemeine Missachtung für Architektur auf hin. ”

Ich würde Meine letzte Dollar Wetten, dass die meisten Softwareanwendungen in der Produktion heute großer Kugeln von Matsch sind.Dies ist nicht unbedingt auf einen Wert Judgement.Es gibt Milliarden von Codezeilen fürchterlich gibt es in der ganzen Welt Personen vornehmen, lose und sehr viel Geld.Es steht Grund, dass große Kugeln von Matsch die Champagne Träume und Caviar Wünsche von vielen ein Unternehmensinhaber und Beteiligten erfüllt werden.

Das Problem darin, dass die Kugel von Matsch Anwendungen zunehmend kostspieliger zu ändern sind.Während die Geschäftsumgebung dynamische bleibt, wird die Software zu unflexibel.Die typische Strategie für den Umgang mit Dies ist die Software Atomkraftwerke Bombe äquivalent: das groß schreiben.Es gibt viele Risiken im Zusammenhang mit großen Neuprogrammierungen, und es ist oft besser, die versuchen, den Entwurf des etablierten Systems zu verbessern.

Bevor Sie beginnen können, um einige der low-Level-Techniken einsetzen, ist es oft nützlich, ein Shape auf Ihr System vor.Typische Beispiel ist der geschichteten Architektur.Klassischerweise der Benutzeroberfläche kommuniziert mit und -Dienste sprechen, um eine Art des Modells und dadurch das Modell kommuniziert wiederum mit der Persistenz-Ebene.

Strukturieren Sie Ihren Code in Schichten kann eine sehr niedrige Wiedergabetreue Aktivität sein.Organisieren von Code in Namespaces, die mit dem Namen nach den Schichten der Architektur, um zu starten.

Sie verfügen nun über Ihre Aufträge Marching: Erzwingen Sie die Regel, dass die höhere Ebenen (Benutzer-Schnittstellenschicht) nur auf die nächste Ebene nach oben (Dienstschicht) abhängen.Als einfache Möglichkeit zum Erzwingen der Regel ist die Ebenen in separate Projekte in Visual Studio zu verschieben.Die Lösung wird nicht kompiliert, wenn Sie die gegen die Regel verstoßen.

Dadurch, dass die Regel übergeben, haben Sie die Kopplung verringert.Das Modell ist nicht mehr auf Ihre Anwendung Ansichten gekoppelt.Durch die Einführung eines Shapes haben Kohäsion erhöht werden.Klassen innerhalb Ihrer Ebene arbeiten alle dem gleichen Zweck, ob es sich, die zum Anzeigen von Daten an ein Endbenutzer oder zum Kapseln von geschäftlichen Verhalten handeln.

Führen Sie Fassaden zwischen Schichten ein und machen Sie Ebenen der höhere Ebene zu, wie Ihre Benutzeroberfläche hängen Fassaden von der unteren Ebene Schichten statt abgestufte Klassen innerhalb der Ebenen bereitgestellt.Sie können dieses Verfahren in diesem Prozess inkrementell und gegebenenfalls anwenden.

Die Leistungsfähigkeit von einem anwendet, ein Shape auf das monolithischen Groß Ball Matsch wird jetzt gestartet werden kann um mehr gezielte Möglichkeiten für die Zahlung wieder technische Schulden zu identifizieren.Das heißt, wenn Sie viel Arbeit in, sagen, möglicherweise CompanyX.ProductY.Model, Sie einen Drilldown mit einem statischen Analyse-Tool, um die am häufigsten gekoppelt oder kompliziert Klassen zu suchen.

Schließen Sie die Unterstützung für Luft mit Tests

Die Änderungen ohne Änderung des Systemverhaltens ist die Umgestaltung bezeichnet.Es gibt gesamte Umgestaltung Muster Sprachen dedizierter für beide objektorientierte (refactoring.com ) und Code für die relationale Datenbank (agiledata.org/essays/databaseRefactoringCatalog.html ): Extrahieren Sie Methode, teilen Sie die Tabelle und so weiter.Die Tatsache die Frage ist, ist es schwierig, diese präzise und sicheren Methoden anwenden, wenn Sie nicht die Codebasis vollständig verstehen.

Wie starte Sie Änderungen in einem älteren Projekt?Als erstes zu beachten ist, dass, wenn eine Auswahl, immer sicherer ist, Tests, um die Änderungen, die Sie vornehmen, haben.Wenn Sie den Code ändern, können Sie zu Fehlern führen.Aber wenn Sie Ihren Code mit Tests, abdecken bevor Sie den Code ändern, können Sie eher um alle Fehler abzufangen.

Die Praxis Shotgun medizinischen nicht plunging headlong in Code ohne echte vertrauen, die die Änderungen, die Einführung von sind auch nicht gefährlich defekte Einführung die einzige Möglichkeit, eine Änderung zu erzwingen.

Bevor Sie Code ändern können, ermitteln Sie, ob eine harte Schnittstelle im System gegen, das Tests schreiben können.Diese Tests sind die Blackbox-Reihe.Das heißt, Sie Einführen eines Systems Eingaben und die Ausgaben überprüfen.Wenn Sie Ihre Änderung vornehmen, ständig führen Sie die Tests zu überprüfen, ob Ihre Änderungen bestehende Verhalten aufgeteilt, die noch nicht aus.

Anwendung der diese Taktik kann schwierig sein, wenn Sie Teile des Systems bearbeitet haben, die eng gekoppelt sind.Die Kosten für das Testen möglicherweise sehr gut den Vorteil des Entfernens von Schulden überschreiten.Diese Konstanten Kosten / Nutzen-Analyse permeates bei der Aktivierung einer Codebasis um, und in manchen Fällen ist es kostengünstiger, direkt von einer Anwendung oder einen großen Teil einer Anwendung Codebasis umschreiben.

Measure Observable-Effekte

Erstellen Sie Messungen um den Bereich des Codes verbessert werden können.Aus Gründen der Argument let’s sagen, dass Sie herausfinden möchten, die Geschäftslogik Kern Ihrer Anwendung besser zu organisieren.Es gibt eine Vielzahl von Pfaden Durchlaufen der Member in die Typen von diesem Namespace: switch-Anweisungen, die verschachtelte Wenn-Anweisungen und ähnliches.Eine Maßeinheit, z. B. zyklomatische Komplexität kann Ihnen eine grobe Vorstellung davon, ob der Verbesserung von Software Code vereinfacht werden.

Erhalten Sie extrem Maße bestimmte Teile Ihrer Codebasis mit NDepend Code-Analysetools (ndepend.com ).NDepend bietet eine leistungsfähige Code Query Language (CQL) über die Namespaces, Typen und Mitglieder in Ihrem .NET Assemblys.

Berücksichtigen Sie die CQL-Anweisungen in Abbildung 1. Beachten Sie, dass ich Messungen wie Kopplung und Komplexität (nur einige der vielen Metriken NDepend macht verfügbar) in einem bestimmten Namespace durchsucht bin.Dies impliziert, dass ich ein Shape bereits eingeführt haben, damit ich in meinem Code definierbare Bereichen konzentrieren können.Wenn ich bei der Einweisung positiver Änderungen erfolgreich sollten Messungen wie Kopplung und Komplexität verringern über einen Zeitraum angezeigt.

Abbildung 1 NDepend CQL

-- Efferent coupling outside a namespace
SELECT TYPES 
WHERE TypeCe > 0 
      AND (FullNameLike "MyCompany.MyProduct.Web")

-- Afferent coupling inside a namespace
SELECT TYPES 
WHERE TypeCa > 0 
      AND (FullNameLike "MyCompany.MyProduct.Web") 

-- Top 20 most complicated methods
SELECT TOP 20 METHODS 
WHERE CyclomaticComplexity > 4 
      AND FullNameLike "MyCompany.MyProduct.Web"

Ein nettes Nebeneffekt dieser Vorgehensweise ist, dass die Maßangaben Ihnen helfen können, halten die Zeile und Disziplin verwalten, nach dem Schulden entfernt wurde. Sie erhalten Sie ein Frühwarnsystem in Richtung der Reintroduction von neuen Schulden in einen bereits verbesserte Bereich.

Dedizierte zur Verbesserung der Stream

Sie leben nicht in einem Vakuum. Wahrscheinlich sind, während Ihre Bemühungen Verbesserung werden Sie gefragt, um den Vorgang fortzusetzen, neue Features und Änderungen an vorhandenen Features zu übermitteln. Übermittlung Druck verursacht, dass es sich unter der Gun Gefühle. Aber Wartung ist eine Tatsache Leben, die Sie übernehmen sollten statt zu ignorieren.

Eine Möglichkeit für den Umgang mit diesem besteht darin, Sichern Sie die Genehmigung von dem Unternehmen Ressourcen reservieren – einer Person, ein paar oder ein gesamtes Team – zur Verbesserung der Schulden Elemente gleichzeitig mit neuen Features bieten.

Dies kann eine sehr effektive Strategie jedoch eignet sich am besten, wenn das gesamte Team (alle Entwickler und Tester, die Änderungen an der Codebase) einen Teil in die Verbesserungen übernimmt. Versuchen Sie es regelmäßig drehen Personen als Paare. Der Entwickler, der in den Stream Verbesserung der längsten wurde gedreht, lassen Entwickler kurze das neue Paar auf was geschieht.

Durch das Verteilen der Wissensdatenbank erhalten Sie näher an gemeinsamen Besitz, wodurch Risiko und Entwürfe zu verbessern. Manchmal finden Sie Verbesserungsmöglichkeiten, die direkt über der einige neue Funktionen liegen Sie übermitteln möchten. Bei jedem start von Arbeit zu einem neuen oder geänderten Feature ist es empfehlenswert, überprüfen Sie die Liste, um zu bestimmen, ob das Team bereits einen Bereich für eine Verbesserung identifiziert noch nicht, die mit der Arbeit schneidet Sie gerade tun.

Verbesserungsmöglichkeiten auftreten, die Zeit, die häufig identifizierten on-the-Fly und ein Teamkollege findet mit ein paar einfache Refactoring, die das nächste Mal an eine Differenz, erreicht den Code.

Es gibt eine Konstante, die auf wechselt, wenn Sie beim Übermitteln von neuen Features die vorhandene Codebasis zu verbessern sind Kosten / Nutzen-Analyse. Wenn die Verbesserung zu kostspielig, fügen Sie wieder zu Ihrer Liste hinzu, und besprechen Sie bei der Verbesserung der Planung.

Durchlaufen, wiederholen, wiederholen

Sie haben termingerecht Back einige Schulden. Wechseln Sie zurück zur Schritt eine und identifizieren, Priorisieren und Zeit einen Konsens zu erstellen, auf das nächste Element, das behoben werden können, Rechte benötigt?

Ja, aber es ist etwas mehr dazu als mindlessly plowing durch die Liste. Sie müssen sicher sein, dass Sie nicht mehr Schulden als Ihre dass sind. Sie sollten außerdem regelmäßig Ihre 
learnings in zukünftigen Bemühungen in neue Entwicklungen und der Verbesserung von Software gleichermaßen einbinden.

Möglichkeiten zum Verbessern der einer Codebasis regelmäßig zu ändern. Wenn sich Sie und ihre Bedeutung Ebbs und fließt. Gründe für die der dynamischen Natur von hoch verzinste Schulden zu von Version zu Version ändern.

Was auch für mich gearbeitet wird ist einen kurzen, mit den Entwicklern neue Schulden Elemente überprüfen und Priorisieren von den Backlog der Elemente von bestehenden Schulden wöchentliche Besprechung planen. Auf diese Weise wird die Übereinstimmung, die Sie erstellt haben aktiv und die neue Liste. Erneut, würde ich Priorität geben, zum Beheben von Schulden, die wahrscheinlich können Sie die aktuelle Version oder das Projekt verlangsamen.

Beginnen Sie die Besprechung durch neue Elemente überprüfen. Haben Sie die Verschiebung der Groß-und Kleinschreibung und platzieren Sie es für eine Abstimmung-ID: gefährdet es Aufnahme im Backlog oder nicht? Sobald Sie über die neuen Elemente überschritten haben, überprüfen Sie die alten Elemente. Ist Arbeit, die nicht mehr gültig? Wird es unmittelbaren Wert Abschließen dieser Arbeit, d. h., entfernt es tägliche Impediments? Zuletzt, Priorisieren Sie die Verkaufschance für andere Benutzer – Ihrer Liste AW-Rang. Das oberste Element in der Liste sollte sehr nächsten Verbesserung vornehmen.

Halten Sie die Zeile

Während Sie und Ihr Team Karl unten hoch verzinste technischen Schulden bezahlt werden, werden Sie wahrscheinlich auch neuen Software übermittelt werden. Sie erfahren Sie mehr über solide Programmiertechniken und Einführen neuer Muster in den Code, gelten Sie diese Kenntnisse, die Zukunft. Es ist möglich, dass zusätzliche Arbeit auf vorhandenen technischen Schulden, erstellen ein inescapable Inertia pile wird.

Es ist wichtig, dass Sie die Erwartungen für den beteiligten Unternehmen für neue Arbeit festlegen. Höherer Qualität nimmt mehr Zeit zum Erreichen als Get-It-fertig-Stil Code rushed. Diese Tatsache bringt mich an den Systemen denken Konzept eingeführt wurden, wieder in meinem Artikel vom Dezember 2009. Für mich ist dies eine kulturelle Attribut. D. h., die Organisationen können die sustainably für die langfristige vorstellen oder ein kaufen jetzt fortsetzen bezahlen höher Mentality – die ACH so fertile Breeding Boden der technischen Schulden. Vergessen Sie nie die zentrale Frage, wie wir hier in erster Linie enden?

Sehr wahrscheinlich wird einige Normwerte Team entwickelt, die auf neuen Code anwenden, während wie lernen Sie eine Codebasis zu verbessern. Es empfiehlt sich, diese in einem Tool wie ein Wiki erfassen und gedrückt halten, kleine, informelle Sitzungen Lernen Ihre Ergebnisse mit Ihrem Team freigeben. Sie werden auch Verfahren zum Umgang mit ähnlichen Verbesserung Elemente entwickeln. Wenn Sie feststellen, dass haben das gleiche ein Entwurfsfehler korrigieren oder bereinigen Implementierung drei oder vier Mal codify in Ihrem Team allseits. D. h., notieren Sie in einem bekannten Ort und sehr einfach informieren von Personen ist vorhanden.

Gemeinsames Arbeiten

Technische Schulden ist ein Problem Personen. Personen mit fehlendem von wissen oder unrealistische Erwartungen, erstellt das Chaos und sind jetzt im Zusammenhang mit der folgen. Und es dauern wird, Personen, die als Gruppe arbeiten, um den Fehler zu beheben.

Erteilen Ratschläge, wie dies ist alles schön und gut, und ich würde überrascht, wenn Sie eine Software professionelle und wahrscheinlich ein, die über Ihre Bastelarbeiten Leidenschaftliches ist abgeschlossen zu werden.

Eine erfolgreiche Umlaufzeiten erfordert grundlegende Änderungen in das System Wert, der alle Beteiligten – das gesamte Team. Die Wirtschaftlichkeit Qualität werden letztendlich wieder bezahlen erwiesen, jedoch müssen Sie die Schritt glauben kurzfristig teilnehmen. Sie haben zu Herzen und Recht gewinnen, um eine Kultur zu ändern und, kann in der Tat ein schwierigen Auftrag. Wird von der nützlichste Vorschlag, den ich vornehmen können: Gehen Sie es alleine nicht. Erhalten Sie das Team hinter den Aufwand zu, und stellen Sie sicher, dass jeder Benutzer hat eine Bedeutung in den Ergebnissen.

Festlegen eines Ziels wie “ soll 90 Prozent Abdeckung ” oder “ wir wollen Test-Driven Development (TDD) immer ” ist relativ bedeutungslos. Lösen Sie die Problembereiche, die Sie in dem Moment, und in naher Zukunft verlangsamt werden. Einführung in die TDD und vom Bericht abgedeckt Leben bedeutet möglicherweise, oder es ist möglicherweise nicht. Ist es möglicherweise etwas mehr primitive, wie Sie sicherstellen, dass Ihr Team weiß, dass die Grundlagen der objektorientierten Analyse und Entwurf.

Erstellen einen Unterschied zu starten

Während ich hoffe, ich Ihnen einige Tools und Techniken dass für Schulden bearbeitet oder zumindest erteilt haben, versucht Sie einige der impliziten Ideen und Erfahrungen Sie hatten explizit, es ist wichtig zu erkennen, dass der Umgang mit technischen Schulden sehr viel von einer Produkt-zu-Produkt-Problem ist. Z. B. möglicherweise in einer Umgebung, in denen keine Vertrauensstellung zwischen den Entwicklungs- und Geschäftsanforderungen Parteien und suchen Sie die Groß-/Kleinschreibung mit der Vorbereitung einer Testversion Anwalt Schreibbreite haben viel.

Es werden keine Out-of-Box, die Sie die für Sie Schulden driving festlegen werden, aber wie für die beim und den , , heute ist ein Tag, machen einen Unterschied zu starten. März in Richtung technischen hervorragende Leistung kann langsam und grobe wechseln in der Anfang sein. Es ist nur über anhaltende Aufwand, Lern- und über allen-Konstante, eine earnest Haltung, die Sie über gewinnen immer wieder Onlineschalten von Schulden crippled Code in das schwarze abgerufen werden. Ich empfehle Ihnen, mit dem Programm einhalten. Nicht nur wird der Wert für Ihre Kunden zu erhöhen, Sie werden Ihre Handwerker Toolbox erheblich erweitert.

Dave Laribee VersionOne Inc. Produktentwicklungsteam coaches Er ist ein gefragter Referent bei lokalen und nationalen Entwickler Ereignisse und zuerkannt wurde einMicrosoft Architecture MVP für 2007 und 2008. Er schreibt der CodeBetter Blog Netzwerk wird bei thebeelog.com.