Was gehört noch zum "Fundamentwissen"? [Archiv]

x50

2009-01-08, 01:17:03

Hallo 3DC,

ich versuche mich im Bezug auf meine Programmierkenntnisse gerade einem Zustand anzunähren, welcher sich wohl am besten mit "Fundamentwissen" oder "Kompaktwissen" der Software-Programmierung bezeichnen lässt.

Bisher hab ich je ein 1200 Seitenbuch in Java und eines in C# durch (ist ja praktisch das gleiche, nur in anders ;) ).
Ich weiß nicht, ob ich dadurch das Programmmieren gelernt habe, aufjedenfall kann ich so ziemlich alles in Code umsetzen, was ich mir in einem _realistischen_ Rahmen vornehme. Wie der Code dabei aussieht, oder wie schnell er ist, ist ne andere Sache... aber das ganze funktioniert wenigstens.

Allerdings fühle ich dabei eine gewisse Unvollständigkeit meines bisherigen Wissens. Sobald ein Projekt wächst (und damit die Anzahl der Codezeilen), würde ich am liebsten die ganze Zeit von vorne anfangen, weil ich die Architektur/Strukur meiner Programme nicht für "State-of-the-art" halte, weil ich im Hinterkopf weiß, dass es da noch so etwas wie Entwurfsmuster, MVC und 3 Schichten-Modell etc. etc. gibt - Ich aber einfach nach Lust und Laune drauf loscode, weil ich keine Ahnung von den genannten Dingen habe.

Okay, halten wir mal fest: bisher kann ich relativ gut mit 2 Sprachen hantieren und habe mich dadurch auch in der Objekt-Orientierung eingelebt. Alles, was darüber hinaus das Design (nicht im optischen Sinne) eines Programms betrifft - Fehlanzeige.

Das mit den Entwurfsmustern war jetzt nur ein Beispiel.
Was gehört eurer Meinung noch zu einem solchen Fundament?

Ich will noch anmerken, dass ich das ganze Privat betreibe, d.h. weder studiere ich was in die Richtung, noch hab ich beruflich damit zu tun, Es ist einfach nur zum Spaß. Deshalb bitte eher nach dem Motto "Klein aber fein" antworten, was das wissen angeht - ein Kompaktwissen eben.

Angenommen, ihr würdet mir folgende Roadmap zu Ende schreiben, wie würde die aussehen? Fortsetzung erwünscht:

- sich mit einer Sprache beschäftigen und grundlegende Dinge wie Syntax, Sprachkonstrukte und Elemente der Sprache erlernen - done.
- sich mit Objekt-Orientierung vertraut machen - done.
- Entwurfsmuster erlernen?
- Datenbanken?

Momentan denke ich eigentlich, dass wenn ich die Entwurfsmuster kapiert habe und anwenden kann, das Kompaktwissen vollendet ist. In Datenbanken noch etwas einlesen, aber für Privatprojekte sollte das Oberflächlich reichen. Allerdings gibt es evt. Dinge, von denen ich noch garnicht weiß, dass man sie braucht, vor allem deshalb frage ich.

Gruß

Watson007

2009-01-08, 01:29:25

tja das erweitert sich ja ständig. Ist schon anspruchsvoll...
aber gute Frage, das habe ich mich auch schon öfter gefragt.

- UML-Programme scheinen einige Firmen als wichtig anzusehen. Stichwort : Codegeneratoren und "Modellbasierte Softwareentwicklung". Gibts offenbar in allen Ausprägungen... Programme wie Altova UModel, MagicDraw, StarUML, ArgoUML
- eine Scriptsprache... vbs zum beispiel
- Design Patterns... kennen auch nicht alle Programmierer, wird aber als wichtig angesehen. Wie du bereits erwähntest... auch wenn einige wie Singleton (weitgehend) überflüssig sind weil sie in die Programmiersprache eingehen (Singleton->statische klassen bspw.)
- Grundkenntnisse HTML?
- objekt-relationale Mapper wie (N)Hibernate, wenn man sich für Datenbanken interessiert
- nicht direkt mit Programmierung zu tun, aber Virtualisierer sollte man wohl bedienen können, evtl. auch VMWare Server

ach das ist einfach ein verdammt weites Feld... im Prinzip könnte man sich die ganze Zeit nur weiterbilden.

such dir ein Entwickler-Forum....

und die Grenzen zwischen einfachen Software-Entwicklern und Software-Architekten sind fließend. Es gibt Firmen für die sind nur Software-Architekten richtige Entwickler...

Monger

2009-01-08, 02:21:15

Was in meinen Augen wirklich fundamental ist, und gerne übersehen wird, ist ein wenigstens oberflächliches Wissen über die Standardbibliothek der jeweiligen Sprache.
Sprich: bei Java was halt das JDK so mit sich bringt, und bei .NET das .NET Framework. Dazu gehören jetzt z.B. mal so grundlegende Dinge wie das Collections Framework, Streams (inklusive Dateisystem), Netzwerk, Multithreading...

