Ist DRY der Feind des Softwareprojektmanagements?

83

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 :).

Frank Puffer
quelle
96
Lassen Sie uns wissen, wie sich Ihre Projektmanager fühlen, wenn es darum geht, in 100 dieser kopierten und eingefügten Instanzen etwas zu finden, zu ändern und zu testen. Und vergessen Sie nicht die zusätzliche Zeit, die aufgewendet wird, um herauszufinden, warum es kaputt geht, weil nur 98 von ihnen tatsächlich gewechselt wurden.
Blrfl
16
@Blrfl Auf der anderen Seite kann das vorzeitige DRY-up von Code, bevor eine gute Abstraktion klar ist, auch die Produktivität beeinträchtigen, da eine gemeinsame Abstraktion eine gemeinsame Abhängigkeit ist. Ich bin übrigens nicht anderer Meinung und weise nur darauf hin, dass definitiv ein Gleichgewicht gefunden werden muss.
GoatInTheMachine
16
Das Prinzip, das verhindert, dass DRY außer Kontrolle gerät, ist das YAGNI- Prinzip (Du wirst es nicht brauchen) .
Philipp
88
Es gibt kein Dilemma. Wenn der Projektmanager möchte, dass Sie viel überflüssige manuelle Arbeit erledigen, da diese leicht abzuschätzen ist, ist es die naheliegende Lösung, den Projektmanager zu entlassen.
JacquesB
10
Wenn Sie sich wiederholen, müssen Sie noch all diese anderen, schwer abzuschätzenden Arbeiten sowie einige zusätzliche sinnlose Arbeiten ausführen. Wie hilft das dem Projekt?
user253751

Antworten:

134

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.

JacquesB
quelle
21
Ich stimme Ihren Behauptungen hier voll und ganz zu, aber ich denke, es muss angemerkt werden, dass es viele miese Projektmanager gibt, die wirklich Vorhersagbarkeit vor Geschwindigkeit oder Qualität bevorzugen. Die meisten Leute, die keine Ausbildung in Projektmanagement haben, lernen, was sie darüber wissen, und ich habe die Erfahrung gemacht, dass es nur wenige Projektmanager gibt, die mit Unsicherheiten auf ruhige, rationale Weise umgehen können.
JimmyJames
5
@FrankPuffer Ich war dort. Wie lange wird es dauern? Eine Möglichkeit besteht darin, einen Bereich anzugeben. Informieren Sie sich bei PERT speziell über 3-Punkte-Schätzungen, da diese bereits darüber Bescheid wissen sollten. Prozentsatz abgeschlossen? Das ist das nervigste. Versuchen Sie es zu ignorieren, aber wenn Sie sich nicht daran erinnern können, dass es prozentuale Zeit ist, nicht prozentuale Anzahl der codierten Zeilen oder was auch immer. Was sie wirklich wissen wollen, ist, wann es abgeschlossen sein wird? Geben Sie frühzeitig konservative Vorhersagen für jede Aufgabe und verfeinern Sie diese bei Bedarf. Das Warten bis zur letzten Minute, um Ihnen mehr Zeit zu sagen, wird die Leute verrückt machen.
JimmyJames
11
Wie lange wird es dauern? Ich bin zu 60% sicher, dass wir es mit x beenden können, aber es besteht eine 10% ige Chance, dass es fünfmal so lange dauert.
David
18
@David: Das würde den PM wahrscheinlich verrückt machen, weil er aus Erfahrung weiß, dass diese 10% ige Chance tatsächlich 80% der Fälle vorkommt :)
Frank Puffer
7
Die Realität ist, dass viele Orte gerne ein Projekt in den Boden verfolgen würden, um dann unerwartet erfolgreich zu sein. Die PMs werden oft dafür belohnt, genaue Projektionen zu haben, damit sie perverse Anreize haben. Dies ist das Prinzipal-Agent-Problem .
Schlitten
39

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.

