Forum: PC-Programmierung Fremder, schlecht strukturierter Code


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Frank M. (aktenasche)


Lesenswert?

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?

von Joachim D. (Firma: JDCC) (scheppertreiber)


Lesenswert?

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.

von Klaus W. (mfgkw)


Lesenswert?

Joachim Drechsel schrieb:
> Neu schreiben und von Anfang an richtig machen.

Wenn es noch klare Anforsdrungen gibt, was die SW wie machen soll...

von Karl H. (kbuchegg) (Moderator)


Lesenswert?

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.

von Dr. G. Reed (Gast)


Lesenswert?

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

von Simon K. (simon) Benutzerseite


Lesenswert?

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.

von Μαtthias W. (matthias) Benutzerseite


Lesenswert?

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

von _Gast (Gast)


Lesenswert?

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.

von Tom K. (ez81)


Lesenswert?

>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()

von Kugelfisch (Gast)


Lesenswert?

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.

von Tommi (Gast)


Lesenswert?

Es hilft schon ungemein die Groß- und Kleinschreibung zu beachten!

von DirkB (Gast)


Lesenswert?

Du kannst das ganze auch mal durch Doxygen jagen.
Das ergibt auch eine erste Übersicht.
Und man kann seine Erkenntnisse gleich dokumentieren.

von Markus V. (valvestino)


Lesenswert?

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

von Robert L. (lrlr)


Lesenswert?

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

von Joachim D. (Firma: JDCC) (scheppertreiber)


Lesenswert?

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

von Karl H. (kbuchegg) (Moderator)


Lesenswert?

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.

von Mark B. (markbrandis)


Lesenswert?

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 ;-)

von Joachim D. (Firma: JDCC) (scheppertreiber)


Lesenswert?

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.

von Frank M. (aktenasche)


Lesenswert?

_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.

von Karl H. (kbuchegg) (Moderator)


Lesenswert?

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 Robert L. (lrlr)


Lesenswert?

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

von Marwin (Gast)


Lesenswert?

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.

von Joachim D. (Firma: JDCC) (scheppertreiber)


Lesenswert?

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.

von Simon K. (simon) Benutzerseite


Lesenswert?

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.

von Simon K. (simon) Benutzerseite


Lesenswert?

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.

von Mark B. (markbrandis)


Lesenswert?

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.

von Frank M. (aktenasche)


Lesenswert?

Mark Brandis schrieb:
> Was mit ziemlicher Sicherheit nicht sein muss, ist eine einzelne
> Funktion, die sich über 1600 Zeilen erstreckt.

naja, im endeffekt schon ^^

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

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

von progger (Gast)


Lesenswert?

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.