Aber auch so andere Sachen, die teilweise ganz eigene Sprachen hinter sich ziehen wie z.B. reguläre Ausdrücke oder XML Suchen via XPath.

Das alles existiert eigentlich in jeder modernen Sprache, nur halt in unterschiedlichen Ausprägungen, und kann man für alles mögliche gebrauchen - wenn man erstmal davon weiß.

Dann gibts noch so ein bißchen speziellere Themen, die einem aber auch schnell übern Weg laufen können. Wie z.B. Fensteranwendungen aufgebaut werden, ist sowohl in Java als auch Windows ziemlich ähnlich. Hier wie dort arbeitet eine Event Queue, und hier wie dort gibt es ähnliche Probleme (und Lösungen) mit asynchronen Prozessen.

Dann der Umgang mit Settings und Ressourcen... beides ziemlich essentiell wenn man mal tatsächlich eine Fensteranwendung haben will. Sollte man zumindest mal gesehen haben.

Expandable

2009-01-08, 07:06:45

auch wenn einige wie Singleton (weitgehend) überflüssig sind weil sie in die Programmiersprache eingehen (Singleton->statische klassen bspw.)

Singletons sind mächtiger als statische Klassen.

Shink@work

2009-01-08, 10:12:02

Ich würd mal sagen Entwurfsmuster, SQL und Concurrent Programming wären ganz brauchbar. Naja, und ich würde auch etwas in Richtung Softwareentwicklungsprozesse gehen (z.B. RUP, Extreme Programming).

Ich denke UML war den Leuten schon mal wichtiger aber schaden kanns auch nicht.

Wegen deiner Bedenken: Programmiere trotzdem. Fang öfters mal bewusst von Vorne an wenn du Zeit dafür hast.

Gast

2009-01-09, 18:26:37

HBisher hab ich je ein 1200 Seitenbuch in Java und eines in C# durch (ist ja praktisch das gleiche, nur in anders ;) ).

Meiner Meinung nach sind das um jeweils mindestens 1000 Seiten zu viel. Programmieren lernt man NUR durch Übung und davon kann man nie genug bekommen.

Ich würde einmal folgende Themen behandeln:
Netzwerk (Socket) Programmierung, Datenbanken mit SQL ansteuern bzw. Datenbankdesign (das ist eine wahre Kunst, wenn man es ordentlich machen will), dann kommen noch Multithreading (aber nicht auf Performance anzielen, sondern auf bessere Funktionalität) und ganz wichtig das Exception Handling.

Danach kommt es stark darauf an, in welche Richtung du dich weiterentwickeln willst. Kannst du auf die Linux Basis verzichten, so rate ich dir eindeutig zu C#. Hier hat man eine einheitliche Linie, auf die man aufsetzen kann, nicht so bei der Sprache, sondern von der Entwicklungsumgebung selbst. Das harmoniert einfach. Das .NET Framework hat jeder, während es bei Java nicht wirklich saubere Lösungen gibt, die Software auszuliefern (ich kann mich mit .jar Dateien nicht wirklich anfreunden) und mit dem Betriebssystem harmoniert es auch mehr, aber das ist viel auch Ansichtssache. Ich bin überhaupt bei VB.NET hängen geblieben, weil man die Syntax um einiges moderner vorkommt.

Was du auf jeden Fall machen solltest ist ein größeres Projekt, das dann auch eingesetzt wird und auch laufend erweitert wird. Dadurch lernt man am Allermeisten, da man hier gezwungen wird, sauber zu arbeiten z.B. nicht alles fest zu codieren, sondern in Config Dateien auszulagern und man lernt auch, wie man mit Bugs umgeht und die managed. Es macht einen großen Unterschied, ob man eine schöne Exception samt Stack Trace vom Kunden geschickt bekommt mit genauen Zeilenangaben, wo man dann meistens schon ohne Fehlerbeschreibung weiß, woran es liegt, oder ob man nur hört, dass es ständig abstürzt und man von 2 Leuten 3 sich ausschließende Fehlerbeschreibungen erhält.

UML ist ein schöner Standard, wie man was zeichnet, aber hilft einem am Anfang auch nicht viel weiter. Man sollte es nur einmal gesehen haben um zu wissen, welche Diagramme es gibt und welche momentan gerade sinnvoll ist. Ein Use Case Diagramm ohne Schnittstellen nach außen, ist wenig sinnvoll.

