Erste Schritte Die Kunst am Programmieren

[Almsi]

Hallo Zusammen,

ich habe nun zu gut 3/4 das Buch "Einführung in JAVA" beendet und kann bereits jetzt kleinere Sachen umsetzen (z.B. User-Input um die Fläche eines Kreises zu berechen und son Zeug ).

Es macht mir super viel Spaß und ich will auch neben meiner Berufstätigkeit konstant dran bleiben und pro Woche ca. 8 - 12 Stunden aufwenden.

Ich stehe natürlich noch komplett am Anfang, würde jedoch gerne wissen, ob die folgende Aussage zutrifft:
- Wenn man in JAVA programmiert, dann bedient man sich i.d.R. verschiedenster Bibliotheken und fügt Funktionen aus dieser zusammen um ein neues Produkt zu schaffen. Wenn ich mir bsp. eine Bibliothek über Bildererkennung runterlade, so kann ich durch die Funktionen im Programm z.B. programmieren, dass mein Programm nur weitergeht, wenn es ein Gesicht erkennt.

Aus dem Grund besteht die Kunst des Programmierens aus dem Kennen der Basics und die Herausforderung liegt darin, sich in die jeweilige Bibliothek einzuarbeiten ?

Ist meine Annahme so richtig ?!

 

[Bitfehler]

Und wer programmiert dann die Bibliothek?

 

[Almsi]

@Bitfehler:

Das machen natürlich auch Programmierer bzw. studierte Informatiker, oder ? ;- )
Bibliotheken wie z.B. zur Bildererkennung oder Spracherkennung würde Dir ja kein reiner Anwendungsentwickler schreiben können, da dahinter doch sehr sehr viel abstrakte Mathematik steht.

Oder irre ich mich ? :/

 

[Tobse]

Das machen natürlich auch Programmierer bzw. studierte Informatiker, oder ? ;- )
Bibliotheken wie z.B. zur Bildererkennung oder Spracherkennung würde Dir ja kein reiner Anwendungsentwickler schreiben können, da dahinter doch sehr sehr viel abstrakte Mathematik steht.

Oder irre ich mich ? :/

Das ist etwa zur hälfte richtig Die Algorithmik, die bei der Bilderkennung arbeitet, wird von Mathematikern entwickelt (die sich mit Computern und Programmirung meist nur oberflächlich auskennen). Das ganze wird dann aber von Anwendungsentwicklern und Informatikern in eine performante, benutzbare, wartbare und einfach zu erlenende Form, die Library, gebracht. Insofern gibt es schon mehr zu beachten.

Deine Aussage ist grundsätzlich relativ nahe an der Realität. Du musst beim programmieren nicht viel Wissen, du musst nur wissen, wo es steht (Google, Standards, etc...). Zur "Kunst" der Softwareentwicklung zählen für mich aber auch ein paar andere Dinge, die wichtigsten:

• gutes Abstraktionsvermögen: der Computer muss die reale Welt sehr oft "simulieren". Das im Code richtig abzubilden erfodert einen Blick fürs große ganze und viel abstraktes Denkvermögen.
• Detailkenntnisse: Um sicheren und effizienten Code zu schreiben bedarf es viel Detailkenntnis der verwendeten Programmiersprache (auch kenntnis der Standard-Library einer Programmiersprache)
• Methodik: Qualitative und wartbare Software zu schreiben braucht Disziplin bzgl. der Best-Practices (Dokumentation, Konventionen). Zusätzlich müssen Softwareentwickler oft Software für Fachbereiuche schreiben, die ihnen persönlich zunächst völlig unbekannt sind. Man braucht also einiges an Methoden um mithilfe von Fachliteratur und dem Kunden den Fachbereich zu verstehen und ihn adequat auf die Computer-Welt zu übertragen.

Vor allem der letzte Punkt mag leicht wirken; ist aber in der Praxis die größte Herausfoderung. Z.B. Microsoft ist darin peinlich schlecht. Das spiegelt sich, seit Jahrzenten, in der mießen Benutzerfreundlichkeit der meisten Microsoft-Software.

 

[stg]

@Tobse Speziell ohne den letzten Punkt wäre der Job vorallem auch langweilig

 

[eldrior]

Die Kunst ist es dann, wie hier auch teilweise erwähnt, seinen Code so zu schreiben, dass man ihn problemlos für andere Probleme wiederverwenden kann. Wenn ich also ein Programm schreibe, dass die Abarbeitung von Anrufen in einem Callcenter simuliert und dann irgendwann die Fortpflanzung von Bienen simulieren soll, dann sollten beide Programme im Kern dieselben sein.

