it-swarm.com.de

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ätzung, Zeitplanung, Kontrolle)? 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 vorhandenen Code 100 Mal kopieren und bei Bedarf geringfügige Anpassungen an jeder Kopie vornehmen. Sie wissen jederzeit genau, wie viel Arbeit Sie geleistet haben und wie viel noch übrig ist. Alle Manager werden Sie lieben.

Wenn Sie stattdessen das Prinzip DRY] anwenden und versuchen, eine Abstraktion zu finden, die den doppelten Code mehr oder weniger eliminiert, sind die Dinge anders. Normalerweise gibt es viele Möglichkeiten, Sie müssen Entscheidungen treffen, Nachforschungen anstellen Seien Sie kreativ. Sie könnten in kürzerer Zeit eine bessere Lösung finden, aber Sie könnten auch scheitern. Meistens können Sie 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: Nach welchen Kriterien kann ein Entwickler DRY übertreiben? Wie können wir einen guten Kompromiss finden? Oder gibt es eine Möglichkeit, dieses Dilemma vollständig zu überwinden, indem nicht nur ein Kompromiss gefunden wird?

Hinweis: Diese Frage basiert auf der gleichen Idee wie meine vorherige, mfang der Routinearbeit in der Softwareentwicklung und ihre Auswirkung auf die Schätzung , aber ich denke, es macht meine Punkt klarer, also tut mir leid, dass ich mich wiederholt habe :).

82
Frank Puffer

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 das gleiche wie für Entwickler: Wert 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 es bezweifle), bietet dem Kunden jedoch kein gutes Preis-Leistungs-Verhältnis, sodass es einfach ein schlechtes Projektmanagement ist. Es gibt kein Dilemma.

Es ist bekannt, dass die Schätzung von Softwareprojekten schwierig ist, und es wurden zahlreiche Bücher geschrieben und verschiedene Verfahren entwickelt, um sie zu verwalten.

Wenn das nur Ziel des PM) darin bestand, genaue Schätzungen zu erstellen, wäre es einfach. Füllen Sie die Schätzungen einfach auf das 10-fache und lassen Sie die Entwickler Spiele für das spielen ruhen Sie sich aus, wenn sie früh fertig sind. Dies wäre tatsächlich besser als Ihr Vorschlag, die Zeit mit Copy-Paste-Arbeit zu füllen, da das Spielen die Leistung des Produkts nicht beeinträchtigt.

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

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

133
JacquesB

Sie haben Recht - Copy-Paste funktioniert hervorragend, und DRY hat keinen Sinn, wenn Sie ein Programm erstellen möchten, für das entweder die kopierte Vorlage oder die Kopie nicht gepflegt oder weiterentwickelt werden muss die Zukunft. Wenn diese beiden Softwarekomponenten einen völlig unterschiedlichen Lebenszyklus haben, kann das Koppeln durch Umgestaltung von gemeinsamem Code in eine gemeinsame Bibliothek, die sich selbst in einer intensiven Entwicklung befindet, tatsächlich unvorhersehbare Auswirkungen auf den Aufwand haben In Abschnitten innerhalb eines Programms oder Programmsystems haben alle diese Teile normalerweise den gleichen Lebenszyklus. Ich werde im Folgenden veranschaulichen, was dies für DRY und Projektmanagement) bedeutet.

Im Ernst, es gibt viele solcher Programme: Zum Beispiel produziert die Computerspielbranche viele Programme, die über einen kurzen Zeitraum von einigen Monaten oder maximal einem Jahr gewartet werden müssen, und wenn diese Zeit abgelaufen ist, das Einfügen von Texten Alter Code aus einem früheren Spiel, bei dem die Wartungszeit überschritten wird, 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 mich in den letzten Jahren befassen musste, stark davon. 98% der Anforderungen oder Fehlerbehebungsanforderungen, die bei mir eingingen, waren Änderungsanforderungen für vorhandene Programme. Und wann immer Sie etwas an einer vorhandenen Software ändern müssen, funktioniert "Projektmanagement" oder Planung am besten, wenn Ihr Test- und Debugging-Aufwand recht gering ist - was nicht der Fall ist, wenn Sie etwas an einem Ort ändern, sondern aufgrund einer Kopie -verwandte Geschäftslogik, die Sie leicht vergessen, dass Sie auch ein Dutzend anderer 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 wenn Sie eine genaue Schätzung für die Änderung vornehmen könnten, könnten die Kosten, die ein Dutzend Mal höher sind als erforderlich, leicht mit dem Projektbudget kollidieren.

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 gerne kopieren. Wenn Sie, Ihr Team oder Ihr Unternehmen jedoch verantwortlich sind oder werden könnten, wenden Sie DRY an, wann immer Sie können.

