Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Do Mär 28, 2024 11:17

Foren-Übersicht » Programmierung » Allgemein
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 13 Beiträge ] 
Autor Nachricht
 Betreff des Beitrags: Einarbeiten in Messiprojekte
BeitragVerfasst: Mi Jun 17, 2015 09:15 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Jan 04, 2008 21:29
Beiträge: 419
Wohnort: Lübeck
Hallo Leute,

ich habe momentan ein massives Problem. Ich habe hier einen Quellcode von einem Programm liegen, für dass ich eine "Erweiterung" entwickeln soll. Eigentlich ist es keine tatsächliche Erweiterung, wie man sich das in einer üblichen Pluginschnittstelle vorstellt, sondern eher so, dass ich einfach in den bestehenden Code etwas integrieren soll. Das schlimme an der Sache ist, dass der Code über Jahre immer wieder weiter entwickelt wurde und es weder eine Dokumentation, noch sinnvolle Kommentare gibt. An Diagramme etc. ist gar nicht zu denken.

Das Programm ist eine Software um das Produktportfolio einer Firma abzubilden und in 3D zu konfigurieren. Es geht hierbei um Krankenhausequipment (Deckenversorgungseinheiten und OP-Leuchten). Die Konfiguration ist sehr sehr aufwendig, weil teilweise Bauteil für Bauteil ein Gerät zusammengestellt werden kann und es sehr viele Einschränkungen gibt. Außerdem bietet die Anwendung dem Nutzer direkt Angebote aus der Konfiguration zu generieren und Bestellungen einzuleiten, wobei dies lediglich auf Dokumentenbasis passiert. Kommunikation mit einem SAP-System oÄ findet nicht statt.

Der gesamte Sourcecode besteht weitestgehend aus Formularen. Eine Klassenstruktur ist nicht zu erkennen. Es gibt zwar Klassen, aber diese verwenden nie Interfaces und sind auch nicht von irgendwas abgeleitet. Meist handelt es sich um Klassen, die lediglich eine Methode ODER ein paar Variablen beherbergen.

Die Logik befindet sich zum Großteil in einer von extern eingekauften GrafikEngine, die seit Jahren nicht mehr weiter entwickelt wird (DXStudio). Das Debugging ist an dieser Stelle also sehr aufwendig, so dass man nicht mal einfach durch den Code steppen kann, um zu sehen wann was wo und wie passiert. Logfiles werden auch keine geschrieben.

Da es nur die Formulare und die Engine gibt, hat eine Aufteilung in Schichten hier also gar nicht stattgefunden und ist aufgrund der Größe des Projekts wohl auch nicht mehr möglich.

Meine Frage ist: Wie würdet ihr versuchen diesen Sourcecode zu durchleuchten? Die eigentlichen Entwickler wissen größtenteils selbst nicht mehr was sie da gemacht haben...

_________________
Klar Soweit?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Einarbeiten in Messiprojekte
BeitragVerfasst: Mi Jun 17, 2015 16:55 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++
Da ich mit sowas @work täglich zu tun hab (teilweise Quellcode der 20 Jahre alt ist), kann ich dazu einiges sagen, bzw. kann dir "Working Effectively with Legacy Code" von Robert C. Martin empfehlen.

Bei solchen Legacy-Systemen hat man grade am Anfang immer das Problem dass jede kleine Änderung an ganz vielen Stellen Auswirkungen haben kein, weil, wie du sagst, kaum Abstraktionsschichten vorhanden sind, und auch die Abhängigkeiten sind dann i.d.R. ganz wüst (Thema "Dependency Hell").

Ein solches System umbauen ist schwierig, da ist ein Neubau i.d.R. besser. Dafür hat man aber normalerweise keine Zeit.

Im ersten Schritt wird man also nicht umherkommen die Stellen an denen man Änderungen machen muss zu analysieren, und zu sehen wo genau diese Änderungen Auswirkungen hätte. Also Code raustrennen, refactoren, statische Codeanalysen laufen lassen, sauber dokumentieren und dann dafür Unit-Tests schreiben.

Für einen ersten Überblick kann man ggf. auch mit einem Tool wie Doxygen eine komplette Quellcodedoku inkls. Abhängigkeisgraphen erzeugen lassen. Grade Letzteres hat mir gezeigt wo die schlimmsten Abhängigkeiten liegen und was man mit einer Änderungen an welcher Stelle potentiell kaputt machen könnte.

