Warum man NICHT in einem Monat Programmierer/Softwareentwickler wird

Da ich immer wieder der Frage begegne, wie lange man braucht, bis man ein halbwegs guter Programmierer/Softwareentwickler wird oder auch schonmal die Anfrage aus meinem näheren Umfeld bekommen habe, ob man mir nicht bei meinen Projekten ein wenig unter die Arme greifen könnte, hier ein kurzer Erklärungsversucht, warum das NICHT mal so nebenbei machbar ist.

Meine Antwort auf die Frage, wie lange man braucht, um ein halbwegs guter Programmierer zu werden, lautet in der Regel:

“Kommt drauf an, aber ich würde ungefähr 5 Jahre schätzen.”

Mit diesem Statement sind die meisten Fragenden nicht zufrieden:

“So schwer kann das doch nicht sein!”

Da ich hauptsächlich Webapplikationen in Java entwickel, werde ich ein paar Frameworks und Technologien ansprechen, die man so im Entwickleralltag benötigt und warum man diese benötigt. Zu fast jedem Punkt gibt es sicherlich Alternativen, die man einsetzen kann, aber diese Liste erhebt ja keinen Anspruch auf Vollständigkeit, sondern soll nur exemplarisch verdeutlichen, dass programmieren *mehr* ist, als eine Programmiersprache zu können.

1. Das Betriebssystem. Okay, jeder der einen Computer verwendet, verwendet auch (wissentlich oder eben auch unwissentlich) ein Betriebssystem. In meinem Falle ist das sowohl Windows als auch Linux. Wobei die Webapplikationen in der Regel später auf einem Linux-System laufen. Sprich: ich muss beide Systeme grundlegend bedienen / administrieren können. Dazu gehört unter anderem der Umgang mit der Konsole (ja: auch unter Klicki-Bunti-Windows kommt man da ab und zu nicht dran vorbei) oder zum Beispiel das Setzen von Umgebungsvariablen. Beides Dinge, mit denen der Otto-Normal-User in der Regel bereits überfordert ist. Auch die feinen Unterschiede zwischen den Systemen, wie z.B. case-sensitivity, werden anfangs unter Umständen für Verwirrung sorgen.

2. Die Konzepte einer Programmiersprache. Da die von mir verwendete Sprache objekt-orientiert ist, kommt man nicht drum herum sich mit OOP auseinander zu setzen. Was sind Klassen, Vererbung, Polymorphismus? Die abstrakten Gedanken hinter diesen Begriffen zu verstehen, dauert nicht lange. Sie aber in der Praxis an der richtigen Stelle richtig anzuwenden, schaffen einige Programmierer in ihrem ganzen Programmiererleben scheinbar (leider) nicht.

3. Die Programmiersprache. In meinem Falle Java. Die Syntax von Java ist nicht sonderlich kompliziert. Bis man aber einen Überblick über vorhandene Funktionalität gewonnen hat, die mit Java daher kommt, werden etliche Monate vergangen sein. Und wenn man noch nie (Java) programmiert hat, wird man sich erst einmal mit ein paar Grundbegriffen herumschlagen müssen. Was ist Source-Code, was ist ein Compiler, was sind Packages, Interfaces, Klassen, Exceptions, Datentypen, Methoden? Wie compiliere ich meinen Sourcecode? Wie führe ich die generierten *.class-Dateien aus? Wie bündel ich meine verschiedenen Klassen in eine JAR-Datei? Was sind überhaupt JAR-Dateien? Wie binde ich Fremdbibliotheken ein?

4. Die IDE. Wenn man die Grundkentnisse erworben hat und seine ersten Programme auf der Konsole compiliert und zum Laufen gebracht hat, wird man sich sicherlich irgendwann nach einem mächtigeren Werkzeug sehnen. Eine IDE muss also her. Ob das nun IntelliJ IDEA, Eclipse oder Netbeans ist, ist völlig irrelevant. Ich persönlich verwendet seit über 6 Jahren Netbeans. Und entdecke tw. immer noch neue Features. Eine IDE, egal welche, IST ein mächtiges Werkzeug, da diese in der Regel auf professionelle Entwickler abzielen. Bis man dieses Werkzeug richtig einzusetzen weiß, wird ebenfalls eine Menge Zeit ins Land gehen.
Alternativ wäre ein Editor mit Syntax-Highlighting schon ein Fortschritt. Aber die Integration sämtlicher Entwicklungstools in einem Programm ist schon etwas Feines.

