Was versteht Ihr unter programmieren?

[Gurki]

Moin Moin,

ich wollte gerne mal wissen was Ihr unter programmieren versteht. Also es wird ja immer gesagt man soll "Programmieren" lernen, alles andere ist Syntax. Was versteht Ihr darunter? Lernen wie Schleifen funktionieren? Was Strings und Integer sind? Wie lerne ich am bessten "Code zu lesen" ?

Ich dachte immer man muss eine Sprache (hier z.b. VB.Net) perfekt auswendig können um wirklich gut programmieren zu können. Aber scheinbar ist programmieren - Codeschnippsel aus dem Internet suchen anpassen und zusammen führen... Ist das so korrekt? Ein Freund sagte mir das das programmieren sei. Man kann keine Programmiersprache perfekt beherrschen und die Syntax kompeltt auswendig kennern, man muss imemr mal googeln und die Hilfe nutzen. Also bin / war ich immer in einer "Traumwelt"???

P.S.: Lerne Anwendungsentwickler

[Industrial_Engineer]

Es gibt einmal das Programmieren und dann das Software-Entwickeln.

Programmieren ist das verwenden von einer Programmiersprache, deren Befehle verwendet in der zugehörigen Syntax, für die Umsetzung von Algorithmen in ein zu realisierendes Programm.

Software-Entwicklung kann ganz ohne Programmieren stattfinden, z. B. mit Datanbankmodelle, UML oder Pseudocode. Es wird die Software-Architektur beschrieben.

In der Praxis fällt aber beides zusammen. Ich kenne keinen einzigen Software-Entwickler, der nicht beides macht. Auch die Ausbildung zum Fachinformatiker mit Schwerpunkt Anwendungsentwicklung ist recht eindeutig auf beides eingestellt.

Mich persönlich (ich bin ausgebildeter FI/AE und studierter Wirtschaftsingenieur) stört es auch, dass z. B. studierte Wirtschaftsinformatiker die Fachinformatiker immer als Programmierer deklarien und damit explizit herunterstufen möchten.

[flashpixx]

Ich dachte immer man muss eine Sprache (hier z.b. VB.Net) perfekt auswendig können um wirklich gut programmieren zu können. Aber scheinbar ist programmieren - Codeschnippsel aus dem Internet suchen anpassen und zusammen führen... Ist das so korrekt? Ein Freund sagte mir das das programmieren sei.

Das ist ein völliger Trugschluss. Ich würde es so verstehen "Programmieren heißt mit Hilfe einer Sprache ein Problem lösen", d.h. konkret, dass ich einmal abstrakt das Problem erkenne und dann in Teilprobleme zerlege. Diesen Schritt wiederhole ich so lange, bis jedes Teilproblem einer Befehlsstruktur der Sprache entspricht. Das ganze würde ich etwa wie das Optimalitätsprinzip von Bellman sehen. D.h. Je besser Du die Sprache kannst, um so besser findest Du eines passende Befehle für Deine Teilprobleme. Aber so einfach ist das nicht, denn die Problemlösung liegt eben nicht nur an Befehlen, denn gerade wenn man in den parallele Verarbeitung (Multithread / Multicore / Clustering) geht, dann ist eben auch die Nebenläufigkeit im Kopf zu haben.

Gute Informatiker, sowohl studiert, wie ausgebildet, können beides. Sie können sowohl abstrakt das Problem im Kopf lösen, wie auch dann praktisch in Quellcode formulieren.

[lilith2k3]

Ich gebe jetzt einmal eine paradox anmutende Antwort: Programmieren hat überhaupt nichts mit Programmiersprachen zu tun, oder besser: Programmieren ist unabhängig von der konkreten Programmiersprache. Das mag Dich einerseits erstaunen; aber ich will versuchen zu erklären, was ich damit meine:

Natürlich steht zu Beginn der Programmierer-Karriere, das eigentliche Erlernen einer Programmiersprache. Bei dem einen ist es Java, bei dem anderen ist es VB-Net. Wieder andere (wie ich) haben mit "Basic" auf dem ZX81 ihre ersten Programmier-Erfahrungen gemacht. Grundsätzlich geht es beim "Programmieren" darum, sich dem Computer verständlich zu machen. Grundsätzlich aber nicht wesentlich. Und das ist der wichtige Schritt hin zum richtigen Programmierer. Du schreibst als Programmierer nicht nur Code, der dem Computer erklärt, was Du wie gemeint hast: also lediglich Programme, die funktionieren, sondern Du schreibst auch handwerklich gute Programme.

Was sind handwerklich gute Programme?

Zum einen sind es Programme, deren Code aufgeräumt ist. Aufgeräumt ist Code, der sich gewissen Design-Prinzipien unterwirft ( Prinzipien Objektorientierten Designs ) - zumindest ist das in objekt-orientierten Sprachen so. Für andere Sprachen gelten natürlich andere Spielregeln, die denen aber nicht unähnlich sind ( Strukturierte Programmierung vgl. Dijkstra). Im Grunde kann man all diese Prinzipien herunterbrechen auf die Faustregeln:

