moin, jeder hat wohl mal die erfahrung gemacht, mit fremden code arbeiten zu müssen. ich bin gerade in der sehr mistigen situation, eine relativ große software erweitern zu müssen. es ist einfach nur eine qual, codedateien mit 1600 zeilen, keine doku, verwirrende variablennamen (Dataaquisition.Dataacquisiotn oder CorrectData und CorrectedData) mit visual studio arbeite ich hauptsächlich mit "goto definition" und "alle verweise suchen" was sind eure erfahrungen und methoden um damit klar zu kommen?
Frank Meier schrieb: > was sind eure erfahrungen und methoden um damit klar zu kommen? Neu schreiben und von Anfang an richtig machen. Alles andere gibt eine ewige Baustelle, irgendwann kommt auch jemand, der das mal weiterbearbeiten soll.
Joachim Drechsel schrieb: > Neu schreiben und von Anfang an richtig machen. Wenn es noch klare Anforsdrungen gibt, was die SW wie machen soll...
Joachim Drechsel schrieb: > Frank Meier schrieb: >> was sind eure erfahrungen und methoden um damit klar zu kommen? > > Neu schreiben und von Anfang an richtig machen. Oder zumindest ein paar Stunden investieren, um wenigstens ein paar grundlegende Dinge zu korrigieren: Variablennamen gegen Verwechslungsgefahr umbenennen. Funktionen auf sinnvolle Funktionsnamen trimmen. Benamungsschemata einziehen. Generelle Codestruktur (Einrückungen etc) überarbeiten. Das alleine bringt schon recht viel. Wenn sich der Code dahingehend wandelt, dass er selber 'eine Geschichte' erzählt, dann bist du am rechten Weg. Was nix bringt: Einzelkommentare neben den Statements. Wenn du versucht bist i++; // i um 1 erhöhen zu kommentieren, dann kannst du dir das auch sparen. Die Frage ist, was ist denn i an dieser Codestelle? Wenn man dem i einen anderen Namen geben würde, würde dann der Code schon etwas verständlicher? nrClients++; Ah, schon viel besser. Da gibt es also Clients. Und jetzt gibt es eben einen mehr. Was hingegen was bringt: Blockkommentare. D.h. vor Codesequenzen eine Zusammenfassung, was im nächsten Abschnitt passiert und wenn das algorithmisch nicht leicht zu durchschauen ist, dann auch noch eine Beschreibung davon. Auch wichtig: erst mal eine Testumgebung aufsetzen, mit der du deine Änderungen einzeln testen kannst, ob du nicht irgendwo beim Editieren einen Fehler eingebaut hast. Man unterschätzt das. Aber das ist mir mehr als einmal passiert, dass ich entusiastisch Code-'Verbesserungen' gemacht habe nur um dann festzustellen: nichts geht mehr. Dann ist es gut, wenn man in kleinen Schritten gearbeitet hat und zwischendurch immer sichergestellt hat, dass man keine Fehler eingebaut hat, die vorher nicht da waren. Wenn ich fremde Libraries übernommen und überarbeitet habe, dann hat die Einführung von konsistenten Benamungsschemata oft schon sehr viel geholfen.
Sehr hilfreich dabei natürlich eine IDE, welche gute Funktionen zum Code-Refactoring bietet, also man konsistent über den ganzen Quelltext hinweg Variablen und Funktionen umbenennen kann, Funktionen extrahieren und dergleichen....
Da zahlt sich dann der Vorteil "großer" IDEs aus. - Einmal den Formatter drüberlaufen lassen - Automatisches "Refactoring". Also Umbenennung von Funktionen/Variablen entsprechend ihres Gültigkeitsbereiches. Aber fehlende Struktur kann man damit nicht erzeugen. PS: Ich bin froh, dass ich bis jetzt noch nicht an Altem Code herumfummeln musste. Bin auf der Arbeit nur einer der wenigen die Programmieren und der Einzige, der mit Mikrocontrollern herummacht. Viel Verantwortung aber auch viel Freiraum.
Hi Als Ergänzung: Für Kommandozeilennutzer auch ganz nett: http://betterthangrep.com/ Dann hilft es auch die kleinen Änderungen auch immer schön ins VCS einzuchecken. Und sei es in ein lokales GIT-Repo. Dann kann man Änderungen viel besser zurückverfolgen. Aber alles in allem wollte ich das auch nicht machen. Mir reicht da das Altprojekt das ich hin und wieder "befummeln" darf. -> Von einem Pascal-Experten nach C portiertes ASM Programm :-) Matthias
Hallo, was für ein Umfag hat das Projekt? Anzahl codezeilen? Wie viele Datein? Wenn du ab jetzt der einzigste bist der damit Arbeiten muss, bzw. vom unsprünglichen Frickler nichts mehr gemacht wird, würde ich auch versuchen das ersteinmal neu zu strukurieren. Wenn der alte Mitarbeiter noch da ist würde ich das nicht empfehlen. Der wird dir bei Rückfragen nicht mehr helfen können, oder wollen.
>Neu schreiben und von Anfang an richtig machen. Die alte Software hat (im Gegensatz zu jeder neu geschriebenen) den riesigen Vorteil, dass sie das tut, was sie soll, und alle hässlichen Ausnahmen und Spezialfälle wahrscheinlich behandelt sind. >Was hingegen was bringt: Blockkommentare. D.h. vor Codesequenzen eine >Zusammenfassung, was im nächsten Abschnitt passiert Das kann man im Idealfall konsequent weiterdenken und aus der Zusammenfassung einen Funktionsnamen machen:
1 | errorstring = do.stuff() |
2 | if errorstring: |
3 | # fehler zum debuggen loggen |
4 | f = open('myfile.txt', 'a')
|
5 | f.write(errorstring + '\n') |
6 | f.close() |
7 | do.more_stuff() |
1 | errorstring = do.stuff() |
2 | if errorString: |
3 | log_debug(errorstring) |
4 | do.more_stuff() |
was auch immer hilft ist klassische Musik beim Verbessern zu hören. Bei einem guten Walzer macht sich das Refactoring schon viel einfacher ;) Ansonsten Arbeitsteilung mit Kollegen und alles über ein VCS ordentlich mergen.
Du kannst das ganze auch mal durch Doxygen jagen. Das ergibt auch eine erste Übersicht. Und man kann seine Erkenntnisse gleich dokumentieren.
Was bei Refactoring auch ungemein hilft, sind Unit-Tests. Mir ist durchaus klar, das sowas bei altem Code oftmals ein frommer Wunsch ist. Aber vielleicht gelingt es Dir ja, zumindest für Teile entsprechende Tests zu schreiben. Dadurch kannst Du zumindest zum Teil sicherstellen, dass Deine Änderungen nichts verschlimmbessern. Wichtig ist auch, dass Du immer nur kleine Änderungen vornimmst und diese dann so gründlich wie möglich testest. Und nach Möglichkeit sowas wie SourceSafe oder CVS verwenden, damit Du nich auch noch vor jeder Änderung daran denken mußt, Sicherungen zu machen. Ansonsten schließe ich mich meinen Vorrednern an. Gruß Markus
anfangsposting klingt ein bisschen wie das "gejammere" auf der baustelle, wo jedes Gewerk über das andere schimpft .. oder einfach mal "frust los lassen" (ich mein, was erwartet man sich auf so eine "frage" )? >codedateien >mit 1600 zeilen, finde ich jetzt mal prinzipiell nicht wirkklich dramatisch >visual studio es geht um "C" ? (C++?) DAS würd mich viel mehr stören ;-) nein, scherz beiseite: aber ich vermute mal, wenn man z.B. viel mit untypisierten pointer arbeitet, viele tools an ihre grenzen stoßen werden ?! "neuschreiben" finde ich übrigens einen "kuriosen" vorschlag (ohne zu wissen was überhaupt das ziel des ganzen ist..)
Robert L. schrieb: > "neuschreiben" finde ich übrigens einen "kuriosen" vorschlag (ohne zu > wissen was überhaupt das ziel des ganzen ist..) Nicht kurios. Erfahrung. Ich habe das EINMAL gemacht ...
Joachim Drechsel schrieb: > Robert L. schrieb: >> "neuschreiben" finde ich übrigens einen "kuriosen" vorschlag (ohne zu >> wissen was überhaupt das ziel des ganzen ist..) > > Nicht kurios. Erfahrung. Ich habe das EINMAL gemacht ... ja, nein. Neuschreiben ist meistens der letzte Ausweg, wenn gar nichts mehr anderes geht. Ist natürlich auch immer eine Ermessensfrage: wieviel Zeit steck ich rein? Komme ich im Laufe der Codebearbeitung zum Schluss, dass da einige Teile algorithmisch nicht ganz sauber sind, dann kann man die auch schon mal neu machen, wenn man das Dickicht überhaupt nicht lichten kann. Ob und wo sich diese Dinge auszahlen sieht man leider erst, wenn man den Code erst mal aufarbeitet. Wenn sich dabei allerdings schwere Basisschnitzer zeigen, ist es oft wirklich besser, da neu anzufangen. Es gibt immer einen Punkt, an dem Sanieren nicht mehr lohnt.
Joachim Drechsel schrieb: > Frank Meier schrieb: >> was sind eure erfahrungen und methoden um damit klar zu kommen? > > Neu schreiben und von Anfang an richtig machen. Ist oft leider keine Option. Die Leute, die über das Budget entscheiden (und die in aller Regel keine Ahnung von Softwareentwickkung haben) argumentieren meistens nach dem Motto "wieso neu schreiben, bisher lief's doch auch". Und wenn man kein Budget dafür bewilligt bekommt, hat man eben nur sehr begrente Möglichkeiten den Code zu verbessern - dann geht nur das, was man "halt so zwischendurch" machen kann. Bei mehreren zehntausend / hunderttausend Zeilen Code will ich außerdem gern sehen, wie du den mal eben so neu schreibst... :-) Simon K. schrieb: > PS: Ich bin froh, dass ich bis jetzt noch nicht an Altem Code > herumfummeln musste. Bin auf der Arbeit nur einer der wenigen die > Programmieren und der Einzige, der mit Mikrocontrollern herummacht. Viel > Verantwortung aber auch viel Freiraum. Wie, in deiner Firma wird doch wohl nicht jedes Projekt von Grund auf neu entwickelt? Ist eher untypisch. Viele Kundenaufträge sind ja Folgeaufträge - wenn die Firma ihren Job gut macht. Oder du bist erst seit letztem Monat dabei ;-)
Mark Brandis schrieb: > "wieso neu schreiben, bisher > lief's doch auch". Der BWLer kennt den Begriff "Insolvenz" ;-) Jeder hat seinen Programmierstil. Es ist sehr mühsam, sich da erst einmal reinzufinden (zB sich durch Open Source Software durchzuhangeln). Der TO hat da eine Leiche von 1600 Zeilen, das wäre noch machbar. Ich hatte mal eine Leiche von 1000 Zeilen GWBASIC die der Autor überhaupt nicht mehr im Griff hatte ... War mein Einstieg in C.
_Gast schrieb: > was für ein Umfag hat das Projekt? Anzahl codezeilen? Wie viele Datein? von hier aus schätze ich mal so 4500 zeilen ohne externe projekte. neu anfangen habe ich auch schon vorgeschlagen, aber das lohnt aus 2 gründen nicht: 1) schon angesprochen, die software macht im moment das was sie soll 2) bin ich als hiwi nur 10h/woche dort und es sind mindestens 80-100h arbeit Karl Heinz Buchegger schrieb: > erst mal eine Testumgebung aufsetzen, mit der du deine Änderungen > einzeln testen kannst, ob du nicht irgendwo beim Editieren einen Fehler > eingebaut hast. Markus Volz schrieb: > Und nach Möglichkeit sowas > wie SourceSafe oder CVS verwenden, damit Du nich auch noch vor jeder > Änderung daran denken mußt, Sicherungen zu machen. als etechniker hab ich mir das ganze programmiergedöns selber beigebracht. gerade "höhere" programmiertechniken wie interfaces oder events kannte ich nur von der theorie aber mir war nie klar was man damit eigentlich macht. daher interessiert mich: was ist sourcesafe/cvs? wie setze ich eine testumgebung auf? ich weiss es gibt tests in visual studio, mehr aber auch nicht. könnt ihr mir literatur dazu empfehlen? die meisten c# bücher die es gibt, decken nur das ab was ich eh schon kenne. Robert L. schrieb: > finde ich jetzt mal prinzipiell nicht wirkklich dramatisch geschmackssache. 1600 zeilen in einer datei finde ich persönlich sehr viel. wenn man alles sinnvoll in klassen kapselt (gerade bei c#) kann man jeder klasse eine datei spendieren. dabei sollte die klasse zB auch nie mehr als 250 zeilen haben. beispiel: datei "FileIO.cs" beherbergt klasse "FileIO" die alle funktionen, konstanten etc die mit dateieingabe/ausgabe zu tun haben. ein klick und ich bin da wo ich hinwill. bei 1600 zeilen, in denen nichts mit nichts zu tun hat muss ich rumscrollen und zT von ganz oben nach ganz unten springen.
Frank Meier schrieb: > 1) schon angesprochen, die software macht im moment das was sie soll > 2) bin ich als hiwi nur 10h/woche dort und es sind mindestens 80-100h > arbeit Dann Finger weg von Neuschreiben. Zumindest solange nicht, solange du nicht im Detail jede einzelne bisherige Codezeile beim Vornamen kennst und genau weißt, was wann wo und warum passiert. > daher interessiert mich: was ist sourcesafe/cvs? Eine Codeverwaltung, die darüber Buch führt, welche Änderungen gemacht wurden. Man 'checkt' dabei komplette Änderungssitzungen ein. Damit ist es dir möglich zb die Anweisung zu geben: rekonstruiere mir genau den Code, so wie er letzte Woche Dienstag abends ausgesehen hat. > wie setze ich eine > testumgebung auf? Machs nicht zu komplizert. Für den Anfang genügt es, wenn du ein paar definierte Testfälle hast, bei denen du genau weißt, was rauskommen muss. Und diese Testfälle sollten so ziemlich alles abdecken, was mit der Software möglich ist. Nach jedem Editierdurchgang, lässt du deine Testfälle auf den Code los und siehst nach, ob immer noch die richtigen Ergebnisse rauskommen. Wenn ja: Diese Release in den SourceSafe (oder was du hast) einchecken. Und erst dann kommt die nächste Codeveränderung drann. > geschmackssache. Eben. > 1600 zeilen in einer datei finde ich persönlich sehr > viel. Ja ok. Auf der anderen Seite haben wir hier Klassen, deren Funktionen sprengen locker die 15000 Zeilen Marke pro File. Und davon haben wir so ca 120 bis 150 Files. Und noch ein paar Hundert, die dann wesentlich kleiner sind. Aber ich geb dir schon recht: Die Monster müssten neu strukturiert werden. Nur: irgendwer muss das zahlen, wenn 12 Mann sich 3 Monate lang der Codepfelege hingeben. Und da sagen dann die BWL-er: njet. > wenn man alles sinnvoll in klassen kapselt (gerade bei c#) kann > man jeder klasse eine datei spendieren. Das sollte man sowieso machen. > dabei sollte die klasse zB auch > nie mehr als 250 zeilen haben. Ansichtssache. Eine Klasse braucht so viele Zeilen, wie es eben braucht. > dateieingabe/ausgabe zu tun haben. ein klick und ich bin da wo ich > hinwill. bei 1600 zeilen, in denen nichts mit nichts zu tun hat muss ich > rumscrollen und zT von ganz oben nach ganz unten springen. Das macht doch die IDE für dich. Gewöhn dich daran. Du scrollst nur noch in der Umgebung, die du brauchst. Den Rest macht die IDE. Du willst zu der Funktion? Entweder Doppelklick auf die verwendende Stelle oder aus einer Combobox ausgewählt oder mittels Find rausgesucht. Rumscrollen bis man das Benötigte gefunden hat, dauert viel zu lange.
>von hier aus schätze ich mal so 4500 zeilen ohne externe projekte.
ok, so ein mini-projekt könnte man schon mal neu schreiben..
Mit Verlaub, aber offensichtlich bist du Anfaenger. Und gerade Anfaenger meinen sehr oft, wenn sie fremden Code sehen, dass das Alles schlecht waere und unbedingt neu geschrieben werden muesste. Was dabei rauskommt, falls was dabei rauskommt, ist meist noch schlechter als das, was vorher da war. Wer Erfahrung hat weiss, dass man nur neu schreiben kann, was man verstanden hat. Und was man verstanden hat, kann man auch aufraeumen und umbauen und braucht es nicht neu zu schreiben.
Marwin schrieb: > Mit Verlaub, aber offensichtlich bist du Anfaenger. Und gerade Anfaenger > meinen sehr oft, wenn sie fremden Code sehen, dass das Alles schlecht > waere und unbedingt neu geschrieben werden muesste. Was dabei rauskommt, > falls was dabei rauskommt, ist meist noch schlechter als das, was vorher > da war. Wer Erfahrung hat weiss, dass man nur neu schreiben kann, was > man verstanden hat. Und was man verstanden hat, kann man auch aufraeumen > und umbauen und braucht es nicht neu zu schreiben. Hi Marwin, unterschätze das mal nicht. Du brauchst sehr viel Erfahrung und Gefühl umm nachzuvollziehen wie jemand ein Thema angegangen ist. So mal frisch und frei loslegen ist da nicht. Es gibt immer viele Wege zum Ziel.
Mark Brandis schrieb: > Simon K. schrieb: >> PS: Ich bin froh, dass ich bis jetzt noch nicht an Altem Code >> herumfummeln musste. Bin auf der Arbeit nur einer der wenigen die >> Programmieren und der Einzige, der mit Mikrocontrollern herummacht. Viel >> Verantwortung aber auch viel Freiraum. > > Wie, in deiner Firma wird doch wohl nicht jedes Projekt von Grund auf > neu entwickelt? Ist eher untypisch. Viele Kundenaufträge sind ja > Folgeaufträge - wenn die Firma ihren Job gut macht. > Oder du bist erst seit letztem Monat dabei ;-) Wieso nicht? Es sind oft kleinere Projekte und Applikationen, die es in der Form noch nicht gibt. Alles im Bereich TETRA-Funk, wo (zumindest zur Zeit) alles geheimgehalten wird ;-) Angefangen habe ich dort vor längerer Zeit, für meine Bachelorarbeit war ich dort bereits angestellt.
Joachim Drechsel schrieb: > Der TO hat da eine Leiche von 1600 Zeilen, das wäre noch machbar. Nein, er sagt er hat einzelne Dateien mit bis zu 1600 Zeilen Code drin. Und das ist eindeutig zu viel. Da ist Modularität wohl ein Fremdwort und man sucht sich bei einer bestimmten Funktionalitäten einen Wolf.
Simon K. schrieb: > Wieso nicht? Es sind oft kleinere Projekte und Applikationen, die es in > der Form noch nicht gibt. Alles im Bereich TETRA-Funk, wo (zumindest zur > Zeit) alles geheimgehalten wird ;-) Okay, aber das ist dann auch kein typischer Softwareentwickler-Job. Vielen ist "Working (effectively) with Legacy Code" ein Begriff. Und ein Kreuz ;-) Simon K. schrieb: > Nein, er sagt er hat einzelne Dateien mit bis zu 1600 Zeilen Code drin. > Und das ist eindeutig zu viel. > > Da ist Modularität wohl ein Fremdwort und man sucht sich bei einer > bestimmten Funktionalitäten einen Wolf. Modularität bedeutet nicht, dass jede kleine Popelfunktion mit drei Zeilen Code in eine eigene Datei geschrieben wird. Funktionen, die logisch eine Einheit bilden, lässt man auch auf Dateiebene zusammen. Was mit ziemlicher Sicherheit nicht sein muss, ist eine einzelne Funktion, die sich über 1600 Zeilen erstreckt. Das lässt sich in aller Regel sehr wohl noch viel besser unterteilen.
Mark Brandis schrieb: > Was mit ziemlicher Sicherheit nicht sein muss, ist eine einzelne > Funktion, die sich über 1600 Zeilen erstreckt. naja, im endeffekt schon ^^
Frank Meier schrieb: > ich bin gerade in der sehr mistigen situation, eine relativ große > software erweitern zu müssen. es ist einfach nur eine qual, codedateien > mit 1600 zeilen, keine doku, verwirrende variablennamen... > > was sind eure erfahrungen und methoden um damit klar zu kommen? Generell sind zwei Dinge zu unterscheiden: (1) Man ist neu in dem Projekt/der Software und weiß (noch) nicht, wie diese arbeitet und konzipiert ist. Jeder Entwickler hat andere Vorlieben beim Benennen von Variablen, Coding-Rules, Kommentar-Stil, Unterteilung in Module und Funktionen. Ist man neu, sollte man die anfängliche Unsicherheit und die zwangläufig und natürlicherweise vorhandenen Wissenslücken nicht verwechseln mit (2) Der Code ist tatsächlich grottig und wiederspricht allen Regeln der Kunst. > jeder hat wohl mal die erfahrung gemacht, mit fremden code arbeiten zu > müssen. Dazu ist Einarbeitung notwendig. Ein reflexartiges NIH (Not Invented Here: Nicht hier erfunden und damit gleich Schrott) ist ebensowenig zielführend wie blind den Code den eigenen Vorstellungen von guten Coding-Rules anzupassen. All des ersetzt nämlich nicht die Einarbeitung in die Materie. Ein Neuschreiben erfordert zwangsläufig eine Einarbeitung, quasi ein Learning-by-Doing. Die Einarbeitung in Vorhandenes ist hingegen oft trockener und erscheint mühsamer, weil man selbst keinen Gestaltungsspielraum hat. Zudem muss die Abneigung gegen den NIH-Code überwunden werden. Refactoring und Neuformatierung nach Coding-Rules erzeugt zunächst ein beträchtliches Rauschen auf dem RCS; arbeitet man mit mehreren an dem Projekt und provoziert durch solch großflächige Änderungen merge-Konflikte bei Kollegen, ist das nicht gut. Zumal sich an der Funktionalität nichts ändert. Die Rants zum Thema Coding-Rules und Variablen-Nomenklatur sind Legion. Wenn jeder Entwickler bei Übernahme des Projekts glaubt, ein Komplett-Lifting durchführen zu müssen, ist etwas schief gelaufen. Im Vorfeld ist auf jeden Fall abzuklären, ob es Coding-Rules etc. gibt. Gibt es nichts dergleichen, sollten Coding-Rules festgelegt werden um ähnliche Reibungsverluste zukünftig zu verhindern und ein besseres Zusammenarbeiten zu ermöglichen. Steigt man neu in ein Projekt ein, richtet man sich nach den dort üblichen Coding-Rules. Das braucht etwas Zeit, aber man stirbt nicht daran. Bisher hab ich mich erst 1x dazu entschieden, einen Code neu zu schreiben. Leicht gefallen ist mir die Entscheidung nicht. Inzwischen bin ich seit über 1 Jahr damit befasst. Die Kunden haben mittlerweile eine erste Vorabversion, sind mit Performance und Stabilität zufrieden und es gab erfreulich wenige Fehler — viel weniger, als ich dachte. Bis die Software halbwegs fertig ist, werden noch ca. 6 Monate oder mehr ins Land gehen. Den Aufwand zum Neuschreiben sollte man also nicht unterschätzen. Ebenfalls den Aufwand, wie ein Schießhund über den Code zu wachen und vor Commits von Kollegen zu schützen, für die Kommentare, Coding-Rules und ChangeLogs nichts sind ausser lästiger Zeitverschwendung, und die sich bei all ihrer Fachkompetenz die alte Wurstigkeit einfach nicht abgewöhnen wollen...
Kommt vor allem dann vor, wenn Programmierer eine andere Sprache gewöhnt sind (z.B. Pascal) und dann z.B. in C programmieren müssen. Musste mal Code von der Art warten und erweitern. Habe auch mit dem Gedanken gespielt, das ganze neu zu programmieren. Zum Glück habe ich es nicht getan. Auch wenn der Code Schrott ist, so sind doch alle Spezialfälle abgedeckt gewesen. Keine Ahnung wie lange es gedauert hätte, all das neu zu programmieren. Denn: Es sind ja meist auch keine genauen Anforderungshefte vorhanden, die das ganze so genau im Detail beschreiben wie diese und jene Funktion ausschauen soll. Gewöhn dich möglichst früh daran, mit dem Code anderer umzugehen. Das dieser nicht immer toll ist, gehört dazu. Wer weiß, vielleicht denken andere das gleiche über meinen oder über deinen Code? Jedenfalls sollte man, wenn man ein Programm erweitert, möglichst nichts von den bestehenden Dingen ändern, wenn sie funktionieren. Damit habe ich schon öfters schlechte Erfahrungen gemacht. Eben weil man dann doch irgendeinen Spezialfall vergisst. Dort, wo du den Code erweiterst, kannst du ja sauberen Code schreiben. Ich empfehle dir ein Versionssystem. Ziemlich simpel zu benutzen ist GIT. Das arbeitet direkt in deinem Projektordner, also auf deiner Festplatte, du kannst also lokal eine Versionsverwaltung machen. Damit hast du dann einen schönen Überblick über deine Änderungen und kannst nichts kaputt machen. P.S.: 1600 Zeilen pro Datei ist nicht wirklich schlimm.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.