Grade am Anfang, wenn man sich in den Code rein denken muss, ist das schwierig, aber irgendwo muss man anfangen. Wenn ich @work nicht unter Zeitdruck bin (leider eher selten), dann schaue ich mir bei jeder noch so kleinen Änderung am Legacycode an wie man den sauber raustrennen und abstrahieren kann, so dass er auch testbar ist. Das ist zwar Zeitaufwendig, lohnt sich aber spätestens dann wenn man an dem Code wieder was ändern muss.

Wenn die alten Entwickler noch da sind, bzw. Personen die wissen wie sich das System verhalten sollte, hat das natürlich Vorteile. Dann kann man diese die Funktionstests nach einer Änderung machen lassen, und mit ihnen dann auch u.U. aushandeln welche Unittests benötigt werden.

Und dass dann halt alles in kleinen Schritten mit einem CVS (z.B. GIT) in dem man dann sauber Branches für die Änderungen anlegt.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Einarbeiten in Messiprojekte
BeitragVerfasst: Mi Jun 17, 2015 17:00 
Offline
Ernährungsberater
Benutzeravatar

Registriert: Sa Jan 01, 2005 17:11
Beiträge: 2067
Programmiersprache: C++
Sascha Willems hat geschrieben:
...dann schaue ich mir bei jeder noch so kleinen Änderung am Legacycode an wie man den sauber raustrennen und abstrahieren kann, so dass er auch testbar ist.

Wie Sascha schon geschrieben hat: "Working Effectively with Legacy Code"
Und versuchen den Code unter Tests zu bekommen. Natürlich ist das meistens kaum möglich, aber du merkst beim Erstellen der Tests was es für Abhängigkeiten gibt. Und wenn am Ende sogar erfolgreiche Tests heraus kommen, dann gibt es dir Sicherheit für deine Änderungen.

_________________
Steppity,steppity,step,step,step! :twisted:
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ❄ ❆ ❄ ❄


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Einarbeiten in Messiprojekte
BeitragVerfasst: Mi Jun 17, 2015 19:02 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Nov 08, 2010 18:41
Beiträge: 769
Programmiersprache: Gestern
Bei der beschriebenen Größe würde ich mir etwas fixxes in den Teil Suchen den du erweitern musst. Also eine spezielle Funktion, Fehlermeldung oder halt Formular. Und von da aus arbeite ich mich immer
via Find-All-References hoch. Meine Erweiterungen / Fixes packe ich dann immer Extern in eigene Klassen oder so. Wenn es schließlich schon scheiße ist kann man auch ruhig richtige Scheiße reinhacken :)
(natürlich so das daraus nicht wieder Folgearbeit entsteht, denn du willst ja Kohle machen)

Außerdem weiß so jeder das dort mal was gefixxt / geändert wurde ohne erst nach Comments zu suchen.

Verstehen musst du es nur wenn es gerade wie in einen anderen Projekt von mir ist. Dort hat der Kunde versucht selbst zu entwickeln und ein paar 1000 Klassen mit jeden erdenklichen Feature der Sprache. So nach dem
Motto "hey mein Tutorial beleuchtet jetzt dieses Feature". Der entsprechende Mitarbeiter des Kunden wurde dann nach ein paar Jahren "gegangen" und wir sollen das jetzt aufräumen :)

_________________
Meine Homepage


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Einarbeiten in Messiprojekte
BeitragVerfasst: Mi Jun 17, 2015 20:12 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 27, 2005 12:44
Beiträge: 393
Wohnort: Berlin
Programmiersprache: Java, C++, Groovy
Hallo,

du schreibst, dass keine Logfiles geschrieben werden. Genau das könntest du ändern, indem du in verschiedenen Methoden Logpunkte einfügst, mit denen du den Programmablauf wenigstens halbwegs nachvollziehen kannst. Man könnte z.B. am Anfang einer jeden Methode "Aufruf Klasse#Methode" (und zum Schluß "Ende Klasse#Methode") ausschreiben, das ist zwar etwas aufwendig, wenn du aber nicht debuggen kannst schonmal eine gute Hilfe.

Viele Grüße
dj3hut1

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Einarbeiten in Messiprojekte
BeitragVerfasst: Do Jun 18, 2015 08:35 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Sascha Willems hat geschrieben:
Im ersten Schritt wird man also nicht umherkommen die Stellen an denen man Änderungen machen muss zu analysieren, und zu sehen wo genau diese Änderungen Auswirkungen hätte. Also Code raustrennen, refactoren, statische Codeanalysen laufen lassen, sauber dokumentieren[…]