Außerdem musst du teilweise ziemlich genau wissen, wie du eine Bibliothek anwenden musst. Es nützt dir bspw. nichts Daten mit Bibliothek X zu verschlüsseln, wenn du nicht weißt, woher die eigentliche Sicherheit beim Verschlüsseln kommt, die du zum Nutzen der Bibliothek aber nicht unbedingt implementieren musst. In dem Beispiel stellt sich z.B. die Frage, wie oft man iteriert, oder bei Hashfunktionen, welches Salt dazu kommt. Immer dasselbe?

Und wenn du dann größere Programme schreibst, müssen diese meistens DAU-sicher geschrieben sein, was meist schwieriger ist, als es sich anhört. Außerdem kommt irgendwann der Punkt, an dem Performance eine Rolle spielt. Dann musst du teilweise genau wissen, wie die Bibliothek, die du nutzt ein bestimmtes Problem löst.

Du musst dich irgendwann vermutlich auch mit Multithreading und damit verbunden Deadlocks etc. beschäftigen.


Du hast Recht, dass du viele Programme durch Basics+Bibliotheken schreiben kannst, aber um ein gutes, ausfallsicheres, performantes Programm zu schreiben bedarf es schon ein bisschen mehr

 

[JStein52]

dass man ihn problemlos für andere Probleme wiederverwenden kann. Wenn ich also ein Programm schreibe, dass die Abarbeitung von Anrufen in einem Callcenter simuliert und dann irgendwann die Fortpflanzung von Bienen simulieren soll, dann sollten beide Programme im Kern dieselben sein.

Das ist nach meiner Erfahrung reine Theorie bzw. Wunschdenken. Eine Applikation enthält eine gewisse Business-Logik und die lässt sich sehr selten auf andere Aufgabenstellungen übertragen. Für die vom TE angeführten Bibliotheken ist das natürlich anders.

 

[eldrior]

Das ist nach meiner Erfahrung reine Theorie bzw. Wunschdenken. Eine Applikation enthält eine gewisse Business-Logik und die lässt sich sehr selten auf andere Aufgabenstellungen übertragen. Für die vom TE angeführten Bibliotheken ist das natürlich anders.

Ich gebe zu, dass es nicht einfach ist die Programme so zu schreiben, aber es macht Sinn und wenn man es anwendet (vorausgesetz man hat Entwickler die dazu in der Lage sind), spart man auf Dauer unglaublich viel Zeit.

 

[JStein52]

Ich behaupte es ist praktisch unmöglich. Du hast in jeder neuen Applikation einen neuen Kunden und der will alles anders als der vorherige:
- Model: du hast jedes mal andere Daten, mal stehen sie in einer Datenbank, mal in XML-Dateien, mal in kundenspezifischen Dateien, mal sind die Tabellen bzw. der Aufbau vorgegeben, mal so und mal so.
-View: Jeder Kunde hat eigene Vorstellungen wie seine Oberfläche aussehen soll und macht dir da Vorgaben. Da kannst du noch so schöne Oberflächen zur Fortpflanzung von Bienen haben.
- Controller: enthält eine ganz spezifische Businesslogik und du musst deine Architektur schon arg an den Haaren herbeiziehen wenn die universell passen soll.

Ich kenne kein praxisrelevantes Projekt wo du das so entwerfen könntest dass du da was wiederverwenden kannst (mal abgesehen von Stellen die aber in die Kategorie "Bibliothek" fallen.)
Das einzige was wiederverwendbar ist sind Design-Patterns, allgemeine aus der Literatur und spezielle die sich deine Firma geschaffen hat.

 

[Tobse]

Ich behaupte es ist praktisch unmöglich. Du hast in jeder neuen Applikation einen neuen Kunden und der will alles anders als der vorherige:
- Model: du hast jedes mal andere Daten, mal stehen sie in einer Datenbank, mal in XML-Dateien, mal in kundenspezifischen Dateien, mal sind die Tabellen bzw. der Aufbau vorgegeben, mal so und mal so.
-View: Jeder Kunde hat eigene Vorstellungen wie seine Oberfläche aussehen soll und macht dir da Vorgaben. Da kannst du noch so schöne Oberflächen zur Fortpflanzung von Bienen haben.
- Controller: enthält eine ganz spezifische Businesslogik und du musst deine Architektur schon arg an den Haaren herbeiziehen wenn die universell passen soll.