Doc Brown
quelle
4
Wahrscheinlich eine gute Antwort, aber viel zu ausführlich im Vergleich zu anderen guten Antworten.
Vince O'Sullivan
4
Sie können DRY ignorieren, wenn "die Kopie in Zukunft nicht mehr gewartet oder weiterentwickelt werden muss", aber Code, der nie wieder verwendet wird, wird oft ohnehin wieder verwendet.
Andy Lester
"Kopieren-Einfügen funktioniert super ..." - nicht einverstanden! Selbst wenn das Programm einmalig ist und garantiert nie über die ursprüngliche Version hinaus entwickelt wird, erhöht das Kopieren und Einfügen von Code die Arbeit und das Risiko, Fehler zu beheben, die während der Entwicklung der ursprünglichen Programmversion aufgetreten sind. Es sei denn, Sie machen niemals Fehler. In diesem Fall sind Sie ein Gott.
JacquesB
1
@JacquesB: Du solltest meine Antwort genauer lesen, ich habe nichts anderes geschrieben.
Doc Brown
Computerprogrammierung unterscheidet sich lediglich vom Bau identischer Maschinen mit einer Montagelinie. Huh. Wer hätte das gedacht? Vielleicht sollten wir Programmierer als PMs haben. Aber dann brauchen wir Programmierer als Manager. Programmierer als Gesellschafter. Programmierer als Kunden ... Schießen Sie, bringen Sie jedem bei, wie man programmiert und wie man damit fertig wird. (Mit anderen Worten: Nicht-Experten werden die Wechselfälle, die Experten bekannt sind, niemals verstehen.)
19

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.

Telastyn
quelle
2
Ich würde behaupten, dass die meisten Ingenieurberufe "jeden Tag etwas Neues machen"
BlueRaja - Danny Pflughoeft
12
@ BlueRaja-DannyPflughoeft: Nicht wirklich. Nachdem ich als Elektronik- / Elektrotechniker gearbeitet habe, kann ich beweisen, dass es bei den meisten großen Ingenieurberufen (Projekte, bei denen eine Inbetriebnahme wie der Bau von Schiffen und Kraftwerken erforderlich ist) darum geht, sicherzustellen, dass die Leute etwas Bewährtes richtig machen. Das ist es, was Unternehmen als "Engineering" bezeichnen. Etwas Neues zu machen ist "R & D"
Slebetman
3
@slebetman Vielleicht haben Sie einfach nicht die ganze Arbeit bemerkt, die Ihr Management geleistet hat. Selbst wenn Sie immer wieder das Gleiche tun, ändert sich die Umgebung jedes Mal. Sie haben keine Vorlage für ein Kraftwerk, die Sie einfach an einen Kunden liefern und damit fertig sind. Sie müssen eine Vermessung durchführen. Finden Sie heraus, wie Sie die Anlage mit Rohstoffen versorgen und das Produkt wieder ausliefern, verwalten Sie alle Rohstoffe für den Bau und kümmern Sie sich um Versorgungsprobleme, Arbeitskräftemangel und eine Million andere Dinge. Es sieht aus wie Template-Arbeit (wie viele Software-Anstrengungen), aber es ist wirklich nicht.
Luaan
1
@Luaan: Ja, aber nichts davon macht etwas Neues. Sie alle tun "etwas, von dem wir wissen, wie es geht". Softwareentwicklung ist anders. In erster Linie, weil wir in Software im Gegensatz zu physischen Konstruktionsprojekten dazu neigen, Dinge, die wir bereits in Bibliotheken wissen, zu kapseln, damit wir nicht manuell die Vermessung usw. durchführen müssen. Wir würden einfach eine Bibliothek dafür importieren und sie verwenden .
Slebetman
2
@slebetman Fast die gesamte Software, die geschrieben wird, ist "etwas, von dem wir wissen, wie man es macht". Bibliotheken auch leben in einem Umfeld , das immer verändert. Außerdem verfügen Sie nicht über 100% iges Wissen und Erfahrung mit der gesamten Bibliothek und allen Abhängigkeiten dieser Bibliothek und den anderen Abhängigkeiten, und es gibt viele seltsame Systeme und Hardwarekonfigurationen, die sich einfach weigern, so zu funktionieren, wie es ein vernünftiges System tun sollte Arbeit. Die Kapselung ist großartig, aber immer noch verdammt teuer und erfordert eine Menge Vermessung. Und das Engineering hat auch Verkapselung - vorgefertigte Blöcke, ICs usw.
Luaan
12

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.

