Ablauf der Erstellung eines Java Programmes

[monsterherz]

Moin Allerseits. Ich bin gerade dabei für meinen Kopf und meine HP zu überlegen wie ich am Besten Schritt für Schritt bei der Entwicklung eines Java-Programms vorgehe. Bisher bin ich soweit:

• Überlegen welche Tools importiert werden sollen (z.B java.util.Scanner etc)
• Hauptklasse erstellen
• Überlegen ob zusätzliche Klassen gewünscht sind.
• Zusätzliche Klassen (ausserhalb der Main Klasse) ggf definieren
• Welche Attribute werden für die Klassen benötigt?
• Variablen mit Datentypen festlegen
• Sollen nur Methoden erstellt werden ?
• Die Methoden in die Hauptklasse einfügen

Was würdet ihr ändern? Was kann man hinzufügen? Ist ein Fehler drin?

 

[M.L.]

Es gibt kein Universalrezept bis zum laufenden Programm (Stichwort auch: OOA, OOD). Klassen dienen zum Herstellen von Zusammenhängen zwischen Objekten und deren zugehörigen Methoden.
Im Endeffekt muss der Code den syntaktischen Formalien des Compilers genügen, der Gebrauch weiterer Klassen, Attributen, Methoden ist da optional.

 

[httpdigest]

Kurz: Es gibt keine "Schritt für Schritt"-Anleitung. Viele deiner aufgezählten Punkte sind trivial (ja klar, legt man am Ende des Tages Klassen und Methoden und Variablen an - was anderes geht ja auch nicht, und das ist ja auch notwendig).
Das viel wichtigere ist aber, wie man diese Dinge strukturiert und miteinander verbindet.
Und hier gibt es kein "Mache erst das und dann das und dann hast du ein fertiges, gut entwickeltes Programm".
Es gibt Prinzipien, die man befolgen kann und sollte, wie etwa die schon häufig zitierten S.O.L.I.D. Prinzipien: https://en.wikipedia.org/wiki/SOLID
Software Engineering ist zum großen Teil ein intellektueller und kreativer Prozess und kein Rezept.
Und es fällt sogar sehr vielen erfahrenen Senior-Entwicklern immer wieder schwer, gute Prinzipien zu verstehen und zu befolgen und vor allem zu erkennen, wann ein Prinzip befolgt und wann verletzt wird.
Denn: Jede Software ist ein lebendiges Konstrukt, welches an sie gestellte und im realen Leben sich ständig wandelnde Anforderungen erfüllen soll. Und das auch in einem Umfeld, welches sich ständig weiterentwickelt. Deswegen ist Software Engineering insgesamt auch so schwierig: Alles entwickelt sich weiter, Anforderungen kommen hinzu und ändern sich, so dass es sehr schwer ist, die Struktur eines Programmes (außer für äußerst triviale Beispiele) von vornherein "richtig" zu machen.

 

[yfons123]

ein guter schritt wäre eine IDE zu holen die den code formatiert und das "Überlegen welche Tools importiert werden sollen (z.B java.util.Scanner etc)" automatisch macht

 

[monsterherz]

ein guter schritt wäre eine IDE zu holen die den code formatiert und das "Überlegen welche Tools importiert werden sollen (z.B java.util.Scanner etc)" automatisch macht

Ich mag nicht mit einer IDE arbeiten. Ich arbeite nunmal am Liebsten mit nem Editor unter Linux. Und wenn ich den Code direkt schreibe und nicht einfügen lasse merke ich mir den Code auch besser. Wenn ich nen Editor mit Tool brauche nutze ich derzeit Geany

 

[yfons123]

intellij oder eclipse sieht aber genauso aus...?

 

[monsterherz]

intellij oder eclipse sieht aber genauso aus...?

Ja, es ist ja auch ne IDE. Unter Gentoo Linux hab ich momentan Probs Eclipse zu kompilieren. Also hab ich das mal unter Windows installiert. Aber ist nicht mein Ding. Ich arbeite normalerweise mit der Konsole. Und wenn ich mal ne IDE nutzen möchte dann eben Geany. Der Mensch ist ein Gewohnheitstier ... und ich fummel nunmal viel und gern mit der Konsole ...

 

[Neumi5694]

