Ist DRY der Feind des Softwareprojektmanagements?

Eines der grundlegendsten und am weitesten verbreiteten Prinzipien der Softwareentwicklung ist DRY (wiederholen Sie sich nicht). Es ist auch klar, dass die meisten Softwareprojekte eine Art Management erfordern.

Welche Aufgaben sind nun einfach zu verwalten (Schätzen, Planen, Steuern)? Richtige, sich wiederholende Aufgaben, genau die Aufgaben, die laut DRY vermieden werden sollten.

Aus Sicht des Projektmanagements ist es daher großartig, eine Aufgabe zu lösen, indem Sie 100-mal vorhandenen Code kopieren und bei Bedarf kleinere Anpassungen an jeder Kopie vornehmen. Sie wissen jederzeit genau, wie viel Arbeit Sie geleistet haben und wie viel noch übrig ist. Alle Manager werden dich lieben.

Wenn Sie stattdessen das DRY-Prinzip anwenden und versuchen, eine Abstraktion zu finden, die den doppelten Code mehr oder weniger beseitigt, ist das anders. Normalerweise gibt es viele Möglichkeiten, man muss Entscheidungen treffen, recherchieren, kreativ sein. Sie könnten in kürzerer Zeit eine bessere Lösung finden, aber auch scheitern. Die meiste Zeit kann man nicht wirklich sagen, wie viel Arbeit noch übrig ist. Sie sind der schlimmste Albtraum eines Projektmanagers.

Natürlich übertreibe ich, aber es gibt offensichtlich ein Dilemma. Meine Fragen sind: Was sind Kriterien, um zu entscheiden, ob ein Entwickler DRY übertreibt? Wie können wir einen guten Kompromiss finden? Oder gibt es eine Möglichkeit, dieses Dilemma vollständig zu überwinden, nicht nur durch die Suche nach einem Kompromiss?

Hinweis: Diese Frage basiert auf der gleichen Idee wie meine vorherige: Umfang der Routinearbeit in der Softwareentwicklung und deren Auswirkung auf die Schätzung , aber ich denke, dies macht meinen Standpunkt klarer. Es tut mir leid, dass ich mich wiederhole :).

Sie scheinen davon auszugehen, dass das Hauptziel des Projektmanagements darin besteht, genaue Schätzungen zu erstellen. Das ist nicht der Fall. Das Hauptziel des Projektmanagements ist dasselbe wie für Entwickler: Mehrwert für den Product Owner zu liefern.

Ein Produkt, das viele langsame manuelle Prozesse anstelle von Automatisierung verwendet, ist theoretisch möglicherweise einfacher abzuschätzen (obwohl ich dies bezweifle), bietet dem Kunden jedoch kein gutes Preis-Leistungs-Verhältnis, sodass es einfach ein schlechtes Projektmanagement ist. Es gibt kein Dilemma.

Es ist allgemein bekannt, dass die Einschätzung von Softwareprojekten schwierig ist, und es wurden zahlreiche Bücher verfasst und verschiedene Verfahren entwickelt, um diese zu verwalten.

Wenn das einzige Ziel des PM darin bestand, genaue Schätzungen zu erstellen, wäre dies einfach. Füllen Sie die Schätzungen einfach auf das 10-Fache auf und lassen Sie die Entwickler die restlichen Spiele spielen, wenn sie vorzeitig fertig sind. Dies ist in der Tat besser als der Vorschlag, die Arbeitszeit durch Kopieren und Einfügen aufzufüllen, da das Spielen von Spielen die Wartbarkeit des Produkts nicht beeinträchtigt.

In Wirklichkeit möchte der Produktbesitzer nützliche Schätzungen und ein Qualitätsprodukt, das so schnell und billig wie möglich geliefert wird. Dies sind die tatsächlichen Einschränkungen, durch die ein PM navigieren muss.

Auf jeden Fall bestreite ich Ihre Annahme, dass sich wiederholende manuelle Arbeit vorhersehbarer als automatisiert ist. Alle Erfahrung zeigt , dass sich wiederholende manuelle Arbeit ist mehr fehleranfällig. Und was ist, wenn im kopierten Code ein Fehler entdeckt wird? Plötzlich multiplizieren sich die Kosten für die Behebung eines Fehlers mit der Anzahl der Wiederholungen, wodurch die Unsicherheit explodiert.