P.S.: Wenn du das Gefühl hast, du solltest von vorne anfangen, dann tu das. Der Aufwand gerade geschriebenen Code neu zu schreiben ist absolut gering im Vergleich zum Aufwand, den man hat, wenn man mit diesem Code dann weiter leben muss. Solange die Programme mit erreichen des Alpha Status bereits ihr Lebensende erreicht haben und man sich dem nächsten Projekt zuwendet, ist das egal. Wenn man den Mist dann nach 5 Jahren noch warten und erweitern muss, dann ist es nicht mehr egal, vor allem, wenn das eine andere Person ist. Die Kosten können hier explodieren. Kostet ein Bug, der von einem Programmierer beim Programmieren gefunden wird 1 Euro, so sind es nachher 10 Euro, beim firmeninternen Tester 100 Euro, beim externen Betatester 1K Euround beim Kunden 10K Euro. Ich weiß das sind nur ungefähre Richtwerte, aber die Wahrheit liegt ziemlich nah dran. Das merkt man spätestens dann, wenn die Kunden 500 km weit weg anrufen, dass die Anlage ständig abstürzt und man extra hin fährt, der eigentliche Fehler aber zufällig nicht auftritt bzw. sich nicht analysieren lässt, man glaubt es ist behoben und 5 Minuten bevor man daheim ist einen Anruf bekommt, dass schon wieder alles steht.

Gast

2009-01-09, 22:14:48

Es ist erstaunlich und eine Schande das eines der elementar wichtigste bisher
vergessen wurde.

Datenstrukturen und Algorithmen

Das gehört zur Prüfungsleistung eines jeden guten Informatik Studiums im 2. Semester.

Wer nicht weiß was der Unterschied zwischen QuickSort und BubbleSort ist,
der kennt noch nicht die Grundlagen.

Außerdem fehlt mir in dem ganzen Thread auch noch der Hinweis auf
Programmiersprachen für die Systemprogrammierung mit z.b. Pointerarithmetik wie in C/C++.

Monger

2009-01-09, 23:22:54

Es ist erstaunlich und eine Schande das eines der elementar wichtigste bisher
vergessen wurde.

Datenstrukturen und Algorithmen

...

Außerdem fehlt mir in dem ganzen Thread auch noch der Hinweis auf
Programmiersprachen für die Systemprogrammierung mit z.b. Pointerarithmetik wie in C/C++.
Ausgerechnet die zwei Sachen finde ich herzlich unwichtig. Pointerarithmetik ist eine Implementierungsproblematik die in dieser Form nur bei den systemnahen Sprachen wie C/C++ auftritt, und bei Hochsprachen wie C#/Java schlicht nicht mehr existiert. Das ist eigentlich ein Implementierungsdetail der jeweiligen Sprache.

Und Sortieralgorithmen sind was ich ein "gelöstes Problem" nenne. Kein Schwein muss sich in der Praxis noch mit Sortieralgorithmen auseinandersetzen. Man sollte wissen dass es unterschiedliche gibt, die jeweils Vor- und Nachteile haben, das wars aber auch schon. An der Implementierung solcher Algorithmen haben vorher schon Experten Jahre ihres Lebens gesteckt, und all dieses Wissen steckt jetzt schön säuberlich in den Frameworks. Wer am Collections Framework vorbei einen eigenen Sortieralgorithmus bastelt, gehört geohrfeigt.

Ähnlich bei Datenstrukturen: erst sollte man all die Datenstrukturen kennen die einem ohnehin schon zur Verfügung stehen. Wenn man darüber hinaus noch was braucht muss man sich halt wieder reinlesen, aber es wird hoffentlich niemand selber einen Stack, eine Linked List oder einen Hashtable schreiben.

Trap

2009-01-10, 14:21:24

Datenstrukturen und Algorithmen ist mehr als nur Sortieren. Mal ein Link zu einem Inhaltsverzeichnis eines Algorithmenbuch für Fortgeschrittene: http://www.aw-bc.com/info/kleinberg/assets/downloads/toc.pdf

Manches davon gibt es mittlerweile als Bibliothek, anderes muss man noch selber implementieren. Wobei das selbst implementieren nicht so tragisch ist, bei diesen Problemen braucht man meist den größten Teil der Zeit dafür das Problem zu verstehen, die richtige Lösungsstrategie zu finden und die Größen aus der Problemstellung richtig auf die Parameter des Algorithmus abzubilden.
Ich hab übrigens schon heaps und priority queues geschrieben, in den Sprach-Bibliotheken gibt es nämlich keine PQs die auf n-ary heaps, fibonacci heaps oder radix heaps basieren.

An anderen Bereichen halte ich Semantik, Programmverifikation und Berechenbarkeit noch für wichtig, aber das hängt vom Bereich ab den man bearbeitet. In der Programmentwicklung selbst ist es kaum eine konkrete Hilfe, es gibt einem aber etwas Gefühl dafür was der Code bedeutet, wie kompliziert er ist und auf welche Details man achten muss. Es gibt einem auch einen Hintergrund zu den Designregeln bei der Softwarearchitektur, die meisten lassen sich dann nämlich zusammenfassen als "schreibe Code der möglichst einfach zu beweisen ist".

Monger

2009-01-10, 14:50:48

Ich hab übrigens schon heaps und priority queues geschrieben, in den Sprach-Bibliotheken gibt es nämlich keine PQs die auf n-ary heaps, fibonacci heaps oder radix heaps basieren.