Ich kenne kein praxisrelevantes Projekt wo du das so entwerfen könntest dass du da was wiederverwenden kannst (mal abgesehen von Stellen die aber in die Kategorie "Bibliothek" fallen.)
Das einzige was wiederverwendbar ist sind Design-Patterns, allgemeine aus der Literatur und spezielle die sich deine Firma geschaffen hat.

Ich stimme dir da 100% zu. Der Trick liegt meiner Meinung nach eher darin, die Kundenspezifischen Anforderungen aus so vielen Wiederverwendbaren Teilen wie möglich aufzubauen. Sprich pro Projekt kümmerst du dich den Großteil der Zeit um Kundenspezifische Anpassungen und nicht darum, das eine Modul leicht abgeändert neu zu schreiben. Beispielsweise eine Benutzerverwaltung, ein Rechtesystem, Error-Handling, ...

 

[eldrior]

@JStein52

Nehmen wir an du hast bereits ein CRM System für einen Kunden geschrieben. Der nächste Kunde möchte ein Programm zum Einteilen seiner Schichtarbeiter haben.
In beiden Fällen werden Personen verarbeitet. In beiden Fällen haben diese Personen Namen und Kontaktmöglichkeiten. In beiden Fällen haben die Personen Nummern zur eindeutigen Identifikation. Gut, einmal heißt die Nummer Kundennummer, einmal Personalnummer, aber das ist nebensächlich.
Du kannst also problemlos im Programm für die Schichtarbeiterverwaltung von der grundlegenden Klasse zum Abbilden einer Person erben und diese anpassen.
Nehmen wir an der Kunde hatte einen Garantiefall und das CRM soll den Kundenbetreuer daran erinnern nach X Arbeitstagen beim Kunden zu fragen, ob alles in Ordnung ist. Dann braucht das CRM dafür einen Kalender, der nicht nur Wochentage kennt, sondern auch in der Lage ist Feiertage zu berechnen. Warum sollte man das zum Einteilen der Schichtarbeiter neu implementieren?


Wenn du solche Funktionen aber nicht halbwegs allgemein geschrieben hast, darfst du sie erneut schreiben, oder hast sehr hohen Anpassungsaufwand um diese zu verwenden.

 

[JStein52]

Das ist genau das was ich sage: es wird Dinge geben die du wiederverwenden kannst, z.B. ein Klasse SpecialCalendar oder eine Klasse Person und solche Dinge wie sie @Tobse genannt hat. Aber die Businesslogik und die Oberfläche sowie die Datenhaltung kriegst du in jedem Projekt neu vorgegeben !

 

[eldrior]

Bei der Oberfläche gebe ich dir recht, aber auch die Businesslogik kann übernommen werden. Der Algorithmus, der Stundenpläne für Schüler/Lehrer erstellt, kann auch ohne Anpassungen Schichtpläne erstellen. Wenn man das konsequent durchzieht, muss man bei neuen Projekten (abgesehen von der Oberfläche) oft nur zusammensuchen, leichte Anpassungen machen und kann sich auf die wirklich neuen Sachen konzentrieren.

 

[Tobse]

Bei der Oberfläche gebe ich dir recht, aber auch die Businesslogik kann übernommen werden. Der Algorithmus, der Stundenpläne für Schüler/Lehrer erstellt, kann auch ohne Anpassungen Schichtpläne erstellen. Wenn man das konsequent durchzieht, muss man bei neuen Projekten (abgesehen von der Oberfläche) oft nur zusammensuchen, leichte Anpassungen machen und kann sich auf die wirklich neuen Sachen konzentrieren.

Das wage ich doch stark zu bezweifeln. Ein Stundenplan hängt von den Verfügbaren Fachräumen (Labore, Klassenzimmer, PC-Räume, Fachsammlung u.s.w), den verfügbaren Lehrern, deren Fachkompetenzen und Klassenzuordnungen und letztlich den Wochenstunden je Fach, Klassenstufe und Schulart ab. Ein Schichtplan hat völlig andere Abhängigkeiten: Kompetenzen des Arbeiters, verfügbare Werkstoffe, aktuelle Produktionen, Urlaubskalender u.s.w.
Ja, man kann einen Algorithmus schreiben, der so krass konfigurierbar und abgebrüht ist, dass er mit beidem fertig wird. Es ist aber IMHO deutlich einfacher, beides mal einen angepassten Algorithmus zu entwickeln. Einen Schichtplan-Algorithmus von einer Firma auf die andere zu übertragen ist einfach.

 

[Meniskusschaden]