Sie haben Recht - Kopieren-Einfügen funktioniert hervorragend, und DRY hat keinen Sinn, wenn Sie ein Programm erstellen müssen, für das weder die kopierte Vorlage noch die Kopie in Zukunft beibehalten oder weiterentwickelt werden müssen. Wenn diese beiden Softwarekomponenten einen völlig unterschiedlichen Lebenszyklus haben, kann die Kopplung durch Umgestaltung des gemeinsamen Codes in eine gemeinsame Bibliothek, die sich selbst in starker Entwicklung befindet, tatsächlich unvorhersehbare Auswirkungen auf den Aufwand haben. Auf der anderen Seite haben alle diese Teile beim Kopieren von Codeabschnitten in einem Programm oder Programmsystem normalerweise den gleichen Lebenszyklus. Ich werde im Folgenden erläutern, was dies für DRY und das Projektmanagement bedeutet.

Im Ernst, es gibt viele solcher Programme: Zum Beispiel produziert die Computerspielindustrie viele Programme, die über einen kurzen Zeitraum von höchstens einigen Monaten oder einem Jahr gepflegt werden müssen, und wenn diese Zeit abgelaufen ist, kopieren Sie sie Der alte Code aus einem früheren Spiel, bei dem die Wartungszeit überschritten wurde, in die Codebasis eines neuen Spiels ist vollkommen in Ordnung und kann die Dinge beschleunigen.

Leider unterscheidet sich der Lebenszyklus der meisten Programme, mit denen ich in den letzten Jahren zu tun hatte, erheblich davon. 98% der Anforderungen oder Bugfix-Anfragen, die bei mir eingingen, waren Änderungsanfragenfür bestehende Programme. Und wann immer Sie etwas an einer vorhandenen Software ändern müssen, funktioniert "Projektmanagement" oder Planung am besten, wenn Ihre Test- und Debug-Bemühungen recht gering sind - was nicht der Fall ist, wenn Sie etwas an einem Ort ändern, sondern aufgrund von Kopien - Vergangene Geschäftslogik, die Sie leicht vergessen, dass Sie ein Dutzend weiterer Stellen in der Codebasis ändern müssen. Und selbst wenn Sie es schaffen, alle diese Orte zu finden, ist die Zeit, um sie alle zu ändern (und die Änderungen zu testen), wahrscheinlich viel höher, als wenn Sie nur einen Ort zum Ändern haben. Selbst Sie können eine genaue Schätzung der Änderung vornehmen, da die Kosten ein Dutzend Mal höher sind als erforderlich, und dies kann leicht zu einer Kollision mit dem Projektbudget führen.

TLDR - Wenn Sie ein Programm entwickeln, bei dem keine Notwendigkeit oder Verantwortung für die Fehlerbehebung und Wartung des Originals oder der Kopie besteht, können Sie es jederzeit kopieren. Aber wenn Sie, Ihr Team oder Ihr Unternehmen dafür verantwortlich sind oder verantwortlich werden könnten, wenden Sie DRY an, wann immer Sie können.

Beispiel

Lassen Sie mich als Nachtrag erläutern, was "Fehlerbehebung und Wartung" bedeutet und wie dies zu Unvorhersehbarkeit bei der Planung führt, insbesondere innerhalb eines Produkts, und zwar anhand eines Beispiels aus der Praxis. Ich habe in der Tat gesehen, dass solche Dinge in der Realität passieren, wahrscheinlich nicht mit 100 Instanzen, aber die Probleme können sogar beginnen, wenn Sie nur eine doppelte Instanz haben.

Die Aufgabe: 100 verschiedene Berichte für eine Anwendung erstellen, wobei jeder Bericht sehr ähnlich aussieht, einige Anforderungsunterschiede zwischen den Berichten, eine andere Logik, aber insgesamt nicht viele Unterschiede.

Der Entwickler, der diese Aufgabe erhält, erstellt die erste (sagen wir, es dauert 3 Tage). Nach einigen Änderungen oder kleineren Fehlerbehebungen aufgrund von Qualitätssicherung und Kundeninspektion läuft sie anscheinend einwandfrei. Dann fing er an, den nächsten Bericht zu erstellen, indem er das Ganze kopierte und änderte, dann den nächsten und für jeden neuen Bericht durchschnittlich ~ 1 Tag. Auf den ersten Blick sehr vorhersehbar ...

