Muss man kreativ sein, um programmieren zu können?

6 Antworten

(...) aber wenn ich selbst etwas schreiben will, weiß ich nicht, wie ich anfange oder was ich in welche Funktion reinschreibe (...)

Gerade das wäre eigentlich der wesentliche Kern, welcher die Tätigkeit des Programmierens erst beschreibt: Lösungswege zu einem Problem zu finden.

Um Lösungen zu Problemen zu finden, braucht es öfter auch etwas Kreativität, ja. Das ist soweit trotzdem nichts Unerreichbares und durch das strikte analysieren sowie Herunterbrechen in einfacher lösbare Subprobleme kommt man schon auf einen guten Weg.

Ich versuche immer alles in einer Klasse zu erledigen (...)

Ob man das als gut oder schlecht bewerten kann, ist fallbedingt. So einige Lösungswege kann man einfach halten, weshalb dann auch eine Klasse genügt.

Ein Zeichen, wann eine Klasse besser aufgeteilt werden sollte, macht sich durch die Menge an Code in ihr bemerkbar. Bei einer Recherche wirst du sicherlich auf verschiedene Richtwerte stoßen, die sich bspw. auf die Maximalanzahl an Codezeilen je Klasse richtet oder die Maximalanzahl an Methoden. Ich bin der Meinung, dass man das beim selbst drüberschauen bereits selbst merken sollte.

Kann man lernen, wie man ein Programm aufbaut?

Der Themenbereich dazu kann grob als Softwareentwicklung bezeichnet werden, auch wenn er noch ein paar weitere Themen umfasst (z.B. die Rollenverteilung von Entwicklern in Projekten, Testverfahren, etc.).

Für dein geschildertes Problem musst du dich aber noch nicht direkt in dieses Feld stürzen. Ich würde dir dazu raten, schrittweises Denken mehr zu üben. Dem Computer muss immerhin jeder Arbeitsschritt genau vorgegeben werden. Diese Art kleinteiligen Denkens ist für uns Menschen in der Regel eher ungewohnt, daher fällt es gerade Anfängern meist schwer, in das freie Programmieren hineinzufinden.

Ein erster wichtiger Schritt wäre, wie schon oben geschrieben, eine Analyse. Jedes Programm soll irgendein Problem lösen. Sei es die Berechnung einer Summe, das Erreichen des Weltfriedens oder die Automatisierung eines Produktionsprozesses.

In jedem Fall ist es notwendig, das vorliegende Problem zu erfassen und zu verstehen. Viele Probleme sind komplex und nicht leicht in einem Satz beschreibbar, weil sie bspw. aus einem Problembündel bestehen / verschiedene Anfordungen stellen. All diese Anforderungen müssen zunächst herausgearbeitet werden.

Im nächsten Schritt kann man damit beginnen, das Problem bzw. die schon herausgefundenen Anforderungen zu zerlegen. Am Beispiel eines Taschenrechners verdeutlicht würde man feststellen, dass dieser mindestens die Grundrechenarten beherrschen sollte und dafür müsste man wissen, wie man diese jeweils berechnet. Sollte man an dieser Stelle feststellen, das ein gebildetes Subproblem immer noch zu komplex ist, zerlegt man es besser noch weiter.

Ziel wäre es, eine Liste an Subproblemen zu erhalten, die jeweils als einfach lösbar erscheinen (d.h. man kann sie mit den Grundbausteinen einer Programmiersprache - Variablen, Kontrollstrukturen, Operatoren oder bereits vorhandenen Funktionen lösen). Man könnte es mit der Planung einer Hochzeitsfeier vergleichen. Für die Hochzeit braucht man eine Hochzeitstorte, Gäste, einen Partysaal, usw.. All diese Anforderungen / Subprobleme lassen sich erneut unterteilen: Jeder Gast benötigt eine Einladung (die muss wiederum erst erstellt werden), den Partysaal muss man erst mieten, usw..

Die Lösungen wiederum bilden zusammengesetzt Algorithmen (Lösungsanleitungen), die die einzelnen Probleme lösen können.

Ganz nützliche Tools für diesen Analysevorgang sind grundsätzlich Skizzen oder UML-Diagramme. Für die Beschreibung von Aktionen wären vor allem Programmablaufpläne oder Struktogramme hilfreich. Bei Problemlösungen mit Hilfe der OOP ist es für den Start hilfreich, das Programm in einfachen Sätzen zu beschreiben und anschließend Subjekte (= Objekte) sowie Verben (= Methoden) herauszulösen. Weitere Übersichten bieten dann Objekt- und Klassendiagramme.

Was du nicht machen solltest, wäre die Lösungssuche direkt mit einer Programmiersprache selbst à la Code-einfach-mal-so-herunterschreiben. Du machst es dir (gerade als Programmieranfänger) sonst nur schwerer als nötig, schränkst dich im Denken womöglich ein und baust mit großer Wahrscheinlichkeit schneller logische Fehler ein, als bei einer Vorplanung.

Gibt es eine Seite mit Projekten zum Üben, wo man am Ende nicht nur einen Lösungscode hat, sondern ein ausführbares Programm?