Beispiel

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

Die Aufgabe: Erstellen Sie 100 verschiedene Berichte für eine Anwendung, wobei jeder Bericht sehr ähnlich aussieht, einige Anforderungsunterschiede zwischen den Berichten, einige unterschiedliche 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 geringfügigen Fehlerkorrekturen aufgrund der Qualitätssicherung und der Kundeninspektion scheint sie einwandfrei zu laufen. 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 benötigte er 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. Wenn nun das Prinzip DRY] angewendet wurde, 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 bestehen 100-mal statt einmal gelöst. Und aufgrund der Änderungen, die bereits von einem Bericht in einen anderen übernommen wurden, kann der Entwickler den Fix für den ersten Bericht nicht schnell kopieren und in den anderen 99 einfügen. Er muss alle 100 Berichte prüfen und lesen , übersetzen Sie die Änderung in den geänderten Bericht, testen Sie sie und debuggen Sie sie möglicherweise einzeln. Für den PM wird dies sehr schwierig - er kann sich natürlich die Zeit für eine "normale" Fehlerbehebung nehmen (sagen wir 3 Stunden) ) und multiplizieren Sie dies mit 100, aber tatsächlich ist dies höchstwahrscheinlich eine falsche Schätzung. Einige der Korrekturen sind möglicherweise einfacher durchzuführen als andere, andere sind möglicherweise schwieriger. Und selbst wenn diese Schätzung korrekt ist, kostet das Debuggen das 100-fache Hoch, wie sie sein mussten, kostet Sie Unternehmen viel Geld.

Dasselbe passiert beim nächsten Mal, wenn der Kunde in all diesen Berichten die Farbe seines Firmenemblems ändern, die Seitengröße konfigurierbar machen oder eine andere neue Anforderung, die alle Berichte auf ähnliche Weise betrifft. 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 zahlen müsste, wenn der Code trocken gewesen wäre. Versuchen Sie dies jedoch einige Male, und dann wird der Kunde das Projekt abbrechen, da er wahrscheinlich nicht bereit ist, Ihre exorbitanten Entwicklungskosten zu bezahlen. Und vielleicht wird an diesem Punkt 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 produzieren, haben Sie immer zumindest für kurze Zeit die Verantwortung, das Ding zum Laufen zu bringen, Fehler zu beheben, das Programm an sich ändernde Anforderungen anzupassen usw. Auch in einem Green-Field-Projekt 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 für die Verantwortung für alle Teile gleich. Dies unterscheidet sich erheblich von der Situation, in der Sie älteren Code aus einem nicht mehr vorhandenen toten Projekt kopiert haben unter aktiver Wartung.

39
Doc Brown

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

Ihre Basisaussage ist falsch.

Das, was Software anders von anderen Berufen unterscheidet, ist, dass Sie jeden Tag etwas Neues machen. Schließlich wird kein Kunde Sie bezahlen, um etwas zu bauen, das bereits jemand anderes gemacht hat. Projektmanager mögen vielleicht Vorhersehbarkeit, aber ihre Chefs mögen Wert. Wenn Sie nur Code mit geringfügigen Abweichungen kopieren und einfügen, bieten Sie dem Unternehmen nicht viel Wert.

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

19
Telastyn

Das Programmieren durch Ausschneiden und Einfügen führt schließlich zu einer aufgegebenen 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 durchgeführt wurden und kein Arbeitscode geändert werden sollte. Die kleinste Verbesserung könnte zu einer neuen Kopie von Hunderten von Codezeilen führen. Ursprünglich wurde die Anwendung für die Verwaltung von Konten mit bis zu zwölf physischen Zeilen geschrieben. Natürlich wurde diese Einschränkung an Hunderten von Stellen im Code vorgenommen. Nach ungefähr vier Jahren fragte das Geschäft das Team, was nötig sei, um größere Konten abzuwickeln. Sie schätzten ungefähr 18 Millionen Dollar. Zu diesem Zeitpunkt wurde das Projekt für minimale Wartung an ein Offshore-Team übergeben. Das bestehende Team wurde entlassen.