Nachdem die 100 Berichte "fertig" sind, geht das Programm in die reale Produktion und es treten einige Probleme auf, die während der Qualitätssicherung übersehen wurden. Vielleicht gibt es Leistungsprobleme, vielleicht stürzen die Berichte regelmäßig ab, vielleicht funktionieren andere Dinge nicht wie beabsichtigt. Nach Anwendung des DRY-Prinzips konnten 90% dieser Probleme gelöst werden, indem die Codebasis an einer Stelle geändert wurde. Aufgrund des Copy-Paste-Ansatzes muss das Problem jedoch 100-mal und nicht nur einmal gelöst werden. Und aufgrund der Änderungen, die bereits von einem Bericht auf einen anderen angewendet wurden, kann der Entwickler den Fix für den ersten Bericht nicht schnell auf den anderen 99 kopieren und einfügen. Er muss alle 100 Berichte überprüfen, lesen und die Änderung in den geänderten übersetzen melden, testen und eventuell jedes einzeln debuggen. Für die PM, das wird langsam sehr schwierig - er kann sich natürlich die Zeit für eine "normale" Fehlerbehebung nehmen (sagen wir mal 3 Stunden) und diese mit 100 multiplizieren, aber tatsächlich ist dies höchstwahrscheinlich eine falsche Schätzung, einige der Fehlerbehebungen könnten sein leichter zu machen als andere, andere könnten schwerer sein. Und selbst wenn diese Einschätzung korrekt ist, kostet es Sie eine Menge Geld, wenn das Debugging 100-mal so hoch ist, wie es sein musste.

Das gleiche passiert beim nächsten Mal, wenn der Kunde die Änderung der Farbe seines Firmenzeichens in all diesen Berichten, die Konfiguration der Seitengröße oder eine andere neue Anforderung, die alle Berichte auf ähnliche Weise betrifft, anfordert. In diesem Fall können Sie eine Schätzung der Kosten vornehmen und dem Kunden das 100-fache des Preises in Rechnung stellen, den er zu zahlen hätte, wenn der Code TROCKEN gewesen wäre. Versuchen Sie dies jedoch ein paar Mal, und der Kunde bricht das Projekt ab, da er wahrscheinlich nicht bereit ist, Ihre exorbitanten Entwicklungskosten zu bezahlen. Und vielleicht wird dann jemand die Frage stellen, warum dies passiert ist, und mit dem Finger auf die Person zeigen, die die Entscheidung für diese Copy-Paste-Programmierung getroffen hat.

Mein Punkt ist: Wenn Sie Software für andere erstellen, haben Sie zumindest für kurze Zeit die Verantwortung, die Sache zum Laufen zu bringen, Fehler zu beheben, das Programm an sich ändernde Anforderungen anzupassen usw. Auch in einem Projekt auf der grünen Wiese, diese Teile können sich schnell zu weit mehr als dem ursprünglich geplanten Entwicklungsaufwand summieren. Und insbesondere, wenn sich der gesamte kopierte Code in einem Produkt befindet, ist der Zeitraum der Verantwortung für alle Teile gleich. Dies unterscheidet sich erheblich von der Situation, in der Sie älteren Code aus einem toten Projekt, das nicht mehr vorhanden ist, kopiert haben unter aktiver Wartung.

Aus Sicht des Projektmanagements ist es daher großartig, eine Aufgabe zu lösen, indem Sie 100-mal vorhandenen Code kopieren und bei Bedarf kleinere Anpassungen an jeder Kopie vornehmen. Sie wissen jederzeit genau, wie viel Arbeit Sie geleistet haben und wie viel noch übrig ist. Alle Manager werden dich lieben.

Ihre Basisbehauptung ist falsch.

Die Sache , die Software macht anders aus anderen Berufen ist , dass Sie jeden Tag etwas Neues machen. Immerhin wird kein Kunde zahlen Sie etwas zu bauen , das jemand anderes bereits gemacht hat. Projektmanager mögen Vorhersehbarkeit, aber ihre Vorgesetzten mögen Wert . Wenn Sie nur Code mit geringfügigen Abweichungen kopieren und einfügen, erhalten Sie für das Unternehmen nicht viel Wert.