Dann ist eine ordentliche Strukturierung der Datenmodelle um so wichtiger. Denn irgendwann kannst du dir nicht mehr alles merken.
Meiner Meinung nach steht und fällt jedes Programm, das nicht nur einen schlichten Algorithmus darstellt, mit der Datenverwaltung. Wenn die nicht passt, dann wird das nichts.
Der zweitwichtigste Punkt ist Wartbarkeit. Immer wiederkehrende Abläufe gehören in eigene Methoden mit lesbarem Namen. Dein Programm fasst du vielleicht erst in einem oder zwei Jahren wieder an und musst was anpassen. Bis dahin hast du längst alles darüber vergessen. Deshalb ist die Dokumentation der Methoden wichtig (Stichwort javadoc) und auch, dass die Klassenstruktur verständlich bleibt.

Welche "Tools importiert" (du meinst die imports ganz oben am Anfang der Klasse?) werden müssen, ist mitunter das Unwichtigste. Das sind Implementierungsdetails, die mit der Planung nicht viel zu tun haben. Deine Datenquellen mögen sich irgendwan ändern, irgendwann kommen die Eingaben aus einer Datei oder aber du verwendest ein anderes Framework, aber es soll das gleiche passieren. Importiere nur bei Bedarf, sobald ein Zugriff darauf erfolgt und nicht erkannt wird.
Aus dem selben Grund ist es wichtig, Berechnungen und Input/Output strikt getrennt zu halten und System.out und die Verwendung von System.err zu vermeiden, wo immer es geht. Dafür gibt's Logger-Interfaces. Am Ende mögen die vielleicht nach System.err oder System.out ausgeben, aber im Code sollte das nur sehr sporadisch vorkommen, wenn z.B. eine Eingabe ansteht (edit: Ist aber jetzt nicht einer der dringendsten Punkte, nur ein Gedanke, der mir dazu gekommen ist).
Die "Hauptklasse" ist nur dein Startpunkt. Es ist nicht unüblich, dass eine Main-Klasse überhaupt nur eine Methode hat, die nichts anderes macht, als das Programmfenster zu öffnen, eventuell noch ein paar mehr, um Konfigurationsdateien einzulesen. Es müssen bei weitem nicht alle Methoden dort rein. Wenn du z.B. viele mathematische Methoden hast, sammle sie in einer eigenen Klasse.
Weiters: Das Organisieren deiner Klassen in Packages, nicht alles in das gleiche Package. Reduziere Sichtbarkeiten, so weit es geht. Private, Package Protected usw. Nur was von außen angesprochen werden soll, wird public.
Was die Organisation der Klassen und Packages angeht, ist es heute auch üblich, in den Packaganemane Ersteller und Programmname mit unterzubringen, z.B. kann der Name Hauptklasse so lauten: org.meineid.programmname.Main.


Aber gewöhn dir eine IDE an. Welche genau, ist eher irrelevant. Ich bin Netbeans-Anhänger, andere schwören auf Eclipse oder IntelliJ. Das sind nur persönliche Präferfenzen. Selbst berndoa hat sich überzeugen lassen, der war auch ein Consolero. Wir alle haben mal mit Texteditoren angefangen. Aber es ergibt keinen Sinn, auf Knien durch die Gegend zu robben und sich die Hände am Boden anzukleben, wenn man auch stehen kann.
Dein Editor wird sich bei Refactoring schwer tun, oder beim Anzeigen der API-Dokumentation. Und mit einer IDE lernst du dann auch, wie man ein Projekt ordentlich organisiert und hast die notwendigen Werkzeuge dazu. Du solltest dich nicht mit Micromanagement aufhalten müssen (Dateinamen, Vereinheitlichen von Verzeichnisstrukturen und Packagenamen), damit du dich auf die Entwicklung konzentrieren kannst.

 

[KonradN]

Im Augenblick stehe ich hier gerade und bin unsicher, das ich Dir schreiben kann / soll.

Ich habe eine komplett andere Sichtweise.

Das Erste, das immer erfolgen muss - ist die Überlegung, was das Programm überhaupt machen soll. Alle Deine Schritte sind absoluter Unsinn, wenn noch nicht klar ist, was über entwickelt werden soll.

Das kann man nennen wie man es will. Da gibt es dann hochtrabende Begriffe wie "Object Oriented Analysis", "Object Oriented Design" (OOA, OOD) mit vielem großen Büchern. Aber Bei Dir geht es ja nicht einmal um Software Projekte sondern wirklich nur um kleine Programme. Daher kann man da massive Abstriche machen.

