Wie werde ich ein besserer Programmierer?
Ich bin noch am studieren und beherrsche nun C# zum grösstem Teil, jedoch fällt es mir schwer große bzw. komplexe Projekte strukturiert/organisiert zu entwickeln. Ich denke ich habe noch Schwierigkeiten beim Design der Klassen. Daher dachte ich mir, lerne ich mal das Thema "Design Patterns". Kennt ihr irgendwelche Tipps, die euer Programmier-Leben verändert hat oder die man einfach wissen muss?
7 Antworten
Wow, erstmal Röschpeckt für die gute Frage! Dir ist vielleicht gar nicht klar, WIE gut die eigentlich ist! Das ist das erste mal, dass ich hier auf GF eine Frage in dieser Form lesen darf. Aus dir wird sicher mal etwas werden!
So, genug geschleimt ... Ich werde dir jetzt mal ein paar Stichwörter nennen, von denen viele Punkte ganze Bücherregale füllen. Lies dir zu allen genannten Punkten unbedingt mindestens die Wikipedia-Artikel und ggf. entspr. Verlinkungen am Ende durch. Besorge dir evtl. Bücher zu den Themen, die du für besonders wichtig erachtest.
Also dann ... hier ist eine unsortierte Liste, von wirr zusammen gewürfelten Dingen, die man von einem wirklich erfahrenen Software-Entwickler erwarten können sollen dürfte (gängige Fachbegriffe in Englisch, falls üblich; nicht alle Punkte betreffen dich gleich stark; unterschätze die Wichtigkeit trotzdem nicht!):
- Portabilität und Plattformunabhängigkeit
- Exception-Safe Programming
- Defensive Programmierung & Sicherheit
- Bindings / Linkage für weitere Sprachen (C++ > C, C# > VB.net)
- Soft-Skills
- Versionskontrolle (git, Visual Source Safe, Subversion, Mercurial, ...)
- Testing (Mocks, Stubs, Spies; Unit, Regression, User, ...)
- Code-Coverage (Test-Abdeckung)
- Code Reviews (und entfernt Pair-Programming)
- Internationalization und Co (i18n, g11n, l10n, l12y)
- Accessibility (a11y)
- Statische Code Analyse (mit entspr. Werkzeugen)
- Schnittstellen für Menschen UND Maschinen
- Reversing (Optimierung eigenen Codes; Prüfung von Dritt-Libs)
- Ressourcen-Management
- Logging
- Profiling
- Fuzzing
- Metriken
- Tracker (Bugs, Issues, Features, usw.)
- Linking (statisch, dynamisch; Kompilierzeit, Laufzeit)
- Dokumentation
- Konvenstionen & Spezifikationen
- Code-Smells
- Design-Patterns & Anti-Patterns
- Versionierungs-Schema
- Backup & Recovery
- Debugging
- Projektmanagement
- Agiles Zeug (Scrum, XP, ...)
- Tool-Wissen (insbesondere Kommandozeile und Shells)
- Auffinden von Speicher- und Ressourcen-Lecks
- Domain Specific Programming (insbes. DSLs)
- autom. Build-, Test-, Packaging- und Distribution-System
- Patching (Source und Binary)
- Software-Lizenzen
Wie gesagt, eine ausführlichere Beschreibung würde jeden Rahmen sprengen ... informiere dich also bitte selbst zu den oben genannten Themen. Mir fallen noch viel viel mehr Stichpunkte ein, aber ich will hier auch nicht übertreiben.
Außerdem solltest du gleich noch mindestens 5 verschiedene weitere Programmiersprachen lernen, einfach um mal über den Tellerrand zu schauen. Das wird dir dann auch bei C# weiter helfen. In deinem Falle würde ich dir Folgende empfehlen: C++, Bash, Erlang, Python, Scheme, JavaScript
All genannten Sprachen habe ich bewusst gewählt, denn sie bieten Konzepte, die es so in C# nicht gibt und eine völlig andere Denkweise erfordern. (Mit Ausnahme von Erlang und besonders Scheme sind die anderen sogar alltagstauglich!)
Wenn du mit dem ganzen Kram durch bist, sind bestimmt einige Jahre vergangen, da man sehr viel Zeit investieren muss. Allein eine Programmiersprache ist viel mehr als nur Syntax, und das Verinnerlichen braucht nun mal seine Zeit.
Darüber hinaus solltest du all das wissen, was man so im Studium lernt, aber das ist ja bei dir vermutlich sowieso der Fall. Vielleicht solltest du dich noch intensiver mit Mathematik beschäftigen, die über dein Studium hinaus geht. Wissen in Mathe kann man eigentlich nie genug. :)
Auf jeden Fall wirst du am Ende definitiv ein besserer Programmierer sein, und wenn du noch ein paar Jahre dran hängst, sogar zu den besten zählen.
Viel Erfolg! :)
PS: Verdammt gute Frage!!!
Danke schön, aber ich möchte nochmal darauf hinweisen, dass die Liste alles andere als vollständig ist!
Wenn du dich aber in die genannten Themen einliest, wirst du über Querverweise auch auf viele weitere wichtige Gebiete treffen, mit denen du dich teilweise gleichberechtigt beschäftigen solltest.
Wie gesagt, es ist verdammt viel, und es wird Jahre dauern. Aber es lohnt sich!
Schönen Tag noch! :)
Mir hilft es immer die Klassen zu beginn grob zu umreißen und erst dann zu Programmieren.
Es hilft auch eine Klasse immer nur für ein einziges Spezielles Problem zu machen und nicht versuchen alle möglichen Features in eine Klasse zu packen.
Nehmen wir zB eine Klasse welche als Abstraktionsschicht zwischen verschiedenen Datenbanksystemen fungiert.
Ich würde nicht die Logik für jede Datenbank in die Klasse packen, sondern nur High Level Funktionen wie das Auslesen von Daten aus der Datenbank oder schreiben von Einträgen. Die Funktionen sollten hierbei möglichst gut an die späteren Aufgaben angepasst sein.
in einem Interface definierst du die Low Level Funktionen für die Datenbank und die implementierst du dann in extra Klassen, also eine Klasse pro Datenbanksystem.
Natürlich kann man auch schon das Interface in den anderen Klassen verwenden, allerdings ist es, finde ich, besser Wartbar wenn du so eine Klasse verwendest.
Das waren eigentlich so die Sachen welche ich bisher gelernt habe, wobei auch ich, besonders unter Zeitdruck, oft noch Blödsinn mache, wo ich mir nacher denke warum hab ich das so kompliziert gemacht, aber ich glaube das ist normal und ich finde man lernt in diesem Gebiet nie aus.
Na da gibt's ja schon ganze Bücher zu ("Weniger schlecht Programmieren" etc.) aher möchte ich mich ganz kurz fassen bezüglich ein paar Einsichten aus meiner bisherigen Programmiererfahrung:
- Man muss eine Bereitschaft zum Lernen mitbringen. Je höher, desto besser. Ich bin mir sicher, du hast eine Lernbereitschaft. Hatte ich auch aber am Anfang war ich immer nur darauf aus möglichst schnell an mein Ziel zu kommen. Oft ging es mir nur darum möglichst einen Codeschnipsel oder ein Tutorial zu finden das das tut, was ich nicht kann, und ich hatte keine Bereitschaft mich damit genauer auseinander zu setzen. Das Problem ist, damit verbaut man sich selber den" Weg zur Weisheit" weil man sich mit vielen Themen gar nicht beschäftigt, was zu Halbwissen führt. Vielmehr sollte man versuche Wissen nicht nur in die Tiefe, sondern auch in die Breite auszubauen. Sonst weiß man zwar wie man einen Login für eine Website programmiert, hat aber keine Ahnung von Sicherheitsaspekten und ihn garantiert absolut unsicher gebaut.
- Akzeptieren, dass man nicht alles wissen kann. Daraus aber nicht schlussfolgern: Okay dann gebe ich auf - sondern das man versuchen muss, aus all dem Lärm (auf Twitter, Blogs, Newslettern usw.) das Wichtige herauszufiltern. Man wird mit neuen Dingen (Frameworks, Libraries, Design Patterns etc. etc.) regelrecht bombardiert und nicht alles (bzw. das meiste) davon ist für einen selbst wichtig. Man sollte versuchen grob auf dem Laufenden zu bleiben und einen Überblick zu wahren. Den neuen Dingen den Schrecken nehmen. Z. B. mit einem neuen Framework ein kleines Miniprojekt realisieren um erste Erfahrungen zu sammeln und ein ungefähres Gefühl dafür zu bekommen und das "Oh Gott schon wieder ein ganz neues, großes Themenfeld von dem ich überhaupt nichts weiß"-Gefühl einzudämmen. Mir ist inzwischen klar geworden, dass es wirklich nicht wichtig ist alles über Framework X aus dem Stehgreif zu wissen (außer man benutzt das wirklich jeden Tag primär), sondern es reicht auf ein Level zu kommen auf dem man damit arbeiten kann - durchaus unter Zuhilfenahme von Dokumentation, Tutorials und Co. Wichtig ist der Überblick. Von Technologien schon mal gehört zu haben und zu wissen: (Beispiel) Ah, wenn ich mal einen Chatbot programmieren muss dann kann ich Wit.ai dafür benutzen - wie genau das geht, keine Ahnung, das finde ich dann aber schon noch heraus. Denn dann kann man auf neue Trends gut reagieren. Bzw. man bekommt vieles mit bevor es einen wirklich betrifft und kann nicht so leicht von irgendwas (negativ) überrascht werden.
- Von anderen lernen. Sehr wichtig. Vielleicht inzwischen selbstverständlich aber als ich angefangen habe hatte ich keinen Internetzugang. Ich war quasi notgedrungen auf mich allein gestellt. Ich musste erst lernen, von anderen zu lernen. Man muss sich darüber im klaren sein: Wenn ich Script X sehe und davon beeindruckt bin, dass dessen Entwickler Y erst sagen wir 18 Jahre als ist und schon Code geschrieben hat, den ich selber kaum hätte besser schreiben können - dann sprechen da womöglich viele andere Personen aus diesem Code. Man darf sich nicht von dem vermeintlichen Wissen / Können anderer einschüchtern lassen. Vieles kommt durch Erfahrung. Und vieles kommt durch "Abschauen". Die wenigsten erfinden das Rad neu, sie schauen es lediglich ab. Es gibt so viele Möglichkeiten sich zu spezialisieren, da ist es eigentlich klar, dass es viele "Experten" gibt. Allrounder sind aber auch wichtig. Und es ist das eine sich theoretische Kenntnisse anzueignen, diese dann aber praktisch anwenden zu können ist etwas anderes. (Das Thema bedarf vermutlich einer Vertiefung aber dazu fehlt es mir jetzt an Zeit.)
- Erfahrung! Also programmiere! Am besten natürlich abwechslungsreich, damit du nicht zum "Fachidioten" wirst. Der (durchschnittliche) Softwareentwickler-Alltag besteht zu einem großen Teil aus eher stumpfen Tätigkeiten bei denen man wenig bis gar nichts dazu lernt. Also achte bei deinen Programmiertätigkeiten neben dem Studium darauf, dass du möglichst viel lernst. Viele kleine Projekte mit unterschiedlichen Stacks etc. bringen diesbezüglich mehr als ein großes das am Ende nur noch aus eher primitiver Pflichtarbeit besteht. Und ja ich spreche da aus (der negativen) Erfahrung. :D
Na da gibt's ja schon ganze Bücher zu ("Weniger schlecht Programmieren" etc.) ...
Zu diesem Buch muss ich sagen, dass es für absolute Anfänger sicherlich ein reichhaltiges Angebot an Hinweisen liefert, aber Profis können aus diesem Werk vermutlich eher weniger mitnehmen. (zur Verteidigung der Autoren sei aber erwähnt, dass genau DAS auch so im Vorwort steht)
Trotzdem sollte man da natürlich mal reingeschaut haben. Genauso wie in "Clean Code" und wie sie alle heißen. :)
Fachbücher zu den Üblichen Design Pattern bzw Dingen wie Clean Code helfen sicher. Ansonsten aber vor allem eines Dinge: Learing by Doing. Also in Großen Projekten Mitarbeiten und dabei ganz wichtig auch Code von guten Leuten lesen und verstehen.
Open Source Projekte können hier z.b während des Studiums hilfreich sein. Dabei hilft dann besonders das diese meist auch definierte Review Prozesse haben. Dadurch kriegst du automatisch Feedback.
Außerdem kannst du selbst auch Code lesen in dem du selbst reviewst/dir zum review stehende Commits anschaust.
Ansonsten nennen die meisten Communitys dir auf Nachfrage meist auch gerne Bugs deren Lösung zum Einstieg gut geeignet sind.
Ob dies gerade Dir nützlich ist, musst Du selbst entscheiden.
Suche Dir ein geeignet umfangreiches Projekt. Beginne mit dessen Architektur und denke das ausgiebig durch!
Beginne mit der Implementierung. Dabei wirst Du an Unsauberkeiten Deiner Architektur stoßen. Nun gehst Du wieder einen Schritt zurück und passt diese an und "refactorst" Deine Implementierung.
Gerade durch den dabei entstehenden Aufwand wird sich Deine Architektur-Fähigkeit verbessern.
Diese Antwort verdient den Stern! Erstaunlich, wie viele aufgelistete Themen mir noch nie ins Ohr gefallen sind. Mit dieser Liste und Tipps kann ich etwas anfangen und wie gewünscht über den Tellerrand hinaus schauen. PS: Die Schmeichelei hatte keinen Einfluss auf meine Sterne-verleih Entscheidung ;)