Für einen ersten Überblick kann man ggf. auch mit einem Tool wie Doxygen eine komplette Quellcodedoku inkls. Abhängigkeisgraphen erzeugen lassen. Grade Letzteres hat mir gezeigt wo die schlimmsten Abhängigkeiten liegen und was man mit einer Änderungen an welcher Stelle potentiell kaputt machen könnte.
Dass Doxygen da hilfreich ist glaube ich gern. Man muss darauf achten, die Callgraphen und alles was man bekommen kann anzuschalten, das ist per default aus. Dann sieht man zumindest, von wo nach wo irgendwas passiert. Wenn du in einer dynamischen Sprache unterwegs bist (Python, Javascript, …) haste da natürlich verloren.


Sascha Willems hat geschrieben:
und dann dafür Unit-Tests schreiben.
Hell yeah. Als jemand, der eine Weile ein Projekt Test-Driven entwickelt, Unittests mit einer ordentlichen Coverage sind göttlich beim Refactorn. Und beim einbauen von Features.


Sascha Willems hat geschrieben:
Wenn die alten Entwickler noch da sind, bzw. Personen die wissen wie sich das System verhalten sollte, hat das natürlich Vorteile.
Nur, wenn man einen Boxhandschuh hat ;)

Sascha Willems hat geschrieben:
Und dass dann halt alles in kleinen Schritten mit einem CVS (z.B. GIT) in dem man dann sauber Branches für die Änderungen anlegt.
Du meinst VCS. CVS will man niemandem empfehlen, schon garnicht in so einer Situation. Am besten ein DVCS wie Git, falls auf der Arbeit selber kein (D)VCS im Einsatz ist, da man mit git ja auch problemlos ohne Server arbeiten kann. Einfach git init auf das Verzeichnis drauf hauen und das Git Book lesen.

viele Grüße,
Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Einarbeiten in Messiprojekte
BeitragVerfasst: Do Jun 18, 2015 14:33 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Jan 04, 2008 21:29
Beiträge: 419
Wohnort: Lübeck
Vielen Dank für die Tipps!

Das Buch ist bestellt und auch die restlichen Tipps werde ich mal ausprobieren. Bei weiteren Schwierigkeiten komm ich nochmal zurück.

Gruß!

_________________
Klar Soweit?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Einarbeiten in Messiprojekte
BeitragVerfasst: Mi Aug 05, 2015 06:56 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7804
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Alles von Sascha bis auf:
Sascha Willems hat geschrieben:
"Working Effectively with Legacy Code" von Robert C. Martin empfehlen.

Das Buch ist nämlich von Michael Feathers. ;)

Wenn du ordentlich arbeiten will, und ich rede da von handwerklich sauber ala "Clean Code" (daswar von Rober C Martin aka Onkle Bob), dann muss du dir mal genau ein bild machen wie das system momentan tickt, die zu änderden Teile testabdecken (das klingt schwierig bei dir, da Businesslogik im Renderer steckt...) und dann refactoren.