Es bleibt aber dabei: Du musst genau wissen, was genau Du ünberhaupt entwickeln willst. Und entweder das ist bereits so klein, dass man es so betrachten kann oder man muss es eben unterteilen.

Ein Ansatz, den ich gut finde (und den ich gerade versuche zu dokumentieren - Die ersten Ansätze finden sich bereits auf jadventure.de) ist der agile Ansatz. Den schreibe ich jetzt hier aber nicht weiter zusammen - das steht da schon jetzt Daher wirklich nur ganz ganz grob:

Wichtig ist, dass so ein Programm nicht gleich als ganzes angegangen wird sondern es wird in Teile zerlegt und dann einzelnd angegangen. Und das so, wie der Papa die Klöße isst: Einen nach dem Anderen!

Das ganze dann in Iterationen:

• Liste an "Features" / "User Stories" / "Backlog Entries" / wie auch immer man es schimpfen will wird geprüft und bewertet
• Dann wird von oben etwas ausgewählt.
• Diese ausgewählten Elemente werden im Detail geplant und dann umgesetzt
• Wenn dies umgesetzt wurde, werden Ergebnisse vorgestellt und ein Rückblick über den durchgeführten Zyklus gehalten: Was war gut? Was war schlecht? Muss was an der Vorgehensweise geändert werden.

Und dann geht es wieder von Anfang an los ...

Und wenn man Software entwickeln will, dann ist das ein Prozess, an den es gewisse Anforderungen gibt.

Ich mag nicht mit einer IDE arbeiten

Das ist mit den Anforderungen den Prozess der Software Entwicklung nicht vereinbar. Da sehe ich auch keinen Spielraum für Diskussionen.
Klar, es geht auch irgendwie ohne, aber das ist frickeln. Und frickeln ist nicht Software Entwickeln.

Zu einer Software Entwicklung gehören viele Dinge, die wichtig sind. Die entscheidend sind z.B. für die Qualität. Man braucht kein Eclipse oder IntelliJ - es reicht auch ein Fleet oder Visual Studio Code. Aber das sind halt mehr wie ein einfacher Editor.

Und dann kommen technische Dinge wie Unit Tests und so ins Spiel. Ein Projektmanagement kommt ins Spiel. Das geht super mit einer Entwicklungsumgebung.

 

[httpdigest]

wie der Papa die Klöße isst

Bitte was? 🙂 Der Papa isst alle Klöße? Und was ist mit den Kindern und der Mama?!

 

[Hansen_07]

Der Mensch ist ein Gewohnheitstier ... und ich fummel nunmal viel und gern mit der Konsole ...

Vielleicht wäre dann auch vi(m) etwas für dich? Mit diversen Plugins, kann man das zu einer richtig mächtigen IDE aufpusten. Habe jetzt keinen Link zur Hand aber da findet sich so einiges im Netz.

Und statt VS Code, nehme ich immer VSCodium. Das ist exakt der selbe Editor, nur eben "entmicrosoftfiziert".

edit: aber ansonsten bin ich was Java angeht, Nutzer von IntelliJ.

 

[KonradN]

Bitte was? 🙂 Der Papa isst alle Klöße? Und was ist mit den Kindern und der Mama?!

Die bekommen den Braten und den Salat. Das ist die typische Arbeitsteilung: Die Datenbank-Tasks macht der Eine ... die Frontend Dinge der Andere ... Der Papa kriegt nur Klöße und den leckeren Braten kriege ich. Die Mama darf den Salat haben.

 

[M.L.]

Zusatz: Schlagworte wie SOLID, OOA, OOP, Softwaretests, Algorithmen, Aufteilung in Schichten, Nutzung einer IDE,... dienen aus menschlicher Sicht dem einfach(er)en Ändern/Erweitern/Löschen/... der Software ("Teile und herrsche"-Prinzip, "Bauer und Klösse"...)

 

[Marinek]

Im Augenblick stehe ich hier gerade und bin unsicher, das ich Dir schreiben kann / soll.

Geht mir genau so. Und vermutlich hätte ich exakt den gleichen Beitrag geschrieben.