5. Das Build-Tool. Spätestens wenn man nicht mehr alleine an einem Projekt arbeitet, möchte man ein Build-Tool einsetzen, womit sich das Projekt unabhängig von der Entwicklungsumgebung respektive einem bestimmten Computer erstellen lässt. In der der Java-Welt sind die beiden verbreitetsten Tools Ant und Maven. Maven bringt gleich ein Dependency-Management mit sich, auf welches man nicht verzichten kann (manchmal aber am liebsten würde) und bei Ant bietet sich das Projekt Ivy dafür an. Ach ja, und ab und an ist auch ein eigener Repository-Manager wie Nexus unabkömmlich.

6. XML. Auch wenn man für sein eigenes Projekt XML nicht unbedingt immer braucht, wird man bei der Konfiguration häufig nicht auf XML verzichten können (z.B. bei Maven und Ant, aber auch bei den meisten Fremdbibliotheken).

7. Ein Debugger. Kein Programm ist beim ersten Mal fehlerfrei. Und manchmal sieht man die Fehler einfach nicht durch einfaches anstarren des Codes. Also muss man sich damit auseinandersetzen, was ein Debugger ist und wie er funktioniert. Wo und wie man Breakpoints setzt, wie man sich Variableninhalte anzeigen lässt, wie man schrittweise durch ein Programm läuft und/oder wie man Methoden “überspringt”. Konditionale Breakpoints sind sicherlich nett, aber bisher habe ich die noch nicht wirklich gebraucht. Aber falls ich mal einen konditionallen Breakpoint benötige, weiß ich, dass es diesen gibt und wie ich ihn anwenden kann.

8. Die Datenbank. Fast jedes Programm wird Daten in irgend einer Form speichern müssen. In wenigen Fällen langt eine normale Textdatei, vielleicht fährt man mit einem XML-Dokument besser. Ab einer gewissen Datenmenge wird man an einer Datenbank aber nicht vorbeikommen. Häufig nimmt man hier immer noch ein RDBMS. Vielleicht ist aber eine Datenbank aus der NoSQL-Bewegung eher für den Anwendungsfall brauchbar. Manchmal (zum Testen z.B.) braucht man auch nur eine in-memory-Datenbank. MySQL hat bei mir in der Regel seinen Zweck erfüllt.
Ach ja, wer eine Datenbank einsetzt, sollte auch ein wenig Kentnisse darüber haben, wie so ein Datenbankdesign aufgebaut wird.

9. SQL. SQL ist die Sprache für Datenbanken. Um also Datensätze abzufragen / zu ändern, müssen also Grundkentnisse in SQL vorhanden sein.

10. Ein ORM. Ein Object-Relational-Mapper nimmt einen den Großteil der Interaktion mit Datenbanken ab. Zwar benötigt man immer noch grundlegende SQL-Kentnisse, dafür kommen andere Fallstricke hinzu. In der Java-Welt ist Hibernate zum de-facto Standandard geworden. In Hibernate kann man seine Datenbankabfragen in HQL, eine an SQL angelehnte Sprache implementieren. Allerdings sollte man heutzutag eher JPA verwenden, was wiederum JPQL verwendet, wobei Hibernate eine Implementierung von JPA darstellt. Verwirrt? Gut, sonst wäre ich ja arbeitslos :-)

11. Der Server. Für eine Webapplikation benötigt man noch einen Server. Für meine Zwecke benötige ich lediglich einen Servlet-Container wie Tomcat oder Jetty. Einen kompletten Applikationsserver wie Glassfish, JBoss oder Geronimo habe ich für meine Zwecke noch nicht verwendet. Auch um die Integration eines Servlet-Containers mit einem Webserver wie Apache HTTPD bin ich bisher herumgekommen (respektive wurde das bisher in benötigten Fällen von jemand anderem umgesetzt).