Bei der Oberfläche gebe ich dir recht, aber auch die Businesslogik kann übernommen werden. Der Algorithmus, der Stundenpläne für Schüler/Lehrer erstellt, kann auch ohne Anpassungen Schichtpläne erstellen. Wenn man das konsequent durchzieht, muss man bei neuen Projekten (abgesehen von der Oberfläche) oft nur zusammensuchen, leichte Anpassungen machen und kann sich auf die wirklich neuen Sachen konzentrieren.

Dem würde ich noch teilweise zustimmen. Letztendlich ist ein Stundenplan aber auch nichts anderes als der Schichtplan einer spezifischen Branche. Deswegen ist es auch kein gutes Beispiel zur Bestätigung der ursprünglichen These, in der es doch darum ging, dieselbe Businesslogik für sehr unterschiedliche Anwendungsfelder zu nutzen.

Einen Schichtplan-Algorithmus von einer Firma auf die andere zu übertragen ist einfach.

Ich denke, selbst das kann äußerst schwierig werden. Anforderungen an Schichtplanungssysteme können sehr schlicht, sehr komplex und vor allem auf unterschiedliche Weise komplex sein. Selbst wenn man es schafft, alles mit einer übergreifenden Businesslogik abzubilden, heisst das noch lange nicht, dass das effizienter wäre, als getrennte Logiken zu entwickeln. Es kann sehr aufwändig sein, ein komplexes Sytem für einfache Anforderungen zu customizen. Und es so zu entwickeln, dass das einfach genug ist, wäre vermutlich noch aufwändiger.

 

[eldrior]

@Tobse
- Verfügbare Fachräume = verfügbare Maschinen
- verfügbare Lehrer = verfügbare Mitarbeiter
- deren Fachkompetenzen = deren Fachkompetenzen
- Ferienzeiten = Urlaub der Mitarbeiter

Die Grundfunktionen sind gleich. Man kann also die entsprechende Klasse erben und weitere Funktionen wie die Suche nach verfügbaren Werkstoffen hinzufügen. Klar muss man Anpassungen vornehmen, aber die Grundfunktionen bleiben weiterhin erhalten und die muss man nicht erneut programmieren.

 

[Tobse]

- Verfügbare Fachräume = verfügbare Maschinen
- verfügbare Lehrer = verfügbare Mitarbeiter
- deren Fachkompetenzen = deren Fachkompetenzen
- Ferienzeiten = Urlaub der Mitarbeiter

Wenn verfügbare Fachräume die verfügbaren Maschinen (sagen wir Arbeitsplätze) sind, musst du Mitarbeiter zu Arbeitsplätzen zuordnen. Dann ergibt aber "verfügbare Lehrer = verfügbare Mitarbeiter" keinen Sinn; denn im Stundenplan musst du ja Klassen zu Fachräumen und Lehrern zuordnen.

Die Grundfunktionen sind gleich. Man kann also die entsprechende Klasse erben und weitere Funktionen wie die Suche nach verfügbaren Werkstoffen hinzufügen. Klar muss man Anpassungen vornehmen, aber die Grundfunktionen bleiben weiterhin erhalten und die muss man nicht erneut programmieren.

Was ist denn die Grundfunktion? Eine Zeitliche Zuordnung aller beteiligten Komponenten sodass keine Komponente zur selben Zeit doppelt verwendet wird. Das allgemein zu implementieren wäre letztendlich ein Brute-Force. Wenn der Algorithmus allerdings mit den Details vertraut ist, kann man optimieren.
Ich denke ich verstehe, was du sagen willst. Die Stunden- und Schichtpläne sind aber kein gutes Beispiel.

----------

Ich denke, selbst das kann äußerst schwierig werden. Anforderungen an Schichtplanungssysteme können sehr schlicht, sehr komplex und vor allem auf unterschiedliche Weise komplex sein.

Wenn ich genauer drüber nachdenke, gebe ich dir recht; eine spezielle Implentierung des Algorithmus ist wahrschienlich einfacher.

----------
Nur um Missverständnissen vorzubeugen: die wie den Kalender, die Mitarbeiter/Personenverwaltung u.s.w kann man natürlich Projektunabhängig entwickeln. Der Kern des Algorithmus, wahrscheinlich nicht mehr als 200 Zeilen Code, profitiert imho deutlich davon, an die Anforderungen angepasst zu sein (im Hinblick auf Performance und Ressourcen).

 

[JStein52]

Die Grundfunktionen sind gleich