Ich mag nicht mit einer IDE arbeiten. Ich arbeite nunmal am Liebsten mit nem Editor unter Linux. Und wenn ich den Code direkt schreibe und nicht einfügen lasse merke ich mir den Code auch besser. Wenn ich nen Editor mit Tool brauche nutze ich derzeit Geany

Ich möchte noch einfügen, dass in diesem kleinen Abschnitt einfach alle deine Probleme sichtbar sind.

Zum einen machst du es richtig und fragst nach dem konzeptionellen und methodischen Vorgehen. Dann schreibt dir ein Kollege, dass man in der SW eine IDE nutzt.
(Absolut 0 Raum für Diskussion).

Aber du sagst am besten programmiere ich anders. Du bist noch komplett am Anfang. Und, wenn ich sondern fragen hier überfliege, dann hast du noch viel an Grundlagen zu verstehen. Sowohl jetzt als auch in der Zukunft, sollte man das Feedback der Kollegen ernst nehmen. Niemand kann alles wissen. Und ältere werden sagen: das habe ich schon immer so gemacht.

Aber du fängst jetzt erst an. Du musst alles ausprobieren und lernen. Du kannst das nicht dismissen.

Und natürlich kann man Linux nutzen. Wenn man sich damit auskennt und weiß was man tut. Aber wenn das einfach nur eine Quelle für Fehler und Fehlentscheidungen ist, dann weg damit. Klar sind Linux Grundlagen nicht schlecht. Aber ich lerne auch kein Spanisch während ich in einem Jumbo Cockpit sitze.

 

[temi]

Der Papa kriegt nur Klöße

"Kloß mit Soß" kriegt bei uns nicht der Papa...

 

[temi]

Und natürlich kann man Linux nutzen. Wenn man sich damit auskennt und weiß was man tut.

So ist das inzwischen auch nicht mehr. Meine Frau ist kein Computerspezialist und verwendet für ihre alltäglichen Dinge bereits seit über 10 Jahren Linux völlig problemlos. IntelliJ und Fleet und weitere IDEs lassen sich recht einfach installieren und verwenden. Geany ist ja auch eine IDE, die halt nicht ganz so viel Komfort bietet.

Es ist am Anfang schon ganz sinnvoll sich mit den Grundlagen von Quellcode und Kompilierung zu beschäftigen. Mit einer IDE geht es halt viel einfacher, weil man viel mehr Unterstützung beim Programmieren bekommt und dadurch weniger Zeit mit Nebensachen "verschwendet". Darum ist auch meine Ansicht, dass der Einsatz einer IDE sehr sinnvoll ist. Wobei ich auch eher zu den "einfachen" IDEs tendiere, die nicht so überladen mit Funktionen sind, die ich nie benötige. Ich beschäftige mich gerade etwas mit Rust und hatte dazu auch mit Geany experimentiert. Letztlich bin ich wieder zu IntellJ (mit der neuen UI) gewechselt, aber ich freue mich darauf, wenn Fleet verfügbar ist.

Ich würde dir empfehlen zunächst die Grundlagen zu lernen, z. B. mit "Java von Kopf bis Fuß" und danach noch "Entwurfsmuster von Kopf bis Fuß" anzuhängen. Gerade das zweite Buch bietet, neben den namensgebenden Entwurfsmustern, tiefe Einblicke, wie Objekte miteinander interagieren und OOP funktioniert. Gerade für Anfänger ist das ein echter Augenöffner.

 

[White_Fox]

Das Erste, das immer erfolgen muss - ist die Überlegung, was das Programm überhaupt machen soll. Alle Deine Schritte sind absoluter Unsinn, wenn noch nicht klar ist, was über entwickelt werden soll.

So sieht's aus, das ist das allerwichtigste. Es gibt kaum schlimmere Entwickler (egal von was, das trifft alle technischen Entwicklungen) als die, die die Ärmel hochkrempeln und losrennen ohne eine nähere Vorstellung davon zu haben, wo sie eigentlich hin wollen.

Als ich mein jCLS-Projekt begonnen habe war das erste, mir ein Notizbuch zu nehmen und so ungefähr zu zeichnen, wie ich mir die Bedienungdes Programms vorstelle. Nicht jedes einzelne Detail, aber so den groben Hauptzweck, wie hacke ich als Benutzer ein was ich einhacken will, und was bekommen ich wie zurück.