Irgendwann wird das Unternehmen feststellen, dass es die gleiche Arbeit in einem Bruchteil der Zeit erledigen kann, wenn es einen guten Programmierer anstellt. Und wenn nicht, werden ihre Konkurrenten.

Cut-and-Paste-Programmierung führt schließlich zu verlassener Software. Ich war ein Auftragnehmer für ein System zur Bestellung von Festnetzdiensten bei einer sehr großen Telefongesellschaft. Das System wurde ad nauseum ausgeschnitten und eingefügt, da alle Tests manuell waren und sie keinen Arbeitscode ändern wollten. Die kleinste Verbesserung könnte zu einer neuen Kopie von Hunderten von Codezeilen führen. Ursprünglich war die Anwendung für Konten mit bis zu zwölf physischen Leitungen geschrieben worden. Natürlich wurde diese Einschränkung an Hunderten von Stellen im Code vorgenommen. Nach ungefähr vier Jahren fragte das Unternehmen das Team, was es für die Abwicklung größerer Konten benötige. Sie schätzten ungefähr 18 Millionen Dollar. Zu diesem Zeitpunkt wurde das Projekt an ein Offshore-Team übergeben, um die Wartung auf ein Minimum zu beschränken. Das bestehende Team wurde komplett entlassen.

Unternehmen, die so denken, werden von Unternehmen mit besserer Technologie unter Druck gesetzt.

Eine oft vergessene Maxime, die hier gilt, ist die Regel von 3 . Dies besagt, dass es in Ordnung ist, Code einmal zu kopieren, darüber hinaus sollte er jedoch durch generischen Code ersetzt werden.

3 könnte scheinen wie eine beliebige Zahl , sondern ein gängiges Szenario ist , wo Daten und Logik in einer Anwendung und Datenbank dupliziert werden. Ein häufig genanntes Beispiel ist das Vorhandensein einer Nachschlagetabelle in der Datenbank und eines Enumerationsclients. Aufgrund des Paradigmenunterschieds kann dies nicht einfach an einem einzigen Ort gespeichert werden, sodass die Informationen häufig an beiden Orten angezeigt werden.

Es ist zwar schön, über DRY-Code zu verfügen, es kann jedoch vorkommen, dass die Geschäftslogik eine Ausnahme diktiert und Sie daher zwei oder mehr Codebits aus der Quelle erstellen müssen, die zuvor generisch war.

Also, was tun? Code für den Status quo (immerhin YAGNI ). Während Code zur Vereinfachung der Modifikation geschrieben werden sollte, ist das Schreiben einer ganzen Reihe von Schnickschnack für etwas, das möglicherweise nicht benötigt wird, nur eine Geldstrafe.

In Ihrer Frage listen Sie nur drei Funktionen des Projektmanagements auf - Schätzen, Planen und Kontrollieren. Beim Projektmanagement geht es darum, Ziele innerhalb der Grenzen des Projekts zu erreichen. Die Methoden zum Erreichen von Zielen innerhalb der Einschränkungen eines Projekts unterscheiden sich bei Softwareprojekten von vielen anderen Projekttypen. Sie möchten zum Beispiel, dass Fertigungsprozesse in hohem Maße reproduzierbar und verständlich sind. Softwareentwicklung ist jedoch meist Wissensarbeit- Es ist keine Routine und erfordert Denken, anstatt strengen Anweisungen und Verfahren zu folgen. Die Techniken, die zum Initiieren, Planen, Ausführen, Überwachen und Steuern und Schließen eines Softwareprojekts verwendet werden, müssen die Art der Arbeit berücksichtigen, die an einem Softwareprojekt ausgeführt werden muss - insbesondere nicht routinemäßige Arbeit, die nicht ausgeführt werden kann zu spezifischen Anweisungen und Verfahren.