Naja, die Beispiele sind ja meistens so konstruiert dass es zumindest Ähnlichkeiten gibt. In der Praxis hatte ich das noch nie. Es sei denn du arbeitest in einer Firma die sich auf solche Funktionalitäten spezialisiert. Wenn du Anwendungsentwicklung als Kundenprojekt machst kannst du das alles vergessen. Da hast du total unterwchiedliche Aufgabenstellungen. Da zahlt ein Kunde in der Regel sehr viel Geld dafür dass du ihm genau das implementierst was er will und nicht für das was du so ähnlich schon mal gemacht hast. Und schon ist die ganze Wiederverwendbarkeit im Eimer.

Um beim Beispiel des TE zu bleiben: was willst du mit einer Gesichtserkennungssoftware in einer Netzwerkmanagementsoftware für ein Mobilfunkunternehmen. Oder in einem Programm das Schach spielt. Oder was tut ein Schachprogramm in einem automatischen Landesystem für die nächste Airbus-Generation ? Wie gesagt, du kannst immer Beispiele finden die einander ähnlich sind. Aber dein nächster Kunde nimmt darauf keine Rücksicht

 

[SimProtect]

Ich denke, dass es stark darauf ankommt, von was genau wir hier reden. In unserem Hause gehöre ich in das Frameworker-Team. Das bedeutet, dass meine Aufgabe ist, die grundlegenden Frameworks für unsere Anwendung zu planen, zu erweitern oder ggf. auch neu zu entwickeln. Und dazu gehört auch die Analyse, welche Logikelemente grundsätzlich in das Framework gezogen werden und welche dem Team der Anwendungsentwicklern vorbehalten werden.

Somit basiert der eigentliche Kern unserer Anwendungsprogramme auf einer wiederverwendbaren Software.

Dazu kommen spezialisierte Frameworks - mein "großes Baby" ist beispielsweise das Simulationsframework, mit dessen Hilfe sämtliche Simulationen im Hause entwickelt werden.
Da fängt das ganze schon an - dieses Framework ist der Kern aller Simulationsframeworks, bietet aber eine denkbare ungünstige Unterstützung für Verwaltungsprogramme, Messenger oder Nachrichtenclienten <- man könnte sicherlich vieles davon modifiziert benutzen, aber das ist dann wirklich hässlich.

Auf der Ebene unsere Anwendungsprogramme sieht es dann so aus, dass diese zwar häufig auch einen gemeinsamen Kern zugreifen (eben das Framework), aber in der spezifischen Logik entsprechende Besonderheiten aufweisen - und in solchen Aufträgen kommen häufig Dinge vor, mit denen man so nicht geplant hatte. Dann geht es bei solchen Elementen los, dass man das Framework modifzieren muss usw.

Bei uns im Hause gab es vor Jahren - deutlich vor meiner Zeit - mal den großen Wahn, dass man alles unbedingt höchst generisch entwickeln musste und sehr häufig die Aussage im Raum stand "Wieso, vielleicht brauchen wir das mal irgendwann".
Das Ergebnis war ein sehr großes Framework voller "man könnte das ja mal brauchen"-Dingen, das dadurch auch eine entsprechende Komplexität aufwies, an der es letztlich gescheitert ist.

Im Endeffekt kommt es immer darauf an - man kann vieles wiederverwendbar gestalten und bei einigen Dingen/Operationen/Objekten ist das auch sehr sinnvoll. Bei wieder anderen ist das dann schnell ein Herumschnibbeln und Zuschneiden, was häufiger auch mal schlampig durchgeführt wird, weil Entwickler darauf keine Lust / dafür keine Zeit hatten. Das sehe ich dann als Elemente an, die man am besten mit dem Projekt und seinen spezifischen Anforderungen neu schreibt.

***
Was die Kunst des Programmierens angeht: Ich denke, dass das auch viele Seiten hat.
Tobse hat oben bereits einiges genannt. Ich würde noch "Sozialkompetenz" als wichtiges Merkmal hinzuzählen.
Häufig programmiert man nicht für sich alleine, sondern gemeinsam mit anderen. Man muss hier auch mit denen und ihren Lösungen umgehen können und man muss sich auch absprechen können. Das ist ein Faktor bzw. eine Fähigkeit, den viele - so glaube ich - ziemlich unterschätzen. Das klingt vielleicht für einige sehr trivial, aber ich habe da schon häufiger regelrechte Konflikte erlebt.

 

[JStein52]

grundlegenden Frameworks

Genau, Frameworks sind da etwas anderes.

den großen Wahn, dass man alles unbedingt höchst generisch entwickeln musste

Ja, von der Sorte kenne ich auch einige.

 

[Dukel]

Ich würde mich mal bei http://clean-code-developer.de/ umschauen. Dort sind einige Prinzipien beschrieben die hier zutreffen.