Diskussion:YAGNI

"[...] Programme so zu entwickeln, dass Anforderungsänderungen leicht umzusetzen sind [...]"

Dies ist bei XP auch der Fall.

Falls YAGNI berücksichtigt wird, ist ein schmaleres Programm das Ergebnis -> Anderungen sind hier auch leicht umzusetzen. (nicht signierter Beitrag von 213.144.1.62 (Diskussion) )

Da hast du Recht. Ich habe jetzt versucht, den Text etwas weniger missverständlich zu formulieren. --jpp ?! 11:05, 21. Dez. 2006 (CET)

Abgrenzung

Es geht um folgende Ergänzung von @TwoThe:: https://de.wikipedia.org/w/index.php?title=YAGNI&oldid=199108496&diff=cur&diffmode=source

Die Ausführungen stimmen mMn nicht:

1. YAGNI kann sicher nicht "nur dann angewendet werden, wenn die Anforderungen auch bekannt sind." Im Gegenteil, gerade dann wenn die Anforderungen nicht bekannt sind sollte YAGNI verwendet werden, sonst werden unnötige Dinge umgesetzt. Gerade bei öffentlichen APIs wäre es katastrophal, wenn diese unnötige Funktionen "auf Vorrat" implementieren, da dies nicht nur die Applikation selbst verkompliziert (und somit die nötigen Funktionen hintanstellt), sondern auch die Anwender der API verwirrt, da sie vor lauter (unnötigen) Funktionen die für sie nötigen & sinnvollen Funktionen nicht finden. Statt dessen sollte man (was auch üblich ist) auf die Anwender der API hören und sukzessive die von ihnen gewünschten Funktionen implementieren...
2. YAGNI ist mit Komponentenbasierte Entwicklung sicherlich vereinbar. Solange die Komponenten nur die Funktionalität enthalten, die auch jetzt benötigt werden ist YAGNI gegeben. Achtet man nicht darauf und versucht die Komponenten für einen späteren, universellen Einsatz fertigzustellen, so wird man nie fertig. Schlussendlich geht man mit den Komponenten life (weil das Geld bzw. die Zeit ausgeht) nur enthalten sie jetzt leider einige nötige Funktionalitäten nicht, weil man diese zu Gunsten der unnötigen Funktionalitäten runterpriorisiert hat.

Diese beiden Absätze gehören daher gestrichen - sie sind auch nur eine Meinung und nicht belegt.

Im referenzierten Artikel aber steht "Andererseits ist strenges YAGNI auch eine Untugend, weil es ihre Fähigkeit einschränken kann, das System später zu erweitern. Ein Feature mag heute unnötig erscheinen, könnte aber morgen schon das Produkt erheblich aufwerten. Die Vorausplanung dieses Features könnte der beste Zug für das Projekt sein und bessere Ergebnisse produzieren." - das ist mMn falsch, weil YAGNI spricht sich nicht gegen eine Vorausplanung von zukünftig wertvollen Features aus, sondern nur gegen die Umsetzung. Aber auch wenn das falsch ist, es ist nunmal durch eine Quelle belegt - auch wenn diese uralt ist und nur die Meinung eines einzelnen Autors wiedergibt. d.h. diese Quelle kann drinnen bleiben - aber nicht die Interpretation dieser Quelle (d.h. das was dazu jetzt im Artikel steht, steht in der Quelle gar nicht drinnen). --Sebastian.Dietrich ✉ 18:21, 30. Okt. 2020 (CET)

1 und 2 sind logische Schlussfolgerungen aus der Beschreibung. Zu 1: YAGNI verlangt nur das zu implementieren was gefordert ist, was logischerweise nur dann geht wenn bekannt ist was gefordert wird. Das ist z.B. problematisch wenn man bottom-up entwickelt, also die Anforderungen anhand der Möglichkeiten überhaupt erst ermitteln muss. Zu 2: Komponentenbasierte Entwicklung hat einen fundamental gegensätzlichen Ansatz als YAGNI, nämlich lieber mehr als nur das unbedingt notwendige zu implementieren. Es ist daher logisch, dass die beiden Methoden sich ausschließen.

Wenn der Artikel 1 + 1 = 2 beweist, brauch ich für 2 + 2 = 4 keine Quelle. --TwoThe (Diskussion) 12:59, 11. Dez. 2020 (CET)

Wenn 1 und 2 logische Schlussfolgerungen wären (was nicht der Fall ist - s.u.), dann ist das kein Allgemeinwissen und muss in der Wikipedia belegt werden (WP:Belege). Wenn du selbst diese logischen Schlussfolgerungen anstellst, dann gehört das auch nicht in die Wikipedia (siehe WP:TF)

Dass man für 2+2=4 keine Quelle braucht, wenn 1+1=2 bewiesen ist, wäre mir auch neu. So funktioniert weder die Mathematik noch die Wikipedia (auch hier siehe WP:Belege)

1: YAGNI wird üblicherweise in agilen Projekten gemacht. Agile Projekte entwickelt nicht gegen Anforderungen, sondern z.B. gegen Bedürfnisse und Probleme vgl z.B. Impact Mapping) YAGNI verlangt auch nicht "nur das zu implementieren, was gefordert ist", sondern "nur das was absolut nötig ist" - idealerweise gar nichts (weil das Bedürfnis anders befriedigt, bzw. das Problem anders gelöst werden kann)

2: Komponentenbasierte Entwicklung ist nicht "lieber mehr als nur das unbedingt notwendige zu implementieren" - es gibt sicher überladene Komponenten aber üblicherweise wird auch bei Komponenten auf deren Größe geachtet. D.h. in komponentenbasierter Entwicklung wird eher auf YAGNI geachtet als nicht - es ist aber weder ein Prinzip noch ein Antipattern bei komponentenbasierter Entwicklung. --Sebastian.Dietrich  ✉  18:51, 11. Dez. 2020 (CET)