Ich denke, das andere Problem ist, dass Sie DRY einnehmen, ein Konzept, das sich auf die Wiederholung von Informationen bezieht und versucht, diese auf die Verwaltung von Aufgaben anzuwenden. DRY sagt einfach, dass Sie nur eine maßgebliche Repräsentation von Informationen haben sollten. Projektmanager sollten dies berücksichtigen, da dies bedeutet, dass jeder weiß, wo er Informationen abrufen muss, Änderungen einfach kommuniziert und die Änderungen gut gesteuert und verwaltet werden können. DRY trägt durch wiederverwendbare Teile dazu bei, die langfristigen Kosten niedrig zu halten, langfristige Zeitpläne einzuhalten und die Qualität zu verbessern - drei Teile im Projektmanagement-Dreieck . Es muss etwas Zeit und Geld investiert werden, um die Dinge effektiv trocken zu machen, aber die Aufgabe des Projektmanagers besteht darin, Zeit, Kosten, Zeitplan und Qualität gegeneinander abzuwägen.

Das Schreiben von neuem Code ist nur ein kleiner Teil der Aufgabe

Ihr Vorschlag würde es einfacher machen, den Teil des anfänglichen Schreibens von neuem Code abzuschätzen. Um tatsächlich etwas Neues mitzubringen (egal ob es sich um ein brandneues System, eine Erweiterung des Funktionsumfangs oder eine Änderung der Funktionalität handelt), reicht dies jedoch nicht aus und ist nur eine Minderheit der Arbeit - die Schätzungen in der Literatur zeigen, dass dies in der Praxis der Fall ist Teil ist so etwas wie 20% -40% der Gesamtarbeit.

Der Großteil der Arbeit (einschließlich der Anpassung Ihrer ursprünglichen Entwicklung an die tatsächlichen Anforderungen, Integration, Testen, Umschreiben und erneutes Testen) lässt sich daher nicht einfacher abschätzen. Umgekehrt hat die absichtliche Vermeidung von DRY diesen Teil viel größer, schwieriger und mit variableren Schätzungen gemacht - dieser Fehler oder Änderungsbedarf, der das Ändern aller geklonten Teile erfordert, tritt möglicherweise nicht auf, aber wenn ja, dann Ihre Schätzungen werden völlig falsch sein.

Sie erhalten keine besseren Schätzungen, wenn Sie die Schätzqualität eines kleinen Teils der Arbeit verbessern, aber einen großen Teil der Arbeit verschlechtern. Es handelt sich also nicht wirklich um einen Kompromiss, sondern um einen Verlust, bei dem Sie eine schlechtere Produktivität, aber auch schlechtere Schätzungen erzielen.

DRY ist nützlich, aber auch überbewertet. Manche Leute können es zu weit bringen. Was viele Entwickler nicht erkennen, ist, dass Sie immer dann, wenn Sie DRY implementieren, um dieselbe Methode für zwei (leicht) unterschiedliche Zwecke zu verwenden, eine sehr enge Kopplung zwischen den verschiedenen Verwendungen herstellen. Jedes Mal, wenn Sie den Code für den ersten Anwendungsfall ändern, müssen Sie außerdem überprüfen, ob der zweite Anwendungsfall regressiv ist. Wenn es sich um weitgehend unabhängige Anwendungsfälle handelt, ist es sehr fraglich, ob sie eng miteinander verbunden sein sollten - wahrscheinlich auch nicht.

Ein übermäßiger Gebrauch von DRY kann auch zu Gott-Methoden führen, die in ihrer Komplexität explodieren, um all die verschiedenen Anwendungsfälle zu bewältigen, in denen sie verwendet werden, wenn im Allgemeinen kleinere atomare Methoden, die Code replizieren, viel besser zu warten wären.

Ich würde jedoch vorschlagen, dass die Frage auf Projektmanagementebene nicht wirklich relevant ist. Ein Projektmanager möchte sich wirklich nicht mit diesem Detaillierungsgrad der Implementierung befassen. Wenn sie es sind, ist es wahrscheinlich Mikromanagement. Wirklich ... wie die Dinge umgesetzt werden, liegt mehr in der Verantwortung des Entwicklers und des technischen Leiters. Das Projektmanagement befasst sich mehr mit dem, was wann erledigt wird .