Kevin Cline
quelle
Ich denke, es ist ein besseres Gehirn als eine bessere Technologie. Technologie kommt aus dem Gehirn, oder? Was ist aus "Think Smarter, not harder" geworden?
10

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.

Robbie Dee
quelle
6
Beachten Sie, dass dies bedeutet, dass Sie kommentieren sollten, dass Sie den Code (an beiden Stellen) kopiert haben, damit Sie wissen, ob Sie ihn erneut kopieren möchten, sollten Sie dies nicht tun!
Mark Hurd
3
Ich habe dies in einem Fall getan, in dem zwei Klassen dieselbe Methode benötigten, aber kaum verwandt waren - ähnlich wie entfernte Cousins. Ich hätte fast einem Dutzend Klassen Abhängigkeiten hinzufügen müssen, damit sie tatsächlich den Code teilen. Also gefiel mir, was Mark vorschlug - ich habe die Methode kopiert und auch einen großen, offensichtlichen Kommentar hinterlassen, der auf die andere Stelle für diese Methode hinwies.
Jeutnarg
@ MarkHurd Yep - großer Punkt ...
Robbie Dee
8

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.

Thomas Owens
quelle
Klar, Softwareentwicklung ist Wissensarbeit. Eigentlich würde ich mein erstes Beispiel (Kopieren / Einfügen) nicht als Softwareentwicklung im engeren Sinne bezeichnen. Die Verwaltung dieser Art von Arbeit ist jedoch sehr viel schwieriger, sodass der Ministerpräsident, auch wenn er über einen Entwicklungshintergrund verfügt und all dies weiß, in seiner Rolle als Ministerpräsident diese eher ignoriert. (Ich sage nicht, dass dies eine gute Sache ist, es ist genau das, was ich oft beobachtet habe. Ich denke auch nicht, dass diese PMs dumm oder inkompetent sind. Es ist eher so, als würde die Rolle sie manchmal dazu zwingen, sich so zu verhalten. )
Frank Puffer
3
@FrankPuffer Ich stimme nicht zu, dass die Rolle des Projektmanagers die Person dazu zwingt, bestimmte Entscheidungen zu treffen. Es ist eher eine erzieherische oder organisatorische Kraft. Wie ich gesehen habe, konzentriert sich die meiste Projektmanagementausbildung auf traditionellere Projektmanagementtechniken (wahrscheinlich, weil sie häufiger auf mehr Projekte anwendbar sind) als auf Softwareprojektmanagementtechniken. Dies kann sich auf Unternehmen auswirken, die dies erwarten und sich nicht mit anderen Techniken für die Verwaltung von Wissensarbeitsprojekten wie der Softwareentwicklung befassen.
Thomas Owens
2
@FrankPuffer Sicher ist es härter, aber es bietet mehr Wert. Wenn der Chef Ihres Chefs klug genug ist, wird er den Manager los, der versucht, "die Dinge für sich selbst einfacher zu machen" und jemanden zu finden, der seine Arbeit tatsächlich erledigen kann. Verstehen Sie mich nicht falsch, wenn das Erleichtern von Dingen Wert schafft, machen Sie es - aber was Sie beschreiben, geht dies mit ziemlicher Sicherheit zu Lasten des Endwerts.
Luaan
4

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.

