Gibt es einen objektiven Unterschied zwischen einem Merge und einer Neuimplementierung? Bisher bin ich davon ausgegangen das bei weniger als 50 % geänderter Codezeilen ein Merge vorliegt, ab 50 % eine Neuimplementierung (mit Wiederverwendung von altem Code).
Nehmen wir mal an, die Antwort wäre ja oder nein. Wie wird das die zukünftiges Leben verändern? Oliver
Gast
#5057523
42
MaWin schrieb: > 42 Bei weniger als der Hälfte sind es sogar nur maximal 21.
Gast
#5057569
Erwin M. schrieb: > Gibt es einen objektiven Unterschied zwischen einem Merge und > einer > Neuimplementierung? Ja, aber der subjektive überwiegt.
hä? schrieb: > Erwin M. schrieb: >> Gibt es einen objektiven Unterschied zwischen einem Merge und >> einer >> Neuimplementierung? > > Ja, aber der subjektive überwiegt. Schön ausgedrückt. :) In Langfassung: Eine objektive Unterscheidung würde eine offizielle Definition oder zumindest eine allgemein akzeptierte Konvention der Begriffe "Merge" und "Neuimplementierung" voraussetzen. Solange du solche Definitionen/Konventionen nicht vorliegen hast bleibt dir wohl nur eine subjektive Bewertung. Was i.d.R. allerdings auch nicht tragisch ist. Im Zweifelsfall schreibst du deine Bewertungskriterien halt mit dazu. Fertig. Falls das nicht möglich ist dann bewerte halt nach deinem persönlichen Gusto - aber halt unter der Nebenbedingung das du deinen Standpunkt auf Nachfrage hin vertreten (aka begründen) kannst. Das 50%-Kriterium liefert, solange keinerlei andere Anhaltspunkte vorliegen, durchaus mal eine vertretbare Daumenregel. Nichtsdestotrotz würde ich - nicht nur im Zweifelsfall - einen Blick auf den Quellcode werfen und eine wohl subjektive Entscheidung treffen. Welche ich anschließend auch vertreten kann. 50 Prozent hin oder her...
Ein anderer Gesichtspunkt. Wenn man sich als neuer brillianter Mitarbeiter positionieren will, macht man natuerlich eine Neuentwicklung, weil das Bestehende sowieso ueberholt, und den neuen Anforderungen nicht mehr gerecht ist. Egal wovon man eigenlich ausgeht. Wenn man keine Lorbeeren abraeumen will, weil der Chef die Vorversion geschrieben hat oder man auch kein Risiko eingehen will, resp massive Zeitueberschreitungen befuerchtet, macht man ein Merge. Weil eine Neuentwicklung enormen Aufwand bedeutet und sowieso nicht in den Zeitplan passen wuerde. So hat man eine Neuentwicklung aufgeschoben, nicht vermieden. Auch egal was man denn womit mergt. Das Mergen kann dann trotzdem unerwartete Seiteneffekte, sprich Zeitverzoegerungen verursachen.
Erwin M. schrieb: > Bisher bin ich davon ausgegangen das bei weniger als 50 % geänderter > Codezeilen ein Merge vorliegt, ab 50 % eine Neuimplementierung (mit > Wiederverwendung von altem Code). Diese Unterscheidung kann nicht wirklich sinnvoll sein. Im Endeffekt würde dann nämlich im Grenzbereich von einer einzigen Zeile Code mehr oder weniger abhängen, ob nun das eine oder das andere vorliegt.
Gast
#5058535
Wenn man die 20% Kern-Businesslogik neu schreibt, ist das auch anders zu bewerten, als wenn man die 80% langweiligen IO- und Hilfsbibliotheken anfasst.
Irgendwie ist da für mich nicht irgendeine Prozent-Grenze, sondern es sind zwei ganz unterschiedliche Dinge. Bei einem Merge nehme ich zwei unterschiedliche Versionen des Code, die sich gegenüber einer gemeinsamen Basis separat von einander weiterentwickelt haben und führe die zusammen. Also wenn z.B. nach einer 2.0-Release eine 2.1 für Bugfixes und parallel dazu eine 3.0 mit neuen Features entwickelt wird. Irgendwann vor der Release von 3.0 muss man dann die Bugfixes aus 2.1 auch übernehmen, damit da nicht plötzlich wieder die schon eigentlich gefixten Bugs wieder drin sind. Das ist mergen. Es bleibt unabhängig davon die Frage, wieviel Prozent neu sein müssen, damit man von einer Neuimplementation sprechen kann. Das Wort suggeriert mir aber, dass der Code komplett oder zumindest fast komplett neu geschrieben ist und nicht nur zur Hälfte.
Gast
#5058747
Sapperlot W. schrieb: > Ein anderer Gesichtspunkt. Wenn man sich als neuer brillianter > Mitarbeiter positionieren will, macht man natuerlich eine > Neuentwicklung, weil das Bestehende sowieso ueberholt, und den neuen > Anforderungen nicht mehr gerecht ist. Forget it! Als brillianter Mitarbeiter entwickelst Du eine bestehende SW (-Komponente) so weiter, dass sie am Ende nur noch Du selbst verstehst. Natürlich muss sie dann objektiv besser sein, mindestens jedoch subjektiv, aber dann für alle. Du darfst keine gravierenden Fehler machen, bzw. keine, die die anderen bemerken. Also: alles muss subber sein. Am besten kannst Du dann noch auf die "Evolution" von der ursprünglichen SW zu deinem Wunderwerk hinweisen. Dann erst bist Du richtig gut.