EDIT: Per Kommentar stimme ich jedoch zu, dass die Vermeidung von DRY manchmal die Menge an Unsicherheit verringern kann , sofern es einfacher ist, die Entwicklungszeit abzuschätzen . Ich halte dies jedoch für ein unbedeutendes Problem in Bezug auf die dringlicheren Fragen: (1) wie lange dauert es, bis die geschäftlichen Anforderungen erfüllt sind, (2) welche technischen Schulden dabei eingehen und (3) welche Risiken für die Gesamtkosten von Die Entscheidung für die Architektur - ob DRY oder nicht - hängt in vielen Fällen eher vom Risiko / Nutzen dieser Faktoren ab, als davon, ob es einfacher ist, den Projektmanagern genauere Informationen zur Verfügung zu stellen .

Ich glaube, Sie verstehen DRY falsch.

Nehmen wir ein Beispiel:

public Class A
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }
}

public Class B
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }

    public int Add(int x, int y)
    {
        return x + y;
    }
}

gegen

public Class C : A
{
    public int Add(int x, int y)
    {
        return x + y;
    }
}

Indem wir Klasse B durch C ersetzt haben, haben wir das DRY-Prinzip befolgt und die Codeduplizierung reduziert. Wir haben jedoch weder die Unbekannten noch das Risiko für das Projekt erhöht (es sei denn, Sie haben noch nie zuvor eine Vererbung durchgeführt).

Ich denke, was Sie meinen, wenn Sie über DRY sprechen, ist eher eine Designaufgabe. Dh:

public Class A
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }
}

!!!Neue Anforderung! Einige Kunden müssen in der Lage sein, das Doppelte zu multiplizieren !!

// Use class B for new clients!!
public Class B
{
    public int Multiply(double x, double y)
    {
        return x * y;
    }
}

gegen

public Class A // Version 2
{
    public int Multiply(int x, int y)
    {
        return Multiply(x as double, y as double);
    }

    public int Multiply(double x, double y)
    {
        return x * y;
    }
}

Hier haben wir (sofern es funktioniert) eine Lösung entworfen, die sowohl die alte als auch die neue Anforderung behandeln kann und im Wesentlichen versucht, ein mathematisches Modell des realen Problems oder der Geschäftsregeln zu erstellen. Im wirklichen Leben wird das System, das wir modellieren, offensichtlich viel komplizierter sein, unser Modell wird nicht genau passen, und die Randfälle und unerwarteten Ergebnisse brauchen Zeit, um zu finden und zu korrigieren.

Sollen wir in diesem Fall also Version 2 von B oder A nehmen?

• B wird spezifischer auf die tatsächlich angeforderte Änderung mit weniger Nebenwirkungen und einfacher abzuschätzen und schneller durchzuführen sein.

• Eine Version 2 wird in Zukunft zu weniger Gesamtcode führen und die elegantere Lösung sein

Ich werde wieder sagen, dass es auf die Qualität der Spezifikation und der Anforderungen ankommt.

Wenn wir sehr klare Spezifikationen haben, die die Edge-Cases und die Abwärtskompatibilität abdecken, können wir sicher sein, dass wir das System gut genug verstehen, um das Modell zu überarbeiten, ohne Fehler zu produzieren.

Wenn wir eine Notfallanfrage für einen einzelnen Kunden haben, bei der die einzige Anforderung darin besteht, dass sich das Verhalten für diesen Kunden ohne Berücksichtigung des Gesamtsystems ändert. dann birgt die "Verbesserung" des Modells durch Refactoring von A ein erhebliches Risiko. Beides, andere Kunden zu brechen oder die Frist zu überschreiten, weil zusätzliche unbekannte Zeit erforderlich ist, um die Lösung zu entwerfen und zu testen.

Absatz für Absatz

Eines der grundlegendsten und am weitesten verbreiteten Prinzipien der Softwareentwicklung ist DRY (wiederholen Sie sich nicht). Es ist auch klar, dass die meisten Softwareprojekte eine Art Management erfordern.

Richtig.

Welche Aufgaben sind nun einfach zu verwalten (Schätzen, Planen, Steuern)? Richtige, sich wiederholende Aufgaben, genau die Aufgaben, die laut DRY vermieden werden sollten.

Sich wiederholende Aufgaben sollten automatisiert und obligatorisch sein . Sie sind langweilig, fehleranfällig, wenn sie von Hand hergestellt werden.