Ja, ich weiß. Wenn es z.B. um Bäume geht, sieht es auch in den Standard Frameworks ganz allgemein schwach aus.

Ich hab diesen Krams ja auch alles gelernt - und seitdem nie wieder verwendet, und mittlerweile wieder vergessen.

Algorithmentheorie ist etwas was man sich als fortgeschrittener Programmierer auf jeden Fall mal anschauen sollte. Schon alleine, um zu begreifen dass eine Datenstruktur nicht zwingend statisch modelliert sein muss, und um ein Gefühl dafür zu bekommen wie effizient ein Algorithmus überhaupt sein kann.

Aber wie gesagt: ich war bis heute nicht wirklich darauf angewiesen. Für einen Einsteiger gibt es da imho einen ganzen Stapel anderer Themen die wichtiger sind.

Trap

2009-01-10, 15:04:47

Sobald ein Projekt wächst (und damit die Anzahl der Codezeilen), würde ich am liebsten die ganze Zeit von vorne anfangen, weil ich die Architektur/Strukur meiner Programme nicht für "State-of-the-art" halte
Da gibt es einen klassischen Text zu: worse is better (http://www.jwz.org/doc/worse-is-better.html)

Es gibt sehr viel sehr erfolgreiche Software, die nicht besonders schön programmiert wurde.

Neu von vorne Anfangen ist ganz gut weil man dann neue Fehler machen kann und daraus was lernen kann. Wenn man aber eher an der Software als am Lerneffekt interessiert ist, ist ein extreme programming/test driven development Ansatz wohl geeigneter, ein kurze Beschreibung davon in Folien: http://www.telbit.pt/docs/12.pdf

Gast

2009-01-10, 15:30:21

Ähnlich bei Datenstrukturen: erst sollte man all die Datenstrukturen kennen die einem ohnehin schon zur Verfügung stehen. Wenn man darüber hinaus noch was braucht muss man sich halt wieder reinlesen, aber es wird hoffentlich niemand selber einen Stack, eine Linked List oder einen Hashtable schreiben.

Deine Antwort zeigt mir, daß du nie ein Informatikstudium begonnen hast.

Eigentlich sollte ich einen Beitrag der so anfängt einfach kommentarlos trashen, aber ich bin heute guter Laune.

Monger

Im Informatikstudium geht das mit den Grundlagen nämlich schon so weit, daß man auch die Grundlagenalgorithmen lernt um selbst schnelle Grafik zu verwenden ohne dabei Direct3d und OpenGL zu verwenden.
Das Argument ist, daß es auch noch später Leute geben soll, die neue Versionen von Direct3d oder OpenGL auch implementieren können.

Es sind also eher die APIs die unwichtig sind, die Grundlagen sind viel bedeutender.

Monger

2009-01-10, 15:53:59

Im Informatikstudium geht das mit den Grundlagen nämlich schon so weit, daß man auch die Grundlagenalgorithmen lernt um selbst schnelle Grafik zu verwenden ohne dabei Direct3d und OpenGL zu verwenden.

Wie zur Hölle kommst du hier auf Direct3D?
Selbstverständlich ist ein erstrebenswert, effiziente Algorithmen zu schreiben. Aber was genau ist dein Argument?

Es sind also eher die APIs die unwichtig sind, die Grundlagen sind viel bedeutender.
Richtig ist: Algorithmen sind zeitlos. Die meisten Algorithmen sind weit älter als die Informatik, und sie werden auch jeden Computer überleben.

Algorithmentheorie ist ein Thema der theoretischen Informatik, sprich: Mathematik. Das ist ein sehr, sehr spezieller Forschungsbereich. In der Praxis wird man je nach Themenfeld sicherlich über solche Probleme mal stolpern, aber ich bin mir ziemlich sicher dass die allermeisten Anwendungsentwickler damit nur alle Jubeljahre mal in Berührung kommen.

Trap

2009-01-10, 15:54:52

Aber wie gesagt: ich war bis heute nicht wirklich darauf angewiesen. Für einen Einsteiger gibt es da imho einen ganzen Stapel anderer Themen die wichtiger sind.
Ja, solche weitergehenden Algorithmensachen sind anwendungsspezifisches Informatikwissen wie auch GUI, Netzwerk oder Datenbanken.

Für interessante Softwareprojekte braucht man meist irgendein Anwendungswissen, da würde ich aber keins als wichtiger als andere einstufen.

Wenn man als Einsteiger eine Programmiersprache kann, bleiben als weiterführende Themen Programmiersprachen mit anderen Konzepten (wenn man Java/C# kann also z.B. Haskell oder Lisp), klassische theoretische Informatik für ein wirkliches Verständnis von Programmcode, anwendungsbezogenes Wissen und vor allem Übung.

Shink

2009-01-10, 19:43:43

Habt ihr auch wirklich alle gelesen was der TS eigentlich will? Für mich klingt das eher nach Bedenken bei Software Architektur als bei Algorithmen, Datenstrukturen, 3D-Bibliotheken oder der Sehnsucht nach anderen Programmierkonzepten ala Haskell.

Mich wundert ja dass noch niemand Assembler oder Brainfuck erwähnt hat.

Gast

2009-01-10, 20:24:50

http://norvig.com/21-days.html

ist doch witzlos die diskussion hier. programmieren lernt man durch uebung. das was der threaderoeffner vorhat ist voelliger schwachsinn.

programmieren hat nichts mit auswendig lernen zu tun. man lern durch fehler ergo muss er diese machen. programmieren ohne konkrete projekte ist fuer n arsch. wenn man sich aufgaben stellt verbessert man sich nach und nach. auch wenn er alle designmuster kennt so what dann weiss er noch immer nicht wie man sie anwendet. solche dinge wie ein verstaendnis bzgl softwaredesigns, aufbau und implementierung das ergibt sich nach und nach.

die zuvor erwaehnten grundlagen der informatik sind in meinen augen auch unablaesslich, da man ohne ein gewisses grundverstaendnis auch keinen schimmer hat was eigentlich wirklich passiert... und wie will man dann jemals gute programme schreiben.

am besten lernt er erstmal ein paar grundlagen. socket programmierung mit c etc. all der highlvl scheiss ohne wirkliches know how fuehrt doch zu nichts. dann kann er nett ein paar fensterlie programmieren und das wars. toll.

Gast

2009-01-10, 22:08:14

An den Gast über mir.

Deinem Text zufolge bist du so einer aus der alten Garde, der denkt, nur weil er sich durch die lowlevel Sachen gebissen hat um an Wissen zu kommen, es alle anderen auch tun müssen. Das erinnert mich an meinen letzten Deutschlehrer, bei dem mussten wir auch unzählige Texte auf altdeutsch lesen, nur weil man das vor 50 Jahren noch so gemacht hat.

Ich gebe dir recht - Übung und somit Trial and Error ist die beste und wertvollste Methodik, die es gibt.

Aber es ist doch völliger schwachsinn, sich z.B. Entwurfsmuster aus dem Finger zu ziehen, ohne mal irgendwas darüber gelesen zu haben, das funktioniert nie und nimmer.

auch wenn er alle designmuster kennt so what dann weiss er noch immer nicht wie man sie anwendet

Und? das waren auch erst die ersten 50% des Lernprozesses. Dein Part kommt jetzt, anwenden, anwenden, anwenden...
Erzähl du mir mal, wie du nur durch "Üben" an Know-how über Entwurfsmuster kommst. Glaubst du ja selbst nicht.

Der TS hat übrigens nirgends geschrieben, dass er das nicht so handhabt - im Gegenteil, schliesslich schreibt er ja von Projekten.
Hast du seinen Post überhaupt gelesen? Da steht klar und deutlich
Momentan denke ich eigentlich, dass wenn ich die Entwurfsmuster kapiert habe und anwenden kann...

Erst Theorie, dann Praxis mit gesundem Erforschungsgeist, oder beides vermischt. Alles andere ist Zeitverschwendung.

Weiter gehts.

die zuvor erwaehnten grundlagen der informatik sind in meinen augen auch unablaesslich, da man ohne ein gewisses grundverstaendnis auch keinen schimmer hat was eigentlich wirklich passiert... und wie will man dann jemals gute programme schreiben.
am besten lernt er erstmal ein paar grundlagen. socket programmierung mit c etc. all der highlvl scheiss ohne wirkliches know how fuehrt doch zu nichts. dann kann er nett ein paar fensterlie programmieren und das wars. toll.

Ja is klar. Was juckt es ihn, was im Hintergrund passiert, wenn er einen Chat geschrieben hat und dabei gelernt hat, die im Framework zur Verfügung stehenden Klassen effektiv zu nutzen. Dein Hintergrundwissen ist vielleicht ne nette Dreingabe, aber mit diesem Wissen wird man trotzdem keine Netzwerkspezifischen Klassen aus Java/C# selbst manuell neu implementieren.
Achja, mit dem relativ großen Umfang der Frameworks kann man übrigens noch tausend Dinge mehr, als nur Fensterlie programmieren - und das OHNE zu wissen, wie die genutze Klasse aussehen würde, wenn man sie selbst geschrieben hätte.

Gast

2009-01-11, 00:20:49

An den Gast über mir.

Deinem Text zufolge bist du so einer aus der alten Garde, der denkt, nur weil er sich durch die lowlevel Sachen gebissen hat um an Wissen zu kommen, es alle anderen auch tun müssen. Das erinnert mich an meinen letzten Deutschlehrer, bei dem mussten wir auch unzählige Texte auf altdeutsch lesen, nur weil man das vor 50 Jahren noch so gemacht hat.

Ich gebe dir recht - Übung und somit Trial and Error ist die beste und wertvollste Methodik, die es gibt.

Aber es ist doch völliger schwachsinn, sich z.B. Entwurfsmuster aus dem Finger zu ziehen, ohne mal irgendwas darüber gelesen zu haben, das funktioniert nie und nimmer.

Und? das waren auch erst die ersten 50% des Lernprozesses. Dein Part kommt jetzt, anwenden, anwenden, anwenden...
Erzähl du mir mal, wie du nur durch "Üben" an Know-how über Entwurfsmuster kommst. Glaubst du ja selbst nicht.

Der TS hat übrigens nirgends geschrieben, dass er das nicht so handhabt - im Gegenteil, schliesslich schreibt er ja von Projekten.
Hast du seinen Post überhaupt gelesen? Da steht klar und deutlich

Erst Theorie, dann Praxis mit gesundem Erforschungsgeist, oder beides vermischt. Alles andere ist Zeitverschwendung.

Weiter gehts.

Ja is klar. Was juckt es ihn, was im Hintergrund passiert, wenn er einen Chat geschrieben hat und dabei gelernt hat, die im Framework zur Verfügung stehenden Klassen effektiv zu nutzen. Dein Hintergrundwissen ist vielleicht ne nette Dreingabe, aber mit diesem Wissen wird man trotzdem keine Netzwerkspezifischen Klassen aus Java/C# selbst manuell neu implementieren.
Achja, mit dem relativ großen Umfang der Frameworks kann man übrigens noch tausend Dinge mehr, als nur Fensterlie programmieren - und das OHNE zu wissen, wie die genutze Klasse aussehen würde, wenn man sie selbst geschrieben hätte.

nun, in der praxis erlebe ich es jeden tag aufs neue, wie wichtig tiefgehendes wissen in verschiedenen bereichen der informatik ist um z.b. fehler ausfindig zu machen, das system zu verstehen mit dem man interagiert.
keine anwendung der welt steht nur so fuer sich im leeren raum. klar managed code sprachen gehen in die richtung, aber die realitaet sieht anderst aus.

und sicher, ich gebe dir voellig recht, klar muss man ueber die dinge bescheid wissen um sie anzuwenden. aber mal im ernst designmuster sind nicht alles. die ergeben sich von selbst, wenn man gute konepte fuer das ziel das man vor augen hat erarbeitet. klar ist es gut eine factory klasse, signleton etc zu verwenden, aber programmieren ist so viel mehr.

auch gibt es in meinen augen nicht DAS fundament an wissen, das man drauf haben muss. man muss grundlegendes verstanden haben. alles andere kann man schnell mal nachschlagen.

programmieren geht nicht mal eben so, auch wenn das viele gern so haetten. damit man ein guter programmierer wird, bedarf es viele jahre. das hat nichts mit mir und meinem werdegang zu tun, das ist einfach fakt. wer das nicht wahrhaben will, der kann sich evtl seinen eigenen schwaechen nicht eingestehen.

Monger

2009-01-11, 02:07:14

und sicher, ich gebe dir voellig recht, klar muss man ueber die dinge bescheid wissen um sie anzuwenden. aber mal im ernst designmuster sind nicht alles. die ergeben sich von selbst, wenn man gute konepte fuer das ziel das man vor augen hat erarbeitet.
Das Problem imho ist, dass es beim Programmieren ab einem gewissen Grad ganz selten Sackgassen gibt.
Sobald man mal den Kern einer Sprache verstanden hat, kann man grundsätzlich alles programmieren - nur mit sehr, sehr variierendem Aufwand.

Vorallem Anfänger sind oftmals erstaunlich schmerzresistent. Da werden luftige, aufgeblasene und unglaublich wacklige Lösungen entwickelt, einfach weil sie keine Ahnung haben was für äußerst mächtige und vielseitige Konzepte existieren.
Klassisches Beispiel: ich sehe es bei Anfängern ganz häufig, dass sie so ziemlich alles in Arrays verwalten. Wenn sie eine Zuordnung von Schlüssel zu Wert brauchen, machen sie halt zwei Arrays, und implementieren sich selbst mühsam irgendwas um die Werte konsistent zu halten. Wenn sie ein erweiterbares Array brauchen, führen sie irgendwelche Zähler ein, und kopieren ständig die Arrays hin und her...
Nicht wissend, dass es für all das schon fertige Lösungen gibt, die weit flexibler und fixer laufen als man es selbst auch nach jahrelanger Frickelei hinkriegen würde.
Reguläre Ausdrücke sind auch so ein Beispiel, wo man sich entweder auf unglaublich schmerzhafte Weise per String Splitterei sich den richtigen Wert rausfummeln kann, oder eben mal einige Zeit ins Studium von entsprechenden Webseiten investiert, und danach das ganze mit einem Einzeiler erschlägt.

Das löst sich auch nicht zwingend durch Erfahrung. Ich kenn Leute die auch nach 20 Jahren Berufserfahrung immer noch den selben Spaghetti Code produzieren. Ich vermute, weil ihnen das "Schmerzempfinden" fehlt was ihnen irgendwann mal sagen müsste, dass wahrscheinlich eine kurze Recherche ihnen unglaublich viel Arbeit ersparen müsste.

Diese Hemmschwelle sinkt imho beträchtlich, wenn man sich erstmal in solche Konzepte reingekniet hat. Ich weiß noch dass ich während des Studiums ziemlich gekämpft habe, bis eine Kollegin mir gezeigt hat wie ich die Java JDK API in Eclipse einbinde, und mich darin auch zurecht finde. Danach war das alles VIEL leichter! ;-)

Gast

2009-01-11, 02:28:12

Das Problem imho ist, dass es beim Programmieren ab einem gewissen Grad ganz selten Sackgassen gibt.
Sobald man mal den Kern einer Sprache verstanden hat, kann man grundsätzlich alles programmieren - nur mit sehr, sehr variierendem Aufwand.

Vorallem Anfänger sind oftmals erstaunlich schmerzresistent. Da werden luftige, aufgeblasene und unglaublich wacklige Lösungen entwickelt, einfach weil sie keine Ahnung haben was für äußerst mächtige und vielseitige Konzepte existieren.
Klassisches Beispiel: ich sehe es bei Anfängern ganz häufig, dass sie so ziemlich alles in Arrays verwalten. Wenn sie eine Zuordnung von Schlüssel zu Wert brauchen, machen sie halt zwei Arrays, und implementieren sich selbst mühsam irgendwas um die Werte konsistent zu halten. Wenn sie ein erweiterbares Array brauchen, führen sie irgendwelche Zähler ein, und kopieren ständig die Arrays hin und her...
Nicht wissend, dass es für all das schon fertige Lösungen gibt, die weit flexibler und fixer laufen als man es selbst auch nach jahrelanger Frickelei hinkriegen würde.
Reguläre Ausdrücke sind auch so ein Beispiel, wo man sich entweder auf unglaublich schmerzhafte Weise per String Splitterei sich den richtigen Wert rausfummeln kann, oder eben mal einige Zeit ins Studium von entsprechenden Webseiten investiert, und danach das ganze mit einem Einzeiler erschlägt.

Das löst sich auch nicht zwingend durch Erfahrung. Ich kenn Leute die auch nach 20 Jahren Berufserfahrung immer noch den selben Spaghetti Code produzieren. Ich vermute, weil ihnen das "Schmerzempfinden" fehlt was ihnen irgendwann mal sagen müsste, dass wahrscheinlich eine kurze Recherche ihnen unglaublich viel Arbeit ersparen müsste.

Diese Hemmschwelle sinkt imho beträchtlich, wenn man sich erstmal in solche Konzepte reingekniet hat. Ich weiß noch dass ich während des Studiums ziemlich gekämpft habe, bis eine Kollegin mir gezeigt hat wie ich die Java JDK API in Eclipse einbinde, und mich darin auch zurecht finde. Danach war das alles VIEL leichter! ;-)

