Hallo,

ich habe mal eine Frage an alle die da einige Tipps parat haben.

Wie behaltet ihr die Übersicht wenn euer Projekt mal etwas größer ausfällt??

Bei mir ist immer das Problem, das ich schnell den Überblick verliere und nach und nach
einfach nicht mehr durchblicke und das Projekt langsam aufgebe..
Das will ich diesmal vermeiden und wollte Fragen was ihr da so macht (Falls ihr das Problem überhaupt kennt..).
So viele Subs und Funktionen etc. da kann ich mir das irgendwann nicht mehr merken,
was, wie, wo, alles in welcher Klasse/Modul passiert und so weiter und sofort.. xD

habt ihr vielleicht ein paar Tipps für mich

Gruß Eistee

Naja, anständig strukturieren und dokumentieren, dann klappt das schon.

Eistee schrieb:

Das will ich diesmal vermeiden und wollte Fragen was ihr da so macht (Falls ihr das Problem überhaupt kennt..).
So viele Subs und Funktionen etc. da kann ich mir das irgendwann nicht mehr merken,
was, wie, wo, alles in welcher Klasse/Modul passiert und so weiter und sofort.. xD

Das einzige was hilft: Das Projekt von vornherein in logische Teilbereiche zerlegen.

Bei mir ist es so, dass ich Subs/Funktionen bis zum abwinken habe

Bei meinem jetztigen Projekt habe ich aktuell 4.000 Zeilen und da den Überblick zu behalten ist verdammt schwer



Ich mach es so: Wenn ich an einem Sub/Funktion nicht arbeite, immer "einklappen" so das man nur den Namen sieht
Dazwischen noch ein paar Leerzeilen und schon wirkt es geordneter

Dann teile ich mir das noch auf Module bzw. dll's auf
Sodass ich weiß: "Aha, Modul1 kann Dateine lesen/schreiben und Modul2 führt berechnungen aus"


Und wenn man längere Subs/Funktionen hat, dann immer die Kommentarfunktion benutzen, damit ich sofort weiß welcher Codeblock/Absatz was macht (z.B. in dem ersten Absatz werden Variabelen deklariert und im zweiten wird die erste Berechnung durgeführt, usw.)


Hoffe ich konnte dir helfen






Mfg.
SAR

OOP und DRY ersparen einem viel Schreibarbeit und erleichtern die Übersicht.

Aber die Planung VOR der Programmierung ist der eigentliche Schlüssel zum Erfolg, auch wenn es vielen schwer fällt sein Programm erst auf dem Papier zu entwickeln.

Ich benutze oft


Um Teilbereiche zu erstellen.
Außerdem kommentiere ich sehr viel aus.

Die Übersicht im Code hält sich (beim jetzigen Projekt) noch in grenzen..
(Ohne Region Kommentare und klassen bzw. Mudulnamen die mir sagen was wo gemacht wird wäre ich schon bei einem relativ kleinen Projekt verloren..)

Das große Problem im Moment ist ehr so "Was habe ich schon?" "Was brauche ich noch?" oder wenn ich eine Funktion schreibe "ähh moment mal was brauch ich hier nochmal wofür.."
Peinlich Peinlich ist weiß :S. Es ist aber irgentwie echt schwer für mich.

Mit VB2008 arbeite ich ja noch nicht sehr lange. Möglicherweise
gibt es dort ja so eine Funktion... Was ich oft benötigen würde sind
benennbare Textmarker. Normalerweise arbeite ich darum
viel mit Lesezeichen.

Ansonsten lege ich auch ähnliche Subs und Functions
zusammen, so dass ich sie leichter finde.

Auch die Benennungen der Subs kann sehr hilfreich sein,
weil sie dann leichter im Dropdown zu finden sind.

Das mit dem kompletten planen vorher auf einem Blatt hört sich wirklich gut an.

Dann müssten man im Prinzip nur noch "nach Programmieren".
Das blöde dabei ist ich fang immer an wenn ich meine das ich alles zum Projekt habe und dann so nach ein paar tagen,
fällt alles zusammen und ich merke oha da brauch ich noch etwas da und da und da..

Muss mir in dieser richtung mal etwas überlegen wie ich vorher wirklich alles zusammen bekomme.

Naja ich benutze auch sehr viel Regionen,
außerdem versuche ich alles so umzubennenen das mir möglichs sofort einfällt wofür der Codeteil gut ist.

Lg

Also, das für mich wichtigste sind die Regionen. Meine Projekte sind immer voll mit denen. Wenn man alle Regionen eingeklappt hat, gibt es nichts mehr außer Regionen. So behält man leicht den Überblick. Dann nat. noch OOP, alles schön in Klassen auslagern (und mit sinnvollen Namen), dort kann man die Klassen auch in Ordnern sortieren ;).
Bei den Events z.B. beim Menü o.ä. kann man Aktionen vergeben, das ist einfacher. Man macht sich eine Methode DoAction o.ä. und gibt jedem Button, Menüpunkt etc. ein Event welches dann die Action die im Tag an das Control angehängt ist ausführen. Das hilft mir nicht die Funktionen zu kopieren, weil ich sie z.B. 2 mal benötige.