Aus Sicht des Projektmanagements ist es daher großartig, eine Aufgabe zu lösen, indem Sie 100-mal vorhandenen Code kopieren und bei Bedarf kleinere Anpassungen an jeder Kopie vornehmen. Sie wissen jederzeit genau, wie viel Arbeit Sie geleistet haben und wie viel noch übrig ist. Alle Manager werden dich lieben.

Ich denke, Sie können das Wort "Anpassung" mit "Konfiguration" ändern. Stellen Sie sich vor, Sie haben einen Fehler in diesem Code, der kopiert werden soll. Ein Fehler, der unter bestimmten Bedingungen auftritt. Wenn es in der Originalquelle nicht repariert und kopiert wird, müssen viele Stellen repariert werden. Das mag schlecht sein, aber dann muss jemand:

• Korrigieren Sie zuerst den Code in der Originalquelle.
• Korrigieren Sie den Code an jeder anderen Stelle.
• Stellen Sie sicher, dass dies alle Orte waren. Wenn Sie sagen, dass dies dem Manager angetan werden musste, wird er wahrscheinlich zumindest jemanden hassen.

Wenn Sie stattdessen das DRY-Prinzip anwenden und versuchen, eine Abstraktion zu finden, die den doppelten Code mehr oder weniger beseitigt, ist das anders. Normalerweise gibt es viele Möglichkeiten, man muss Entscheidungen treffen, recherchieren, kreativ sein. Sie könnten in kürzerer Zeit eine bessere Lösung finden, aber auch scheitern. Die meiste Zeit kann man nicht wirklich sagen, wie viel Arbeit noch übrig ist. Sie sind der schlimmste Albtraum eines Projektmanagers.

Das Entfernen von Duplikaten führt zu einem einzelnen Fehlerpunkt. Wenn etwas fehlschlägt, können Sie sich ziemlich sicher sein, wo dies geschieht. SOLID und Design Patterns helfen dabei, genau dieses Problem zu beheben. Zu kurze Fristen provozieren tendenziell eine "Kodierung" des Verfahrensstils. Mehr Zeit in ein Projekt investiert, um etwas Wiederverwendbares zu erstellen, bedeutet, dass für das nächste Projekt nur wenig Zeit aufgewendet werden muss, wenn das Feature wiederverwendet wird. Es sollte jedoch an erster Stelle konfigurierbar sein .

Natürlich übertreibe ich, aber es gibt offensichtlich ein Dilemma. Meine Fragen sind: Was sind Kriterien, um zu entscheiden, ob ein Entwickler DRY übertreibt? Wie können wir einen guten Kompromiss finden? Oder gibt es eine Möglichkeit, dieses Dilemma vollständig zu überwinden, nicht nur durch die Suche nach einem Kompromiss?

Viele Leute wiesen darauf hin, dass es hier kein Dilemma gibt. Ja und nein.

Wenn Sie etwas sehr Experimentelles haben, das noch nie zuvor gemacht wurde, gibt es kein Dilemma. Andernfalls, wenn Sie etwas haben, das erneut erledigt werden muss, wie zum Beispiel ein neues Buchungssystem, haben Sie bereits Abstraktionen, es hängt nur davon ab, was Sie brauchen.

Ich denke, das Dilemma ist - sollten wir etwas in ein Feature implementieren, wenn es unwahrscheinlich ist, dass es angefordert wird. Implementieren Sie etwas, wenn Sie dazu aufgefordert werden. Niemand braucht eine riesige Infrastruktur, die nicht genutzt wird.

Hier geht es überhaupt nicht um das Design für die zukünftige Wiederverwendung oder um das YAGNI-Prinzip. Es geht darum, den Code im aktuellen Arbeitspaket zu wiederholen.

Es geht absolut um Design. Vielleicht nicht per se wiederverwenden , aber trotzdem designen.

Was sind Kriterien, um zu entscheiden, ob ein Entwickler DRY übertreibt?

Erfahrung und Ihre bestehende Umgebung / Situation. Für ein gegebenes Problem erhalten Sie ein starkes Gefühl für das Prado-Prinzip, wenn Sie versuchen, einen höheren Grad an Trockenheit zu erreichen. Dann spielen plötzlich Managementüberlegungen eine Rolle. Zeit, Ziele, der Kunde, das langfristige Code-Management (jemand sagte technische Schulden ) usw. werden Ihren Angriffsplan informieren.