nun, dass man die grundlegenden sprachelemente der sprache der wahl beherrschen sollte, darum ging es hier doch gar nicht mehr. deswegen sehe ich fuer meine aussagen, auf die du dich beziehst, keinen zusammenhang mit deiner argumentation.

und was meinst du mit einbinden der standard java bibs/api or whatever. sobald man in eclipse oder netbeans ein java projekt erstellt, ist diese automatisch mit eingebunden...

abschliessend will ich meine meinung wie folgt festhalten: es macht keinen sinn wie wild dinge zu lernen, die man nicht anwendet. es ist wichtig ein wirkliches ziel vor augen zu haben, welches man erreichen will ( softwareprojekt ) dann lernt man das, was noetig ist um dieses ziel zu erreichen. wenn man scheiss code schreibt merkt man das evtl. selbst mit der zeit, weil man nach und nach intuitiver mit den elementen einer sprache umgeht und es einem somit leichter faellt die dinge zu abstrahieren und zusammenhaenge zu erkenen ergo arichtekturen von elementen zu erstellen. beschleunigt wird dieser prozess natuerlich durch codereview mit erfahrenen kollegen, freunden, die einem eventuelle fehler im design oder andere herangehensweisen aufzeigen koennen.

das ist sicher keine absolute wahrheit, aber wohl die regel.