Du kannst auf Edabit oder Excercism nach Herausforderungen suchen.

Klassische Übungsaufgaben, zu denen ich dir auf jeden Fall raten würde:

  • String-Methoden wie contains, endsWith, indexOf, join, lastIndexOf, substring oder replace selbst implementieren
  • Sortieralgorithmen wie Bubblesort, Insertionsort, Selectionsort oder Quicksort selbst implementieren (schau zu jedem auf Wikipedia, nutze lediglich die Beschreibungen und Bildanimationen)
  • Datenstrukturen selbst implementieren: Eine doppelt verkettete Liste, eine zirkuläre Liste, einen Stack, einen AVL-Baum
  • Minispiele wie Tetris, Snake oder Conways Game Of Life (da JavaScript in den Tags erwähnt wird, würde sich p5.js bei der Umsetzung als Hilfsmittel gut eignen)

Für die letzten beiden Stichpunkte kannst du die OOP gut mit hineinziehen.

Natürlich gehört zum guten Programmieren gewisse Kreativität.

Sehr viel in ein und derselben Klasse zu erledigen, muss aber nicht notwendig schlecht sein. In eigene Klassen auslagern (wenn die Applikation eher klein ist) sollte man i.W. nur Funktionalität, die auch für andere Anwendungen nützlich sein könnte.

Klassen mit jeweils nur extrem wenig Funktionalität zu bauen kann durchaus kontraproduktiv sein, denn: Unnötige Modularisierung erzeugt unnötige Komplexität.

Faustregel: Zu wenig Modularisierung liegt mindestens dann vor, wenn ein und dieselbe Idee mehrfach durch deinen Code implementiert wurde.

Ein bisschen, ja.

Wenn du eine Programmiersprache gelernt hast, kannst du noch keine Software entwickeln. Software zu entwickeln musst du auch noch lernen. Du brauchst Hintergrundwissen, musst Design Patterns kennen, einen Prozess zur Problemlösung entwickeln usw..

Der Beruf des Programmierers ist bereits vor Jahrzehnten ausgestorben. Heutzutage stellen Unternehmen Software Entwickler ein, von denen sie erwarten Software zu Entwickeln, und dann auch zu Programmieren. Programmieren ist nur die Tätigkeit eine (bereits entwickelte) Software in den Computer zu übertragen. Früher in den Anfangszeiten der Computer war programmieren noch aufwendig genug dass man dafür eigene Leute eingestellt hat. Da waren die Leute die das Programm entwickelt haben, und sie Leute die es in den PC übertragen haben, unterschiedliche Leute. Heutzutage ist es nurnoch eine Person.

Als "Codeäffchen" (Algorithmen in Programme umsetzen und eintippen) braucht man nicht kreativ zu sein. Das ist ja auch die Stelle, wo immer neue Hilfsmittel in die Entwicklungsumgebungen eingebaut werden. (M. E. ca. 2 bis 3 Jahrzehnte hinter dem Stand der Technik hinterherhinkend.)

Als "Software-Entwickler" (Algorithmen entwickeln und dabei womöglich die Besonderheiten und Marotten der jeweiligen Programmierumgebung - Sprache, Bibliotheken, ... - zu berücksichtigen, muss man sehr wohl kreativ sein. Allein deshalb, weil es fast immer Dutzende bis Hunderte von Möglichkeiten gibt, ein Problem zu lösen. Ganz zu schweigen davon, dass man es nur sehr selten mit einem "Problem" (exakt umrissen, mathematisch genau beschrieben) zu tun hat, sondern mit einer ungefähren Problembeschreibung.

Für deine konkrete Frage würde ich einen Kurs mit einem Dozenten, den man in Echtzeit kontaktieren kann, empfehlen. ("Klassenraum" oder Online-Konferenz)

Woher ich das weiß:Berufserfahrung – Software-Entwickler

Vergleiche ein Programmiersprache mit einer Schreibmaschine oder Collegeblock mit Stift. Damit Wörter eintippen können heißt noch nicht, dass du damit auch einen Bestseller-Roman schreiben kannst.

Beim Programmieren geht es nicht nur die Bedienung des Werkzeugs, sondern auch um die Phantasie und das Vorstellungsvermögen, sich das, was mittels Benutzung dieses Werkzeuges realisiert werden soll, zurechtzudenken. Ähnlich wie der Autor eines Romans sich die Handlung seines noch einzutippenden Buches zurechtlegen, und diese Handlung dann auch noch entsprechend formulieren und in Worte packen muss.

Erst dann kommt es zum Prozess des Codens, um den Compiler der gewählten Sprache damit zu füttern.

Wenn du vor dem Compiler sitzt, und nicht weißt, wo du anfangen musst, hast du einfach am falschen Ende angefangen: Wisse erst, was du schreiben willst, werde dir dann klar, wie du das schreiben willst. Erst dann schreibe es.

Und wenn du dann verstanden hast, was du eigentlich schreiben wolltest, dann schreib das ganze nochmal.