Wie können wir einen guten Kompromiss finden?

Äh ... Design? Refactoring ist Design, das soll es auch sein. Der Umfang des DRYing kann leicht wie eine Supernova von der Schleife über die Methode bis zur Klasse (n) erweitert werden. Kenne ich schon. Aber Sie können nicht wirklich wissen, bis Sie das Problem studiert haben - das ist Design.

Wie kann es kein Designproblem sein? Sie müssen das Problem umfassender betrachten als den unmittelbar vorhandenen duplizierten Code. Dies ist eine Entwurfsaktivität, unabhängig davon, ob es sich um vorhandenen Code oder ein leeres Blatt handelt. ob es sich um eine "Extraktionsmethode" handelt oder um das Erstellen neuer Klassen und Module.

Epilog

... die vorgelegte Frage und ihre Antworten nicht den Aspekt des Projektmanagements abdecken.

Typische Verwaltung ohne Berücksichtigung der Entwurfszeit. Idealerweise hätten wir die überflüssig redundante Wiederholbarkeit vor dem Codieren entworfen. Stattdessen glaubt das Management, dass Entwicklung (und Fehlerkorrekturen) ein einziges olympisches Ereignis ist - Codierung -, wenn es sich tatsächlich um einen Zehnkampf handelt. Und sie messen auf 1/1000 Sekunde, weil sie denken, dass alles analog ist.

Wenn Sie stattdessen das DRY-Prinzip anwenden und versuchen, eine Abstraktion zu finden, die den doppelten Code mehr oder weniger beseitigt, ist das anders.

Ich hatte folgende Erfahrung: "Ich habe zwei Tage damit verbracht, diese Zeile (eines GUI-Formulars) zu schreiben und zwei Stunden, um den Rest des Formulars zu schreiben." Ich meine, dass ich mir die Zeit genommen habe, wiederverwendbare Klassen zu identifizieren - DRY ist ein natürlicher Nebeneffekt - die GUI-Form-Zeile und w / in einigen anderen. Nach dem Debuggen wurden diese einzeln und in ihrer Zusammensetzung in der gesamten Form verwendet, die jetzt sehr schnell codiert wurde und die Tests trotz des Aufbaus von Komplexität außerordentlich schnell waren. Und es hat auch formale Tests mit einer erstaunlich niedrigen Fehlerrate durchlaufen.

Die meiste Zeit kann man nicht wirklich sagen, wie viel Arbeit noch übrig ist. Sie sind der schlimmste Albtraum eines Projektmanagers.

Ich wusste es auch nicht, aber ich hatte das Vertrauen, dass sich das Design im Vorfeld auszahlen würde. Wir alle sagen das, aber insbesondere das Management vertraut dem nicht. Das Management hätte gedacht, ich würde rumalbern. "Zwei Tage und du hast noch nicht einmal 2% davon codiert!"

In einem Fall hielten wir an unseren Waffen fest, als das Management sagte: "Sie verbringen zu viel Zeit im Design, machen Sie sich auf den Weg." Und Mitarbeiter sagen "es sind zu viele Klassen." Nun, ein weitaus weniger komplexes Unterprojekt sollte ungefähr 1 Monat dauern (ich dachte, es wäre in Ordnung), aber es dauerte 5 Monate. 3 Monate davon waren im Testen / Reparieren, weil es so ein POS war. "Aber wir hatten keine Zeit zum Entwerfen!" Das haben sie tatsächlich gesagt.

Meine Fragen sind: Was sind Kriterien, um zu entscheiden, ob ein Entwickler DRY übertreibt? Wie können wir einen guten Kompromiss finden? Oder gibt es eine Möglichkeit, dieses Dilemma vollständig zu überwinden, nicht nur durch die Suche nach einem Kompromiss?

Zeigen Sie dem Management, wie es funktioniert. Erfassen Sie einige Daten. Vergleichen Sie dies mit anderen Arbeiten, insbesondere denen Ihrer Kollegen, die den Slap-Dash-Rush-Job erledigen. Dieser Haufen von Fehlern scheint immer das Rennen zu verlieren, bleibt im Test stecken und kehrt nach der Veröffentlichung immer wieder zurück, um weitere Fehler zu beheben.