Yavion

2009-01-11, 20:51:10

Kenntnisse über Entwurfsmuster und Entwicklungsprozesse halte ich heutzutage schon für wichtig, wenn man sich mit OO-Sprachen auseinandersetzt. Die gehören zum Handwerkszeug genau so dazu, wie diverse UML-Diagramme.

Ich würde mich auch mit Dingen wie "Test driven Developement" auseinandersetzen und dem entsprechend den Einsaz z.B. von JUnit-Tests praktizieren.
Kenntnisse über den Entwicklungsprozess von Softwaresystemen oder DBS sind auch wichtig und werden bei Programmierhandbüchern häufig ausgeklammert, helfen einen aber zum einen selbst aber auch anderen, weil man sich ggf schneller in ein Projekt integrieren kann.

Ich würde zum Basiswissen einfach eine gewisse Routine bei Entwurf und Implementieren zählen, sowie Kenntnisse über theoretische Grundlagen über immer wieder vorkommende Datenstrukturen (z.B. Lists, trees, maps, hashing). Alles was einen hilft, sein Wissen schnell in einen bestimmten Bereich hinein zu erweitern.

Tiamat

2009-01-12, 00:06:52

Hi,
also ich befinde mich grad in der Endphase des 2. Semesters Informatik.
Was mich im Vergleich zum ersten Semester besser gemacht hat, ist auf jeden Fall, dass ich die Objektorientierung besser zu nutzen weiß.
Je größer die Projekte werden, desto wichtiger ist eine gewisse Struktur, die es einem leicht macht, die Übersicht zu bewahren und auch Änderungen vorzunehmen oder den Code gar zu erweitern, ohne sich einen abbrechen zu müssen.

