Zwei Fragen: Aufteilung eines Programms und VB 2017

  • VB.NET
  • .NET (FX) 4.0

Es gibt 25 Antworten in diesem Thema. Der letzte Beitrag () ist von RodFromGermany.

    Zwei Fragen: Aufteilung eines Programms und VB 2017

    Hallo und guten Morgen,

    ich hab an euch zwei fragen... vielleicht mögt Ihr mir eure Meinung dazu geben, wäre nett! Vorab Danke !...

    1)
    Ich arbeite für uns (Firma) an einem Programm zur Kunden und Auftragsverwaltung. Läuft seit einem Jahr, ohne wirkliche Probleme in der Anwendung oder Logistik etc.
    Nun ist das Programm wirklich groß geworden. Beim Laden in VS 2015 hat es direkt nach dem laden schon 1,5 GB. Arbeite ich daran (hatte schon mal einen Beitrag geschrieben wg. OutOfMemory etc) geht es schnell an die 2 GB und mehr... danach kein wirklich gute Weiterarbeiten mehr möglich...

    Nun denke ich daran, dass Programm aufzuteilen, Kundenverwaltung, Warenwirtschaft (was sehr groß geworden ist) und Personal.
    Mein Vorhaben wäre, dass ich ein "Zentral"-Programm mache, für die Anmeldung am System und diverse Verwaltungsprogramme.
    Kundenverwaltung, Warenwirtschaft und Personal sind dann "eigenständige Programme"... eine Art Modulbauweise (keine Ahnung wie ich das nennen soll)

    Dazu die Frage:
    a) Findet Ihr diese Idee generell gut oder schlecht?
    b) Bin mir grad recht unschlüssig, wie ich dann aber z. B. My.Settings (wo natürlich einige drinsteht wie z. B. UserId, UserName für Anwendungen, diverses anderes) dann auch Zentral zur Verfügung stellen soll. Aber wie machen das die großen - aller SAP etc. ? .....

    2)
    Was haltet Ihr von Visual Studio 2017? Bin am überlegen ob ich umstellen soll. Arbeit jedoch viel mit Report Designer und Viwer etc. hab gelesen, dass dies nicht mehr Bestandteil von SV 2017 sei. Hab ich das richtig verstanden? Würde es "Besserungen" in VS 2017 geben? ... Wie macht Ihr weiter?

    So genug geschrieben, vllt. habt Ihr ja Lust eure Meinung zu sangen, vielen Dank...
    GRüße
    Michl

    Das Problem hatte ich auch. Das compilieren hat ewig gedauert und der Designer hing permanent. Hab dann nen neuen PC (18 GB. Ram, I7 Prozessor, SSD) bekommen. Nun geht das Arbeiten wieder prima.

    Ein bestehendes System aufzuteilen stelle ich mir schwierig vor, kann man sicher viel kaputt machen.
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen

    @michl75 Solch Programme sind übrigens Dutzendware, da arbeiten allerdings üblicherweise mehrere Leute dran (>10).
    Wie viele sind es bei Dir?
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Ich kenne ein (kleines) ERP System, welches für jedes Modul (Adressen, Artikel, etc.) im Programm eine eigene .exe nutzt. Das Hauptprogramm verwaltet die Module und startet lediglich die .exe. Ob das gut ist, wage ich jedoch zu bezweifeln.
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen

    @michl75 Das ist eher unterkritisch, das bedeutet, dass Ihr beiden da nicht wirklich was bewegen könnt.
    Ich nehme mal an, Ihr oder zumindest einer von Euch beiden ist zu dem Programm gekommen "wie die Jungfrau zum Kind", also: Hier ist das Programm, mach mal...
    OK.
    Ich kenne jetzt die Struktur des Codes nicht, aber meine Herangehensweise wäre folgende:
    • den Code aufräumen (den Quelltext lesbar machen) und kommentieren,
      Dateien heißen genau wie die Klassen, die sie enthalten,
      pro Datei eine Klasse, pro Klasse ggf. mehrere Dateien (Partial Class)
      Toter Code (Klassen, die nicht instanziiert werden) wird ersatzlos gestrichen
      auskommentierter Code ohne Kommentar dazu wird ersatzlos gestrichen
    • den Code strukturieren, programmatische Inhalte in separate Klassen kapseln,
      die Klassen auf Unterordner verteilen,
      diese Unterordner generieren Namespaces (fällt in C# automatisch bei drin neu erstellten Klassen an)
    • Einen Plan machen, was an Neuem geschöpft werden soll
      Arbeitspakete definieren
      diesen Arbeitspaketen Prioritäten zuweisen, nicht alle Pakete können Prio 1 haben!!!
    • einen Zeitplan aufstellen und los.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    michl75 schrieb:

    Ich arbeite für uns (Firma) an einem Programm zur Kunden und Auftragsverwaltung. Läuft seit einem Jahr, ohne wirkliche Probleme in der Anwendung oder Logistik etc.
    Nun ist das Programm wirklich groß geworden. Beim Laden in VS 2015 hat es direkt nach dem laden schon 1,5 GB.
    Naja, ich denk, da muss man als erstes sorgfältig untersuchen, worans liegt - die 3. der Rules of Optimization.
    Ladet ihr da quadratmeterweise Bitmaps in den Speicher, verwendet ihr generierte Datatasetse mit millionen Zeilen code, hängts am ReportViewer-Brimborium?

    Besonderes Augenmerk ist auf MemoryLeaks zu haben - das sind echte Programmier-Fehler, und nach Korrektur ist das Problem weg - ohne dass man das ganze Anwendungs-System neu schreibt.

    Danke für eure Antworten...

    Ja... tatsächlich, "wir" sind dazugekommen wir Jungfrau zum Kind.

    @RodFromGermany: Finde ich klasse! ...denke aufräumen und mal kommentieren was/wo/wie ist schon mal glaub ich der erste Schritt. Haben ohne hin schon vieles "entfernt"/umgeschrieben und naja sagen wir mal "vereinfacht"... Danke für diese Erklärung, wir werden uns daran halten und mal versuchen umzusetzen.

    @ErfinderDesRades: Ja, leider sind noch viele Bitmaps für Icons enthalten! Haben bereits fast die hälfte entfernt ...... und anschließend den Code korrigiert mit einheitlichen Icons. Es sind aber immer noch fast 400 Icon (auch wenn kleine) enthalten. Wir wollen es auf max. 50 eingrenzen. Sind 50 immer noch zu viel ?
    Und nochmal ja... Es sind große Datasets, mit vielen Abfragen und im "DataSet-Designer" wenn man guggt sind das beim größten 97807 Code-Zeilen.

    Glaube auch da müssten wir mal aufräumen.

    Jou.
    @michl75 Und lass mal eine Codeanalyse drüber laufen, der findet z.B. nicht disposete Objekte.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    michl75 schrieb:

    immer noch fast 400 Icon (auch wenn kleine) enthalten. Wir wollen es auf max. 50 eingrenzen. Sind 50 immer noch zu viel ?
    Keine Ahnung.
    Macht viele Backups, und vergleicht dann, ob und wieviel eure Veränderungen was bringen.
    Ich weiß aber, dass man mit Icons unglaublichen Mist machen kann - hier mal eine DatenKlasse, wo mir der Schreikrampf malwieder im Halse steckengeblieben ist
    (so ungefähr, aussm Kopf):

    VB.NET-Quellcode

    1. Public Class MailAttachment
    2. '...
    4. Public ReadOnly Property Icon As Drawing.Bitmap
    5. Get
    6. Return My.Resources.Attachment
    7. End Get
    8. End Property
    9. End Class
    Wenn du davon 300 Attachments in einem datengebundenen Dgv (mit ImageColumn) anzeigst - dann werden da 300 mal aus den Resourcen ein Bitmap-Objekt generiert.
    lass die Bitmap 1MB haben - schwupps - 300Mb weg.
    Und sogar mit jedem Neuzeichnen jeder Zelle dieser Spalte wird jedesmal ein neues Bitmap-Objekt generiert - und ich glaub nichtmal, dasses auch iwo disposed wird...

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Also Code-Analyse abgeschlossen... Ehrlich ....... mir wird schlecht!!!
    Schaut einfach das Bild an.... mehr muss ich ned sagen.

    @ErfinderDesRades: Danke... und ich glaub ja fast, das wir echt ein Problem mit den Bimpas aus haben. So viele und überall ein anderes. Könnt grad nur Kotzen - Sorry...


    ...glaub ich brauch nichts weiter mehr sagen wa? DAs erste was ich jetzt mache unterm aufräumen ist Option strict on ... und dann mal anfangen ausmisten und korrigieren... Und das am Samstag wo ich ab Montag Urlaub hab... Nerv...
    Bilder

    • ZZZZZZZ999000.JPG

      93,13 kB, 782×444, 239 mal angesehen

    Willkommen im Club!

    Bei uns kam ich zu meiner eigenen Überraschung durch mit der Initiative, Strict On und Abkopplung des VB6-Namespaces als Code-Guideline aufzunehmen.
    Also ich hab Lizenz, Projekte Projektweit auf Strict On stellen und den Vb6-GeneralImport abzuschalten.
    Ich hab dafür eine nette Strategie ausbaldowert, wie man das flächendeckend machen kann, und zwar ohne irgendeinen Code wirklich zu verändern.
    Kling dumm - zu ändern ohne zu ändern - aber isses nicht.
    So wird zumindest in Zukunft nicht mehr so weiter-gemacht, und die Verbesserungen kann man dann sukzessive, dateiweise, vornehmen, wenn halt auch sonst was dran zu machen ist (never carefully change a running system).

    Ich nehme mal an, ihr habt ein SourceControl-System?
    Dann sollte man auch derlei Refactorings eigens committen, und nicht durchmischt mit Commits funktionaler Weiterentwicklung.

    @michl75 Du musst nicht gleich dem ganzen Projekt Strict On geben, nutze dies nur, um die Dateien mit den meisten Fehlern zu finden.
    Dann machste wieder Strict Off und gibst dieser einzelnen Datei Strict On und räumst auf.
    Dann wieder gas ganze Projekt usw. bis Du fertig bist. ;)
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    hihi - hier kommemer in Strategie-Diskussion - meine ist grad annersrum:
    Ich mach Solution-weit - alle Projekte! - Strict On, und das bleibt auch so.
    Im direkten Nachgang gebe ich allen Dateien mit Compilerfehlern Option Strict Off.

    So hab ich für die Zukunft die Weichen gestellt, und zum Aufräumen einer Datei macht man dort halt das Option Strict Off weg.

    Meine Strategie "Erstmal den Unfug nur sichtbar machen" beinhaltet noch weitere Schritte - auch mittm vb6-Namespace - Interesse?

    ErfinderDesRades schrieb:

    meine ist grad annersrum
    Das liegt auch ganz gewiss da dran, dass meine "Unfug"-Projekte in C# geschrieben sind, da komm ich bei Strict Off gar nicht vorbei. Zum Glück. :thumbsup:
    Bei meinem aktuellen solchen waren 3 Generationen Software in einem Projekt vereint, ohne dass die alten Generationen entfernt wurden. Da hab ich mal in ner Woche villeicht 50 Formen rausgeworden, weil die keinen Caller mehr hatten, und die Exe wurde 1 MB kürzer.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Sorry das ich mich da mit rein schalte:

    von @ErfinderDesRades
    Meine Strategie "Erstmal den Unfug nur sichtbar machen" beinhaltet noch weitere Schritte - auch mittm vb6-Namespace - Interesse?

    Ja, hätte ich... hab da auch ein kleines Programm "geerbt" bekommen. Es ist zum Glück nur ein kleines Programm...
    "Hier könnte Ihre Werbung stehen..."