Peter ist
quelle
Das ist ein guter Punkt. DRY oder ähnliche Prinzipien gelten jedoch auch für andere Aufgaben wie Testen oder Integration. Die meisten Dinge können mechanisch, ohne viel nachzudenken oder intelligenter ausgeführt werden. Die intelligenten Lösungen sind oft viel schneller, bergen jedoch die Gefahr eines Ausfalls. Außerdem müssen Sie eine Menge Arbeit in sie stecken, bevor Sie ein Ergebnis erhalten.
Frank Puffer
Es gibt kein "Risiko eines Ausfalls", es gibt eine Gewissheit des Ausfalls. Alles wird früher oder später scheitern. Sie entscheiden nur, wie teuer der Leichenwagen ist und wie schnell Sie fahren.
4

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 .

Brad Thomas
quelle
Der Projektmanager sollte sich natürlich nicht mit Implementierungsdetails befassen. Das ist nicht mein Punkt. Mein Punkt ist, dass er je nach Art und Weise, wie ein Entwickler etwas implementiert, mehr oder weniger in der Lage ist, die für das Projektmanagement erforderlichen Informationen bereitzustellen.
Frank Puffer
Es macht für mich keinen Sinn, das Produkt zu beschädigen / einzuschränken oder technische Schulden aufzunehmen, nur um besser darüber berichten zu können. Der Wert des Berichts muss mit Sicherheit um Größenordnungen niedriger sein als der Wert der Qualitätsarbeit. Aber YMMV
Brad Thomas
Vielleicht sollten Programmierer Größenordnungen mehr als Manager bezahlt werden?
2

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.

Ewan
quelle
7
Ich stimme nicht zu. Vererbung ist nichts, was man einmal macht und dann meistert. Es gibt viele Fallstricke. Es gibt Gründe, warum die Zusammensetzung der Vererbung vorgezogen werden sollte. Wir müssen also eine Entscheidung treffen: Vererbung? Komposition? Etwas anderes? Diese Entscheidung wird wahrscheinlich in der realen Welt schwierig sein. Im zweiten Beispiel gibt es auch viele Alternativen. Was ist mit Generika / Vorlagen? Oder vielleicht ein funktionaler Ansatz mit Lambdas? Nochmals: Viele Möglichkeiten, von denen jede spezifische Auswirkungen haben wird.
Frank Puffer
4
Der Punkt ist, dass Sie im ersten Beispiel doppelten Code buchstäblich mit einer beliebigen Methode entfernen. aber genau derselbe Code wird in beiden Richtungen ausgeführt. Es gibt also keine Funktionsänderung. Im zweiten Beispiel ändern Sie den Ansatz auf etwas, von dem Sie hoffen, dass es funktional äquivalent ist, dass es sich jedoch tatsächlich um einen anderen Code handelt
Ewan,
1
Ich befand mich in einer Situation, in der Ihre "Notfallanfrage" die Norm war. Die Firma, für die ich gearbeitet habe, erstellte kundenspezifische Datensysteme für viele verschiedene Kunden. Zuerst erstellten sie ein System mit Cobol und kopierten es dann für den nächsten Kunden usw., bis sie 100 Kunden hatten. Jetzt hatten sie einen Job in der Hand, um systematische Verbesserungen und Aktualisierungen vorzunehmen. Ich arbeitete an einem System, das das Verhalten der meisten dieser Systeme reproduzieren konnte, wobei ein einzelner Satz Quellcode, aber in Konfigurationsdaten gespeicherte Anpassungen verwendet wurden. Wir konnten nicht alles tun und einige Dinge konnten nicht hinzugefügt werden.
1

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.

Bakudan
quelle
Implementiere jetzt etwas auf die einfache, schnelle Art, denn das wurde verlangt. Wenn später ein komplexer Weg benötigt wird, ist der ursprüngliche Aufwand umsonst und muss von vorne beginnen. Manager mag das nicht. Als ob Sie sagten: "Die Zeit, die wir mit der Fahrt nach Westen verbringen, war nutzlos, wenn wir jetzt nach Osten müssen." Aber es ist auch Zeitverschwendung, das erste Mal die ganze Welt zu bereisen, nur damit wir die ganze Zeit nach Osten gehen können.
1

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.

Radarbob
quelle
"Mit einem Mikrometer messen, mit Kreide markieren, mit einer Axt schneiden."