Unternehmen, die so denken, werden von Unternehmen mit besserer Technologie niedergeschlagen.

12
kevin cline

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

3 mag wie eine beliebige Zahl erscheinen, aber ein häufiges Szenario ist, dass Daten und Logik in einer Anwendung und Datenbank dupliziert werden. Ein häufig genanntes Beispiel ist eine Nachschlagetabelle in der Datenbank und eine Aufzählungsclientseite. Aufgrund der unterschiedlichen Paradigmen kann dies nicht ohne weiteres an einem einzigen Ort gespeichert werden, sodass die Informationen häufig an beiden Orten angezeigt werden.

Es ist zwar schön, DRY Code) zu haben, aber es kann vorkommen, dass die Geschäftslogik eine Ausnahme vorschreibt und Sie daher zwei oder mehr Codebits aus einer zuvor generischen Quelle erstellen müssen.

Also - was tun? Code für den Status Quo (immerhin YAGNI ). Während Code geschrieben werden sollte, um das Ändern zu vereinfachen, ist das Schreiben einer ganzen Reihe von Schnickschnack für etwas, das möglicherweise nicht benötigt wird, nur ein Fackelgeld.

10
Robbie Dee

In Ihrer Frage listen Sie nur drei Funktionen des Projektmanagements auf - Schätzung, Zeitplan und Kontrolle. Beim Projektmanagement geht es darum, Ziele innerhalb der Projektbeschränkungen zu erreichen. Die Methoden zum Erreichen von Zielen innerhalb der Einschränkungen eines Projekts unterscheiden sich für Softwareprojekte von vielen anderen Projekttypen. Sie möchten beispielsweise, dass Herstellungsprozesse in hohem Maße wiederholbar und verständlich sind. Die Softwareentwicklung ist jedoch meistens Wissensarbeit - nicht routinemäßig und erfordert eher Nachdenken als das Befolgen strenger Anweisungen und Verfahren. Die Techniken zum Initiieren, Planen, Ausführen, Überwachen und Steuern sowie zum Schließen eines Softwareprojekts müssen die Art der Arbeit berücksichtigen, die an einem Softwareprojekt ausgeführt werden muss - insbesondere nicht routinemäßige Arbeiten, die nicht ausgeführt werden können zu spezifischen Anweisungen und Verfahren.

Ich denke, das andere Problem ist, dass Sie DRY verwenden, ein Konzept, das sich auf die Wiederholung von Informationen bezieht, und versuchen, es auf die Verwaltung von Aufgaben anzuwenden. DRY sagt einfach, dass Sie nur eine maßgebliche Darstellung von Informationen haben sollten. Projektmanager sollten dies berücksichtigen, da dies bedeutet, dass jeder weiß, wo er die Informationen abrufen muss. Änderungen werden einfach kommuniziert. und die Änderungen können gut kontrolliert und verwaltet werden. DRY hilft durch wiederverwendbare Teile, die langfristigen Kosten niedrig zu halten, langfristige Zeitpläne einzuhalten und die Qualität zu verbessern - drei Teile des Projektmanagement-Dreiecks . 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 in Einklang zu bringen.

8
Thomas Owens

DRY ist nützlich, aber auch überbewertet. Manche Leute können es zu weit bringen. Was viele Entwickler nicht erkennen, ist, dass Sie jedes Mal, wenn Sie DRY] implementieren, um dieselbe Methode für zwei (leicht) unterschiedliche Zwecke zu verwenden, eine Art sehr enge Kopplung zwischen den verschiedenen Verwendungszwecken einführen Wenn Sie den Code für den ersten Anwendungsfall ändern, müssen Sie auch prüfen, ob er den zweiten Anwendungsfall zurückführt. Wenn es sich um weitgehend unabhängige Anwendungsfälle handelt, ist es sehr fraglich, ob sie eng miteinander verbunden sein sollten - wahrscheinlich nicht.