12. Das Webframework. Um nicht ständig wiederkehrende Probleme selber zu lösen, nimmt man bereits etablierte Lösungen, die einem mit einer gewissen Grundfunktionalität versorgen. Nachdem ich in verschiedenen Projekten verschiedene Frameworks ausprobiert / getestet habe (Struts 1, Struts 2, Spring MVC, GWT, Wicket), bin ich bei Wicket hängen geblieben. Ob man nun ein Komponenten-orientiertes Framework (z.B. Wicket, GWT oder JSF) oder doch lieber ein Seiten-orientiertes Framework verwendet (z.B. Stripes, Struts, Spring MVC) ist eine Geschmacksfrage.
Allen ist gemein, dass man ein Grundverständnis für die Technik benötigt, die dem Web zu Grunde liegt. Was ist HTTP, ein Post-Request, ein Get-Request, was sind Parameter, was ist ein Port und wie funktionieren Sessions? Was ist ein Server-Roundtrip? Und warum ist Ajax für den Endnutzer ein schickes Extra, für den Entwickler aber manchmal die reine Hölle?
Ach ja, und ein wenig HTML und CSS sollte man auch können. Und für den Ajax-Kram wird man um ein wenig JavaScript nicht drum herum kommen. Und wo wir schon dabei sind: wer das erste Mal über komische Zeichen statt der erwarteten Umlaute stolpert, wird sich freuen dürfen, sich mit Encodings auseinander setzten zu dürfen. (Warum gibt es eigentlich nicht nur UTF-8?!?)

13. Webanwendungen absichern. In der Regel hat man auf jeder Webseite einen geschützten Bereich, für den man sich anmelden muss. Um diese Funktionalität nicht selber implementieren zu müssen, bietet sich Spring Security an.

14. Logging. Eine gewisse Protokollierung was wann geschieht ist spätestens bei der Fehlersuche hilfreich, wenn sich ein Besucher der Webseite beschwert, dass etwas nicht bei ihm funktioniert. Also wird noch ein Logging-Framework, wie Log4J benötigt.

15. Dependency Injection. Um all diese Technologien möglichst lose zu koppeln, hat sich Spring als Dependency-Injection-Framework durchgesetzt. Spätestens beim Testen, wenn man Mock-Objekte verwenden möchte, wird man Spring lieben lernen.

16. Unit-Tests. Um nicht bei jeder Änderung die gesamte Anwendung testen zu müssen, ob man nicht irgendwas kaputt gemacht hat, sollte man Unit-Tests schreiben, die den Code programmatisch testen. Ob man nun TestNG oder JUnit verwendet, ist ebenfalls geschmacksfrage. Wobei ich TestNG für das bessere Tool halte, auch wenn JUnit verbreiteter ist.

17. Ein Versionskontrollsystem (=VCS). Da man in der Regel keine Software fertig stellt, sondern nur aufhört, an ihr zu arbeiten, wird es im Laufe der Zeit, immer wieder neue Versionen geben. Und spätestens wenn man mit mehreren Programmierern an einem Projekt arbeitet, möchte man eine Möglichkeit haben, die es einem ermöglicht, Sourcecode zu versionieren. Dafür bieten sich Versionskontrollsystem an. Auch hier hat man die Qual der Wahl: CVS, Subversion, GIT, Mercurial, etc. Mit der Wahl von Subversion als erstes VCS wird man anfangs sicherlich nicht viel falsch machen, zumal dieses VCS in die gängigsten IDEs integriert ist.

17. Continuous Integration (=CI). Da Unit-Tests Zeit brauchen und dennoch regelmäßig ausgeführt werden sollen und man unter Umständen den Änderungen seiner Kollegen im VCS nicht traut, sollte man einen CI-Server, wie z.B. Hudson, aufsetzen, welcher in regelmäßigen Abständen sich die Sourcen aus dem VCS holt, compiliert, testet und sonst was macht. Je nachdem was man so einstellt. Dazu mehr im nächsten Punkt.