Bei Spagetticode mach ich gerne einen Code walkthrough von einem definierten Eingangspunkt aus. Ich mal mir ein Communication Diagram (sowas hier, oberer Teil: Bild, nur das die Boxen bei mir eher wie die Klassen aus nem UML Class Diagramm aussehen.

Was mir diese darstellung gibt ist ein Durchstich durchs system, ein Gefühl wo was gemacht wird und wo welche entscheidungen getroffen werden.

Zum Refactoring gibts hier noch ein Video, was wir aktuell allen Entwicklern bei uns regelmäßig empfehlen (wir arbeiten mit einem Legacy Java System was seit ca. 15 Jahren entwickelt wird.):
http://www.youtube.com/watch?v=_NnElPO5BU0

Dein Hauptproblem scheint der Renderer zu sein, der 1. Veraltet und 2. verwurstet ist. Wenn du es schaffst den zu separieren könntest du einen modernen Renderer davor schalten. Ich kenn mich in dem Umfeldnicht aus, aber eventuell kannst du deine Bauteile in eine Szene importieren und dann durch Blender rendern lassen. Wichtig ist, dass der Code der entscheidet was zu rendern ist und der Code der weiß wie man es rendert getrennt wird.

_________________
Blog: kevin-fleischer.de und fbaingermany.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Einarbeiten in Messiprojekte
BeitragVerfasst: Mi Aug 05, 2015 12:50 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Zum testen von renderer und UI hab ich Praxiserfahrung und das ist eigentlich nur wenig komplizierter als ein normaler test.
Man benötigt für jeden Test ein Screenshort vom wie es aussehen sollte und vergleicht dann pixelweise die Bilder.
Das Bild haben wir als PNG abgelegt, weil wir es möglichst klein und unverfälscht haben wollten.
Am Ende des Test haben wir dann den aktuellen Frontbuffer mit der PNG verglichen und ein Schwellwert von 0-10% als Spielraum gelassen.
Der Spielraum ist eigentlich nur für Kompressionsartefakte oder Farbraumänderung wichtig gewesen, da aber unser PNG das nicht mehr hatte haben wir in der Regel 5% für Texturfilterprobleme gesetzt.
Das geht aber nur wenn das Programm deterministisch ist, sonnst hat man recht schnell Probleme.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Einarbeiten in Messiprojekte
BeitragVerfasst: Sa Aug 08, 2015 15:14 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7804
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
@TAK: Dasist eine gute Idee.

Kombinieren würde ich das mit einer Aussage von Onkle Bob: "Testet eure Systeme NICHT durch eure GUI! Separiert beide voneinander. Beschickt die BusinessLogik direkt durch die API. Beschickt eure GUI durch Dummi-Daten."

Wenn man das so macht, kann man die verschiedenen Ausgabeeffekte leichter Provozieren, als wenn man das durch den eigentlichen Code bewerkstelligen muss.

_________________
Blog: kevin-fleischer.de und fbaingermany.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Einarbeiten in Messiprojekte
BeitragVerfasst: Di Nov 17, 2015 17:38 
Offline
DGL Member

Registriert: Mi Okt 16, 2002 15:06
Beiträge: 1012
TAK2004 hat geschrieben:
Zum testen von renderer und UI hab ich Praxiserfahrung und das ist eigentlich nur wenig komplizierter als ein normaler test.
Man benötigt für jeden Test ein Screenshort vom wie es aussehen sollte und vergleicht dann pixelweise die Bilder.
Das Bild haben wir als PNG abgelegt, weil wir es möglichst klein und unverfälscht haben wollten.
Am Ende des Test haben wir dann den aktuellen Frontbuffer mit der PNG verglichen und ein Schwellwert von 0-10% als Spielraum gelassen.
Der Spielraum ist eigentlich nur für Kompressionsartefakte oder Farbraumänderung wichtig gewesen, da aber unser PNG das nicht mehr hatte haben wir in der Regel 5% für Texturfilterprobleme gesetzt.
Das geht aber nur wenn das Programm deterministisch ist, sonnst hat man recht schnell Probleme.


Auf so eine Idee hätte ich mal früher kommen sollen... weil ich habe für für meine Firma eine aufwendige eigene Charting-Bibliothek in Javascript mit HTML5/Canvas geschrieben und nur reine Funktionstest gemacht, z.b. für die Label-Kollisionserkennung - visuelle Tests gibts zwar auch, aber die müssen selbst von "Hand" gestartet und überprüft werden. Mittlerweile ist das ganze so komplex geworden, das es einfach zuviele arten von Darstellungen gibt, welche dazu noch beliebig konfiguriert werden können...


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Einarbeiten in Messiprojekte
BeitragVerfasst: Di Dez 22, 2015 20:09 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 27, 2005 12:44
Beiträge: 393
Wohnort: Berlin
Programmiersprache: Java, C++, Groovy
In der Firma nutze ich seit neuestem SonarQube für die Codeanalyse. Damit lässt sich zumindest ermitteln, wo besonders komplexer Code liegt und man erhält eine gute Übersicht über die Testabdeckung (vorausgesetzt es existieren Tests :twisted:).

Viele Grüße
dj3hut1

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags: Re: Einarbeiten in Messiprojekte
BeitragVerfasst: Mi Feb 17, 2016 11:47 
Offline
DGL Member
Benutzeravatar

Registriert: Do Jan 28, 2016 09:42
Beiträge: 7
Programmiersprache: Delphi, C++
dj3hut1 hat geschrieben:
In der Firma nutze ich seit neuestem SonarQube für die Codeanalyse. Damit lässt sich zumindest ermitteln, wo besonders komplexer Code liegt und man erhält eine gute Übersicht über die Testabdeckung (vorausgesetzt es existieren Tests :twisted:).

Viele Grüße
dj3hut1


SonarQube und ähnliche kann ich bei sowas auch empfehlen. Mein Bruder hatte mal ein ähnliches Projekt am laufen - da war erstmal Durchblicken angesagt.

_________________
Give a man a program, frustrate him for a day.
Teach a man to program, frustrate him for a lifetime. :twisted:
- Waseem Latif


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 13 Beiträge ] 
Foren-Übersicht » Programmierung » Allgemein


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 17 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.436s | 17 Queries | GZIP : On ]