Eine Überbeanspruchung von DRY kann auch zu Gott-Methoden führen, die in ihrer Komplexität explodieren, um all die verschiedenen Anwendungsfälle zu behandeln, denen sie ausgesetzt sind, wenn im Allgemeinen kleinere atomare Methoden, die Code replizieren, viel wären wartbarer.

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

EDIT: pro Kommentar stimme ich jedoch zu, dass insofern es einfacher ist, Schätzung Entwicklungszeit, Vermeidung von DRY kann manchmal die Menge an Unsicherheit verringern. Aber ich glaube das ist eine unbedeutende Frage in Bezug auf die dringlicheren Fragen: (1) wie lange es dauert, bis die Geschäftsanforderungen erfüllt sind, (2) welche technischen Schulden dabei berücksichtigt werden und (3) Risiken für die Gesamtbetriebskosten der Architektur bestehen getroffene Entscheidungen - ob Sie gehen möchten DRY oder nicht, ist in vielen Fällen eine Entwurfsentscheidung, die mehr auf dem Risiko/Ertrag dieser Faktoren basieren sollte, als darauf, ob es ein wenig einfacher ist, ein Projekt bereitzustellen Manager mit genaueren Informationen.

4
Brad Thomas

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. Dies jedoch nicht ausreicht, um tatsächlich etwas Neues zu bringen (egal ob es sich um ein brandneues System, eine Hinzufügung von Funktionen oder eine Änderung der Funktionalität handelt), reicht nicht aus und ist nur eine Minderheit der Arbeit - die Schätzungen in der Literatur belegen dies in der Praxis Teil ist so etwas wie 20% -40% der gesamten Arbeit.

Der Großteil der Arbeit (einschließlich der Anpassung Ihrer anfänglichen Entwicklung an das, was tatsächlich benötigt wurde, Integration, Testen, Umschreiben, erneutes Testen) ist daher nicht einfacher abzuschätzen. Umgekehrt wurde absichtlich vermieden, dass DRY hat diesen Teil viel größer, schwieriger und mit variableren Schätzungen gemacht - dieser Fehler oder Änderungsbedarf, bei dem alle geklonten Teile geändert werden müssen, tritt möglicherweise nicht auf , aber wenn ja, dann werden Ihre Schätzungen total falsch sein.

Sie erhalten keine besseren Schätzungen, wenn Sie die Schätzqualität eines kleinen Teils der Arbeit verbessern, sondern die Qualität eines großen Teils der Arbeit verschlechtern. Es ist also nicht wirklich ein Kompromiss, sondern eine Situation, in der Sie eine schlechtere Produktivität, aber auch schlechtere Schätzungen erhalten.

4
Peteris

Ich denke, Sie verstehen DRY falsch.

Verwenden 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;
    }
}

vs.

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

Durch das Ersetzen von Klasse B durch C haben wir das DRY -Prinzip und reduzierte Codeduplizierung befolgt. Wir haben jedoch die Unbekannten oder das Risiko für das Projekt nicht erhöht (es sei denn, Sie haben noch nie eine Vererbung durchgeführt).

Ich denke, was du meinst, wenn du über DRY) sprichst, ist eher eine Designaufgabe.

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

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

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

vs.

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 (vorausgesetzt, es funktioniert) eine Lösung entworfen, die sowohl die alten als auch die neuen Anforderungen erfüllen 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 es wird einige Zeit dauern, bis die Edge-Fälle und unerwarteten Ergebnisse gefunden und korrigiert sind.

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

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

  • Eine Version 2 führt in Zukunft zu weniger Gesamtcode und ist die elegantere Lösung

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-Fälle und die Abwärtskompatibilität abdecken, können wir sicher sein, dass wir das System gut genug verstehen, um das Modell ohne Fehler zu überarbeiten.

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. Sowohl das Brechen anderer Kunden als auch das Überschreiten der Frist aufgrund der zusätzlichen unbekannten Zeit, die zum Entwerfen und Testen der Lösung benötigt wird.

2
Ewan

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ätzung, Zeitplanung, Kontrolle)? Richtige, sich wiederholende Aufgaben, genau die Aufgaben, die laut DRY vermieden werden sollten.

Wiederholte Aufgaben sollten automatisiert werden, obligatorisch. 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 vorhandenen Code 100 Mal kopieren und bei Bedarf geringfügige Anpassungen an jeder Kopie vornehmen. Sie wissen jederzeit genau, wie viel Arbeit Sie geleistet haben und wie viel noch übrig ist. Alle Manager werden Sie lieben.