18. Statische Codeanalyse. Einige potentielle Fehlerquellen lassen sich durch Tools finden, sogenannte statische Codeanalyzer. Diese lassen sich wunderbar in den CI-Prozess integrieren. Findbugs, PMD, CPD, Checkstyle oder JavaNCSS sind nur ein paar davon, die ich regelmäßig einsetze. Wobei die Interpretation der Ergebnisse ein gewisses Maß an Erfahrung vorraussetzt, insbesondere, um False-Positives zu erkennen.

19. Bugtracking. Da man nicht immer sofort mit der Fehlerbehebung hinterherkommt, sollte man noch einen Bugtracker aufsetzen und verwenden. Bei mir ist das Redmine, weil dort auch ein Wiki, Forum und SVN-Integration verfügbar sind. Weitere bekannte Vertreter sind z.B. Mantis, Bugzilla, JIRA. Ach ja, hier muss die eigene Infrastruktur auch enstprechend erweitert werden. Redmine setzt auf Ruby, Mantis auf PHP, Bugzilla auf Perl. Your choice :-)
Ein weiteres Auswahlkriterium könnte wieder die Integration in die verwendete IDE sein.

20. Profiling. Wenn der eigene Code zu langsam ist und alles Ewigkeiten dauert, wird man einen Profiler anschmeißen, um zu schauen wo die Bottlenecks sind. Allerdings muss man ein wenig über die technischen Internas bescheid wissen, um die Ergebnisse interpretieren zu können respektive die Bottlenecks beseitigen zu können.

21. Speicherverwaltung. In Java muss man sich nicht mehr manuell um die Speicheranforderung und -freigabe kümmern. Dennoch sollte man wissen, dass es einen Garbage Collector gibt und so ungefähr wissen, wie dieser funktioniert. Überhaupt wird man bei der Webapplikations-Entwicklung schnell über OutOfMemory-Exceptions stolpern, die trotz X GigaByte RAM von einer kleinen WebApplikation verursacht werden. Damit man diese Fehler verstehen und beseitigen kann, muss man wissen, was unter der Haube geschieht.

22. Algorithmen. Das viele Wege nach Rom führen, ist ja allgemein bekannt. So ist es auch in der Programmierung. Viele Probleme können auf viele verschiedene Arten gelöst werden. Mit verschiedenen Vor- und Nachteilen. Man schaue sich nur mal die Vielfalt der Sortieralgorithmen an. Es wird vorkommen, dass man eine funktionierende Lösung hat, diese aber durch geänderte Rahmenbedingungen, ändern muss, weil die initiale Lösung nicht optimal ist. Das nennt sich dann refactoring.

23. Refactoring. Mit den heutigen IDEs eigentlich kein Problem mehr. Ziel ist es, Code wartbarer oder im allgemeinen “besser” zu machen. Nur muss man dann auch wissen, was eigentlich “besser” ist. Bei ständig wiederkehrende Problemen haben sich einige Lösungen herauskristalisiert, die sich dann Design Patterns nennen.

25. Design Patterns. Das sind Lösungsansätze für wiederkehrende Probleme. Um diese bewusst anwenden zu können, muss man aber wissen respektive Erkennen, dass ein bestimmtes Problem vorliegt.

26. Programmierstil. Auch wenn die Gestaltung (=Formatierung) des Source Codes keinen Einfluss auf den Ablauf eines Programms hat (zumindest nicht in Java), so ist ein guter konsequenter Programmierstil unabdingbar für wartbaren Code. Dieser entwickelt sich erst mit zunehmender Erfahrung.

27. Dokumentation. Gute Dokumentation zu schreiben ist weitaus schwieriger als es zunächst erscheint. Erst im Laufe der Jahre entwickelt man ein Gefühl dafür, was wichtig ist und was nicht. Und wie die Dokumentation am besten strukturiert wird.