Ich mag nicht mit einer IDE arbeiten. Ich arbeite nunmal am Liebsten mit nem Editor unter Linux. Und wenn ich den Code direkt schreibe und nicht einfügen lasse merke ich mir den Code auch besser.

Meines Erachtens ein großer Fehler. Wozu solltest du dir den Code gut merken können? Schreib den Code doch besser so, daß man sich gar nichts merken muß.
Den Satz "Der Code ist die Dokumentation" kenne ich normalerweise als Spott für völlig unwartbare Projekte, wo selbst die Autoren nicht mehr wissen was sie da gemacht haben, andererseits wäre das genau das Ziel: Code schreiben, der sich selbst erklärt, den man direkt, wörtlich, als Beschreibung lesen kann was das Programm machen soll. Ich schreibe da gerne mal zwei- oder dreizeilige Methoden, um einen Arbeitsschritt zu benamsen. Gerne auch Methoden, die ein Handvoll solcher Methoden enthalten.

Ob man jetzt mit einer IDE oder altertümlich mit einem simplen Texteditor herumhantiert, würde ich jetzt als weniger wichtig ansehen (aber ich bin ja auch kein Softwerker). Aber eine IDE bietet enorme Vorteile: welche Schnittstellen bietet ein Objekt, Javadoc der Methode direkt beim Programmieren anzeigen, Compilerfehler schon zur Programmierzeit, Minicodemap, automatische Codegeneration, integrierter Debugger mit Experimentiermöglichkeiten zur Laufzeit, Autovervollständigung, Umfangreiche Refakturhilfen...ich verstehe beim besten Willen nicht, warum man darauf freiwillig verzichtet.

Ansonsten:

• Überlegen welche Tools importiert werden sollen (z.B java.util.Scanner etc)
• Hauptklasse erstellen

Das ergibt sich, außer vielleicht in einigen Spezialfällen, unterwegs.

• Überlegen ob zusätzliche Klassen gewünscht sind.

Hast du schonmal versucht, den Überblick über eine Klasse zu behalten die >1.000 Zeilen lang ist? 😉
Ich schon, zwei oder drei Mal, und das Ende vom Lied war stets, daß ich das auf mehrere Klassen aufgeteilt habe.

• Zusätzliche Klassen (ausserhalb der Main Klasse) ggf definieren
• Welche Attribute werden für die Klassen benötigt?
• Variablen mit Datentypen festlegen
• Sollen nur Methoden erstellt werden ?
• Die Methoden in die Hauptklasse einfügen

Das ergibt sich alles unterwegs.

 

[Weckers]

Kurz: Es gibt keine "Schritt für Schritt"-Anleitung. Viele deiner aufgezählten Punkte sind trivial (ja klar, legt man am Ende des Tages Klassen und Methoden und Variablen an - was anderes geht ja auch nicht, und das ist ja auch notwendig).
Das viel wichtigere ist aber, wie man diese Dinge strukturiert und miteinander verbindet.
Und hier gibt es kein "Mache erst das und dann das und dann hast du ein fertiges, gut entwickeltes Programm".
Es gibt Prinzipien, die man befolgen kann und sollte, wie etwa die schon häufig zitierten S.O.L.I.D. Prinzipien: https://en.wikipedia.org/wiki/SOLID
Software Engineering ist zum großen Teil ein intellektueller und kreativer Prozess und kein Rezept.
Und es fällt sogar sehr vielen erfahrenen Senior-Entwicklern immer wieder schwer, gute Prinzipien zu verstehen und zu befolgen und vor allem zu erkennen, wann ein Prinzip befolgt und wann verletzt wird.
Denn: Jede Software ist ein lebendiges Konstrukt, welches an sie gestellte und im realen Leben sich ständig wandelnde Anforderungen erfüllen soll. Und das auch in einem Umfeld, welches sich ständig weiterentwickelt. Deswegen ist Software Engineering insgesamt auch so schwierig: Alles entwickelt sich weiter, Anforderungen kommen hinzu und ändern sich, so dass es sehr schwer ist, die Struktur eines Programmes (außer für äußerst triviale Beispiele) von vornherein "richtig" zu machen.

Der Umgang mit dem Computer gehört aber wie das Lesen Schreiben und Rechnen heute zu den selbstverständlichen Kulturtechniken, die fast in allen Fächern Auswirkungen haben.

-
Roman Herzog