Halte alle Funktionen einfach, wiederhole Dich nicht selbst und versuche mit einigen wenigen klugen Abstraktionen eine möglichst hohe Zahl an Anwendungsfällen abzudecken.

Desweiteren ist lesbarer Code ein handwerklich guter Code.

Dazu ist es notwendig das Vokabular eines Programmierers zu erlernen("Factory", "Abstract Factory", "Builder", "Adapter", "Proxy" etc. ktl.); darüberhinaus aber auch das Vokabular des Fachbereichs zu Sprechen, für den das Produkt nachher eingesetzt werden soll. In einem Programm zum Thema Buchhaltung wäre es nicht falsch von "Buchen", "Konto", "Soll", "Haben", "Buchungssatz" etc. zu sprechen.

Variablen und Funktionen werden mit Bedacht benannt und nicht nach Lust und Laune ("KontoFactory" statt "KtoFac").

Die Zeiten von Fortran, wo man nur 6 Alphanumerische Zeichen hintereinander schreiben durfte sind vorbei. Heute werden auch komplexere Benennungen von den IDEs verstanden.

Darüberhinaus zeichnet es einen Programmierer aus, wenn er die Sprache seines Kunden versteht und optimaler Weise auch selbst sprechen kann. Ein guter Programmierer kann sich in andere Abläufe gut eindenken und besitzt die Fähigkeit, diese Abläufe zu abstrahieren, abstrakt zu formulieren und diese Formulierung letzten Endes in Code zu gießen. Nur wer versteht, worum es bei einem Problem geht, ist auch in der Lage es korrekt zu lösen.

Darüberhinaus besitzt ein Programmierer soviel Fachverstand, dass er in der Lage ist, nicht nur ein Problem "lediglich" zu lösen, sondern ggf. seinen gewälten Lösungsweg zu verbessern.

Das sind alles -und längst nicht alle- Aspekte, die einen guten Programmierer oder eben "Programmieren" ausmachen, die zunächst überhaupt nichts mit dem eigentlichen "tippen" der Codezeilen zu tun haben.

Selbstredend ist es wichtig, dass ein Programmierer die Programmiersprache seiner Wahl so umfassend wie möglich versteht und stets bestrebt ist, sich auf seinem Fachgebiet weiterzuentwickeln - oder gehst Du zu einem Arzt, der Dir offen sagt, er habe 10 Jahre Berufserfahrung, aber sich seit 10 Jahren auch nicht mehr weitergebildet? Wohl kaum. Als sorgfältiger Programmierer sollte man stets bestrebt sein, sich mit den neuesten Techniken und Trends seiner Sparte auseinanderzusetzen.

Nur so kann man es vermeiden, Funktionalitäten, die ggf. schon mit dem benutzten Framework abgedeckt werden, noch einmal mühselig neu zu programmieren. Natürlich lässt es sich bei heutigen Frameworks nicht vermeiden, dass man das eine oder andere, die eine oder andere Klasse noch nihct benutzt hat, oder nicht einmal von Ihrer Existenz gehört hat. Ich komme aus der .NET Welt und kann Dir sagen, dass dieses Framework einfach unglaublich vielseitig und mächtig ist, und es nicht so ohne weiteres überschaubar ist. Regelmäßig kommen Neuerungen hinzu. Allerdings gehört es für mein berufliches Selbstverständnis dazu, mich freiwillig neben der Arbeit intensiv weiterzubilden.

Codeschnipsel aus dem Internet zusammenpasten ist zwar auch eine Art des Programmierens, aber das hat, wie Du aus dem Gesagten erschließen kannst nur grundlegend etwas mit Programmieren zu tun. Der eigentliche Programmier beginnt anschließend den kopierten Code zu verstehen, anzupassen, zu abstrahieren umzuformen, zu verallgemeinern und solange damit zu arbeiten, bis aus dem Schnipsel etwas geworden ist, was in sein Repertoire übergehen kann.

Außerdem zähle ich zum Programmieren, das Verwenden essentiell wichtiger Werkzeuge:

1) Source-Code-Verwaltung

2) Test-Frameworks

3) Mocking-Frameworks

beides je nach Vorhandensein

4) Integration Server

5) Code Coverage

etc.

Nur Code, der durch ausreichend Tests definiert werden kann, ist guter Code.

Angenommen die Platte auf der Dein Programmcode gelegen hat, ist kaputt gegangen: Bist Du in der Lage ausschließlich anhand Deiner Tests, die Funktionalität des Programms ohne den eigentlichen Code zu rekonstruieren? Wenn ja, hast Du Tests, die etwas taugen. Wenn nein, kannst Du sowohl die Tests, wie auch Dein Programm in die Tonne treten. Ein Programm, von dem Du nicht einmal mit Sicherheit sagen kannst, dass es die Aufgaben, die es erfüllen soll, auch erfüllt, taugt nicht.

Wie Du siehst, ist -für mich- Programmieren mehr als "nur" Programmieren.

[127.0.0.1]

Cadet

[el_pollo_diablo]

Da diese Frage immer mal wieder auftaucht, wäre es vielleicht ganz gut, wenn man die sehr gute Antwort von lilith2k3 irgendwo gut sichtbar anpinnen könnte.

[Gurki]

Danke für die erklärenden Worte!!!