28. Die englische Sprache. Als Programmierer wird man definitiv nicht um die englische Sprache herumkommen. Während man beim Lesen seine Unkenntnisse noch mehr oder weniger gut kaschieren lassen, so wird es spätestens im schriftlichen teilweise äußerst abenteuerlich. Und da viele Programmierer ihren Variablennamen einen englischen Namen verpassen, landet man ganz schnell im Kuriositätenkabinett der englischen Sprache.

29. Sonstiges. Noch ein paar Schlagworte, die mir so in den Sinn kommen, wenn ich darüber nachdenke, was man sonst noch so gebrauchen könnte: Lucene für die Suche, Hibernate Search um Hibernate und Lucene zu verheiraten, SSH um sich remote auf einem System einzuloggen, Firebug um während der Webseitengestaltung Fehler zu finden, Googles Page Speed um die Geschwindigkeit zu verbessern, Java Mail um Mails zu versenden (was wiederum grundlegende Kenntnisse des Mailversands verlangt (was ist ein STMP-Server?)), Quartz um Cron-Jobs innerhalb einer Applikation laufen zu lassen, reguläre Ausdrücke, Webservices (ob SOAP, REST oder sonstiges ist erst einmal einerlei), ein Grundverständniss von Computersicherheit (denn keiner möchte in seinem Programm z.B. SQL-Injections ermöglichen). Multithreading ist heutzutage sicherlich auch noch erwähnenswert genauso wie Deadlocks und Heisenbugs. Ach und die verschiedenen Lizenztypen, auf die man teilweise achten muss, habe ich fast vergessen.

30. Zu guter letzt: eine endlos hohe Frustrationsgrenze, ein Auge für Details sowie eine Engelsgeduld. Wer schon Mal für eine Woche auf drei Zeilen Code gestarrt hat, weil diese einen Deadlock erzeugt haben, man aber keine Lösung fand, weiß was ich meine.

Fazit

Braucht man das alles? Es kommt drauf an! Für ein kleines Gästebuch sicherlich nicht. Aber die genannten Schlagworte sind einfach Werkzeuge. Und um mal bei dieser Analogie zu bleiben: wenn man sein Haus verschönern und ein Bild aufhängen möchte, langt es, einen Hammer bedienen zu können. Baut man das Haus aber von Grund auf, benötigt man etliche Werkzeuge mehr! Und das in verschiedensten Ausführungen.

Softwareentwicklung ist ein wenig wie Autofahren. Den Führerschein kann man relativ schnell erlangen. Aber höchst wahrscheinlich wird sich kein Fahranfänger an dem Tag, wo er seine Fahrlizenz erworben hat, sich zutrauen, alleine in einer verregneten Nacht im Winter in den Wagen zu setzen und von Flensburg nach München zu fahren. Möglich ist es. Aber wohl keiner wird es machen respektive sich zutrauen. Programmieranfänger sind da ein wenig anders. Nachdem das erste “xyz in 21 Tagen”-Buch zur Hälfte überflogen wurde, denken die meisten, sie könnten das nächste Microsoft gründen.
Ebenso habe ich Studenten kennengelernt, die ein Semester lang einen Kurs besucht haben und der Meinung wären, sie würden bereits alles können.

Die von mir angeführten Punkte sind keineswegs vollständig. Sie sind aber auch nicht übertrieben. Wer das denkt, der darf sich ja gerne mal ein paar Monate an einem Stück Software probieren. Bis auf Windows und JIRA sind die genannten Tools alle kostenfrei.

Und jene Leser, die Programmiererfahrung haben und bis hierher durchgehalten haben: Feedback ist durchaus erwünscht.

Verwandte Artikel

  1. Wie man mir 2,99€ im Monat klauen wollte – oder warum Symantec bald pleite sein dürfte
  2. Softwareentwicklung im Team – Teil 6 – Nightly Builds

2 thoughts on “Warum man NICHT in einem Monat Programmierer/Softwareentwickler wird”

  1. Zu diesem Beitrag fällt mir nur eines ein –> EINFACH GENIAL Fehler beim Erstellen. Möchten Sie den Vorgang fortsetzen und den letzten erfolgreichen Build ausführen?

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>