Ich denke, Sie können das Wort "Anpassung" mit "Konfiguration" ändern. Angenommen, Sie haben einen Fehler in diesem Code, der kopiert werden soll. Ein Fehler, der unter bestimmten Bedingungen auftritt. Wenn es in der Originalquelle nicht behoben und kopiert wird, müssen viele Stellen behoben 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 Prinzip DRY] anwenden und versuchen, eine Abstraktion zu finden, die den doppelten Code mehr oder weniger eliminiert, sind die Dinge anders. Normalerweise gibt es viele Möglichkeiten, Sie müssen Entscheidungen treffen, Nachforschungen anstellen Seien Sie kreativ. Sie könnten in kürzerer Zeit eine bessere Lösung finden, aber Sie könnten auch scheitern. Meistens können Sie 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 ziemlich sicher sein, wo dies passiert. SOLIDE. und Design Patterns helfen dabei, genau dieses Problem zu beheben. Zu kurze Fristen führen tendenziell zu einer "Codierung" des Verfahrensstils. Mehr Zeit in ein Projekt investiert, um etwas Wiederverwendbares zu erstellen, bedeutet, dass im nächsten Projekt nur wenig Zeit für die Wiederverwendung der Funktion aufgewendet werden muss, aber es sollte konfigurierbar sein an erster Stelle.

Natürlich übertreibe ich, aber es gibt offensichtlich ein Dilemma. Meine Fragen sind: Nach welchen Kriterien kann ein Entwickler DRY übertreiben? Wie können wir einen guten Kompromiss finden? Oder gibt es eine Möglichkeit, dieses Dilemma vollständig zu überwinden, indem nicht nur ein Kompromiss gefunden wird?

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 hängt es nur davon ab, was Sie benötigen, wenn Sie etwas haben, das erneut erledigt werden muss, wie z. B. ein neues Buchungssystem.

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.

1
Bakudan

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

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

Nach welchen Kriterien kann ein Entwickler DRY übertreiben?

Erfahrung und Ihre bestehende Umgebung/Situation. Für ein bestimmtes Problem erhalten Sie ein starkes Gefühl für das Prado-Prinzip, wenn Sie versuchen, ein höheres Maß 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 Super-Nova von der Schleife über die Methode bis zur Klasse (n) erweitert werden. Kenne ich schon. Aber Sie können es nicht wirklich wissen, bis Sie das Problem untersucht haben - das ist Design.

Wie kann es kein Designproblem sein? Sie müssen das Problem umfassender betrachten als den unmittelbar vorhandenen doppelten 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 betreffende Frage und ihre Antworten decken nicht den Aspekt des Projektmanagements ab.

Typisches Management, das die Entwurfszeit ignoriert. Idealerweise hätten wir die überflüssig redundante Wiederholbarkeit vor dem Codieren entworfen. Stattdessen glaubt das Management, dass Entwicklung (und Fehlerbehebungen) 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 Prinzip DRY] anwenden und versuchen, eine Abstraktion zu finden, die den doppelten Code mehr oder weniger eliminiert, sind die Dinge anders.

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

Meistens 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 der Aufwand für das Design im Voraus auszahlen würde. Wir alle sagen das, aber insbesondere das Management vertraut ihm nicht. Das Management hätte gedacht, ich würde herumdrehen. "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 mit Design, machen Sie sich auf den Weg." Und Mitarbeiter sagen: "Es sind zu viele Klassen." Nun, ein weitaus weniger komplexes Teilprojekt sollte ungefähr 1 Monat dauern (ich dachte, es wäre in Ordnung, aber ich brauchte 5 Monate). 3 Monate davon waren in Tests/Reparaturen, weil es so ein POS war. "Aber wir hatten keine Zeit zum Entwerfen!" Das haben sie tatsächlich gesagt.

Meine Fragen sind: Nach welchen Kriterien kann ein Entwickler DRY übertreiben? Wie können wir einen guten Kompromiss finden? Oder gibt es eine Möglichkeit, dieses Dilemma vollständig zu überwinden, indem nicht nur ein Kompromiss gefunden wird?

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

1
radarbob