So was schafft man mit der Methode einfachLoslegen(boolean ohneUeberlegung) auf keinen Fall :biggrin:
Je mehr Klassen und Objekte miteinander interagieren, desto mehr Gedanken muss man sich um die Beziehungen der Klassen und Objekte zueinander machen, sonst endet das ganze schnell in Frickelware.

Also ich denke echt, dass du den meisten Nutzen draus ziehen kannst, wenn du dich mal mit Objektorientierter Analyse und Objektorientiertem Design auseinandersetzt.
Das sind quasi die Phasen des Software-Entwurfs, die vor der Programmierung stattfinden. Hierbei plant man praktisch sein Vorhaben Schritt für Schritt.
Je besser und feiner man hier modelliert wird, desto problemloser geht dann die Programmierung von statten. Die Übersicht über alle präsente Klassen wächst automatisch, weil man sich um das Design ja schon vorher die Rübe zerbrochen hat.

Genau für diesen Zweck wurde die UML entworfen. Das hat auch den Vorteil, dass du aus diesem Wissen dann in jeder dir bekannten Objektorrientieren Programmiersprache davon profitieren kannst.

Also ich kenne da ne gute Buchreihe, die sag ich mal leichte Kost, und vom Unterhaltungsgrad wirklich toll ist. Dafür nicht ganz billig, vielleicht kannst du dir´s ja in der Bibliothek ausleihen.
Amazon (http://www.amazon.de/Objektorientierte-Analyse-Design-von-Kopf/dp/3897214954/ref=sr_1_1?ie=UTF8&s=books&qid=1231714636&sr=8-1)

Gruß
Tiamat

Abraxus

2009-01-12, 00:56:57

The_Invisible

2009-01-12, 13:51:40

ich zeichne vor einem projekt gerne alles auf ein blatt papier auf (ja, sowas gibt es wirklich noch ;)) und gehe es mit kollegen durch. meistens kommt zwar eh nur "ja, ja, wird schon passen" aber da kann man leicht fehler korrigieren bzw welche finden.