Aufpassen, dass man nicht ins Blaue rein-"programmiert", sondern schon vorher einen Plan hat. Wenn man dann von Anfang an die Kapselung der Objekte optimal durchführt, dann kann man auch einzelne Teile ganz gut gegen bessere austauschen.
Die VB-IDE verleitet natürlich sofort zum drauflos-basten. Bei kleinen Projekten kann das noch funktionieren, bei großen Aufgaben würde ich schwer davon abraten.
Die meiste Arbeit - wie schon geschildert - sollte man vorher erledigen. Die Programmlogik kann man auch mal zwischendurch festlegen, auch wenn kein Computer in der Nähe ist. (Blatt Papier)

Vielleicht interessiert dich auch dieser thread: Projekt-Vorbereitung

#Region
und viele Module.

Einige sagen sogar auch alle Codes in eine Dll zu packen. Halt ich für Unsinn ist für mich irgendwie viel zu kompliziert.
Variablen übergeben auf Werte im Programm zugreifen etc.

@der_Kurt

Genau so ist es bei mir villeicht nicht ganz so schlimm wie damals bei Vatter aber so ähnlich..

ich "versuche" alles aufzuschreiben doch dann stimmt die methode nicht weil sie nicht passt und
dann muss ich das wieder ändern und ruck zuck bin ich im Chaos gelandet..

Wie schreibst du deine methoden und Funktionen auf?
Genau nach dem Syntax schema oder hast du da dein eigenes?

#Region.
Eindeutig benannte Subs/Funktionen.
Und natürlich Kommentare.

Wenn VB diese Features nicht hätte, hätte ich aus lauter Frust aufgehört, zu programmieren :pinch:

Werde gleich (falls ich dazu komme) mal mein akuelles Projekt auseinander wuseln und auf einem Blatt schreiben WAS ich brauche und WAS ich habe, dann alles neu Struckturieren und ich hoffe das es diesmal klapt.

Ich habe bestimmt an die 20 Projekte in meinem Ordner, die alle halb fertig sind und ich löschen kann, da jedes einzelne im Chaos versunken ist trotz Regionen, Kommentaren, und guter Namensgebung mangels fehlender Planung im vorraus.

Jetzt muss ich nicht nur Vb lernen sondern auch die Planung im vorraus..
Ab jetzt Verweise ich lieber erst auf die Pojektplanung und dannach auf die Grundlagen

Hoffe es klappt jetzt, danke erstmal. (Wenn noch Tipps hat immer weiter her damit!)

Edit:

der_Kurt Wie schreibst du deine Methoden und Funktionen auf
genau nach dem Syntax schema oder hast du da dein eigenes?

Wäre noch interessant.

Was mir gerade noch einfällt. Du solltest feste Zahlen und Pfade etc. durch Konstanten definieren. Da musst du nicht immer in dem Methoden kramen wenn du was ändern willst ;).

Kurz schau dir UML an.

Bedeutet:
Mache dir einen genauen Plan (Klartext und für jeden verständlich).
Mach dir zuerst einen Ablaufplan... Was führt der Benutzer aus und was dein Programm.
Danach die Klassen die du benötigtst.. darin natürlich die Subs, Funktionen und Propertys.

Im Grunde geht jede Softwareentwicklung diesen Weg. Kein Unternehmen schreibt blind darauf los und baut Subs oder Funktionen nach laune ein.

Wie gesagt UML verstehen bedeutet Entwickeln können.

Also ich denke mal, die Rede ist von einer Projektmappe. Wenn es ein wirklich großes Programm wird, dann lege ich mehrere Projekte für die wichtigsten Teilbereiche an. Natürlich auch immer mit sinnvoll benannten Klassen, sonst ist klar, dass man da den Überblick verliert. Also ich hab eigentlich noch nie den Überblick verloren.

Wie schreibst du deine methoden und Funktionen auf?
Genau nach dem Syntax schema oder hast du da dein eigenes?

Nein, nicht nach der Syntax, Notizen in 'Pseudo-Code' habe ich schneller zusammen...
UML ist auch ein schönes Stichwort. Damit kannst du auch ohne Aufwand Klassen planen, und leicht wieder ändern, BEVOR diese jemals einen Computer zu Gesicht bekommen.

Viele befreundete Programmierer, die die freie Wahl einer Programmiersprache haben, haben den gesamten Programmablauf schon fertiggestellt, und entscheiden sich erst dann für die optimale Programmiersprache.