bisher hat es immer sehr gut geklappt, zumindest so gut das man mitten im projekt nicht auf einmal ganze klassen hat umbauen müssen.

wenn der code so 100.000 zeilen hat siehts natürlich wieder anders aus.

mfg

SentinelBorg

2009-01-14, 10:12:01

Papier ist immer gut und wichtig. Selbst bei 100k Zeilen Code. Dann gibts halt nur Teilstücke auf dem Papier oder Board.

Generell lernt man bei der Arbeit immer dazu. Erst letzte Woche habe ich z.B. Bekanntschaft mit der "Shared Sub New" in VB.net gemacht, die war mir bis dahin nicht bekannt. :)

Ganon

2009-01-14, 11:25:47

Diese "Heads First" bzw. "Von Kopf bis Fuß" Reihe finde ich nicht so prickelnd. Kauf dir lieber Bücher von Leuten die von der Materie Ahnung haben. Zumal man diese Buchreihe nicht als Nachschlagewerk benutzen kann, die liest man wenn überhaupt nur einmal und dann nie wieder.

Das was du bemängelst, steht im Buch auf den ersten Seiten dieser Bücher als Hinweis. ;)

Ich hab von denen den Teil mit den Entwurtsmustern und dort steht direkt drinnen, dass dieses Buch kein Nachschlagewerk ist und man sich für so etwas andere Bücher holen soll (wird auch eines empfohlen, ist mir aber entfallen wie es heißt)

Die "Von Kopf bis Fuß" Reihe ist eher dazu da auf interessante Lernweise an das Thema heranzuführen und diese auch zu behalten. Und es funktioniert auch besterns. Was ich in "Hibernate in Action" oder "Die C++ Programmiersprache" gelesen habe, weiß ich so gut wie gar nicht mehr, aber ich kann dir aus dem Kopf noch eine grobe Inhaltsangabe vom "Von Kopf bis Fuß" Buch geben, samt Beispielen ;)