Zur Zeit befasse ich mich (wieder) privat und beruflich mit dem Thema „Entwurfsmuster“ („Design Patterns„). Meine letzten Versuche, diese Thematik anzugehen, waren zaghaft und wenig erfolgreich. Zu trocken und zu abstrakt. Ich hatte nie das Gefühl, dass ich irgendwas davon irgendwo mal hätte einsetzen können. Inzwischen habe ich den Entschluss gefasst, mir die Entwurfsmuster jetzt endgültig gedanklich anzueignen und damit zu arbeiten. Das bekannte Werk „Entwurfsmuster von Kopf bis Fuß“ („Head First Design Patterns„) bringt dem Leser die einzelnen Muster auf humorvolle bildhafte Weise näher. Ich muss sagen, das gelingt wirklich sehr gut. Zum ersten Mal habe ich den Eindruck, dass ich es verstehe und daraus einen Vorteil ziehen kann.
Vielleicht hatte ich deshalb Schwierigkeiten, mich initial damit anzufreunden, weil die Entwurfsmuster bei mir für ein mittelschweres Trauma gesorgt hatten. Dieses genoss ich vor eineinhalb Jahren, kurz nach meinem Studium, das ich mit einem breiten Grinsen und vor Stolz geschwellter Brust abschloss, und eine Welt erwartete, die taufrische Informatiker mit offenen Armen, einem Glas Sekt, und dem roten Teppich empfangen würde. Damals, in meiner Experimentierfreude, bewarb ich mich bei einer Spieleentwicklerfirma als Junior-Developer für Tools. Freudig erzählte ich davon, dass ich mich für den Richtigen für den Job halte, weil ich viel Erfahrung mit Spielen habe, weil ich das Spiele-Repertoire des Unternehmens kenne und selbst spiele, und ganz besonders weil ich selbst schon etwas Erfahrung im Bereich Spieleentwicklung gesammelt habe, sowohl 2D als auch 3D, sowohl Windows als auch Linux, sowohl Java als auch C++. Bestimmt würde man mir gleich den Arbeitsvertrag rauslegen.
Stattdessen fragte man mich ziemlich ausführlich, ob mir Erich Gamma ein Begriff ist, ob ich weiß wer die Gang of Four ist und was die eigentlich gemacht haben, ob ich irgendwelche Design Patterns kenne und möglichst auch gleich beschreiben könnte, wofür die da sind. Observer hier, Factory da, Design Patterns dort und überall. Ich musste bei jeder Frage abwinken und saß am Ende nur noch mit einem roten Kopf da, wollte nur noch, dass es endlich aufhört. Der Rest des Bewerbungsgesprächs verlief nicht minder ernüchternd. Lauter Begriffe, die ich vielleicht mal gehört hatte, oder eben nichtmal das. Es ging spätestens jetzt nicht mehr darum, ob ich die Stelle bekommen würde oder nicht. Die haben es nämlich geschafft, mir den Job auszureden. Ich wollte die Stelle gar nicht mehr. Ich begann zu zweifeln, ob ich als Entwickler überhaupt geeignet bin. Vielleicht hätte ich als Maurer mehr Glück.
Ich bin aus dem Informatikstudium entlassen worden, ohne dass der Begriff „Entwurfsmuster“ jemals in einer Vorlesung gefallen wäre. Java, PHP, C und C++ waren im Studium eigentlich nicht zu kurz gekommen und auch gab es die eine oder andere Vorlesung zum Thema Software Engineering, wo dann so Dinge wie das Wasserfall-Modell und das V-Modell durchgenommen wurden. Meine Noten waren zumeist überdurchschnittlich. Ich hatte nie Anlass gehabt mich schlecht vorbereitet zu fühlen. In meiner Freizeit hatte ich durchaus das eine oder andere kleine Progrämmchen oder Spielchen entwickelt, aber auch da stieß ich nie auf Entwurfsmuster, wenn ich mal was recherchierte. Und dann stand ich da, mit einem Diplom in der Hand, ohne Kenntnis von Entwurfsmustern. Und so jemanden wollen die Arbeitgeber wohl nicht.
Ich hatte Glück, ich bin nach zehnmonatiger Stellensuche gnädigerweise doch noch in einem IT-Unternehmen angestellt worden. Was sprach am deutlichsten gegen meine Anstellung: die zehnmonatige Stellensuche – „Grenzwertig“, laut Personaler. Dass ich unerfahren bin und keine Entwurfsmuster kenne, ist unproblematisch und lässt sich ändern. Warum nicht gleich so? Dann wären mir auch zehn Monate Unsicherheit erspart geblieben. Hätte meine Arbeitslosigkeit länger als ein Jahr angedauert, wer weiß ob mir mein Diplom dann noch genützt hätte.
Salve Vince,
mit einiger Belustigung, musste ich lesen, wie du dich für eine Stelle als Software Engineer beworben hast, ohne zu wissen was die GOF Patterns sind. Sorry das ich so hart bin. Aber ich bin doch schon etwas länger als du in dem Geschäft tätig. Auch als Software Engineer mit Fachhochschulabschluss. Bei mir hättest du den Job auch nicht bekommen, da ich von einem FH Absolventen erwarten kann, dass er zumindest im Ansatz weiss, wass ein Factory Pattern ist. Wie soll ich mit jemandem arbeiten, der nicht mal die Grundlagen von OOA / OOD kennt? Das ist eben Engineering. Alles andere ist basteln.
Toll dass du jetzt begonnen hast, die Patterns dir doch noch anzueignen. Du wirst noch sehen, wie praktisch die sind. Das Head-First Buch ist wirklich gut, trotzdem sollte man schliesslich noch einen Blick in das Original werfen. Hat viel mehr Tiefe.
Eins wundert mich aber doch: Du schreibst, du hättest im Studium nie was von Patterns gehört. Auf der Webseite deiner FH, habe ich den Modulplan gefunden. Modul Nummer 46? Objektorientierte Techniken? OOD -> Patterns? Echt nie gehört?
Bitte sag nicht, du hättest auch noch nie einen Unit Test geschrieben.
Gruss aus der Schweiz
Thomas
Hallo Thomas,
vielen Dank für deinen Kommentar, auch wenn er ein klein wenig arrogant rüberkommt. Ich nehms einfach mal positiv auf ;-)
Zum Modulplan, den du gefunden hast: Den Diplomstudiengang, den ich durchlaufen habe, gibt es heute nicht mehr, insofern kann ich dir über diesen Plan nichts sagen. Ich kann dir nochmal versichern, dass in den paar Objektorientierung-Vorlesungen kein einziges Design-Pattern erwähnt wurde. Echt nicht.
Unit-Tests kamen dagegen tatsächlich vor, daran wäre die Bewerbung also hoffentlich nicht gescheitert.
Was meine Bewerbung trotz „Unterqualifikation“ angeht: Es war eine Stelle als _Junior_ Developer und wenn man so manche Definition von Design Patterns liest, dann steht dort unter anderem, dass die Anwendung von Design Patterns insbesondere ein Merkmal _erfahrener_ Software-Entwickler ist, also eigentlich etwas, das man nicht mit der Muttermilch aufnimmt, sondern sich im Laufe seines Berufslebens erarbeitet. Daher ist das meiner Vorstellung nach weiterhin etwas, das man eben nicht unbedingt von einem Hochschulabsolventen erwarten kann, aber dafür garantiert von jemandem, der seit 10 Jahren Software entwickelt.
Ich denke generelle Programmierkenntnisse, Lernbereitschaft, ein Auge für Algorithmen usw. sind primär doch wichtiger als einen Haufen Entwurfsmuster auswendig zu kennen. Wie sich eben zeigt, lässt sich das jederzeit nachholen. Dafür lagen die Studienschwerpunkte bei uns vielleicht einfach ein wenig anders verteilt. Allerdings will ich das jetzt nicht als Aufforderung zum Schwanzvergleich verstanden wissen. Ich bin mir im übrigen nicht so sicher, inwieweit sich die Studiengänge von Software Engineering und klassischer Informatik in dieser Hinsicht vergleichen lassen.
Wenn ich ausschließlich auf solche Arbeitgeber wie dich gestoßen wäre, hätte ich nie einen Fuß in die Tür bekommen. Dann hätte ich vermutlich ein unbezahltes einjähriges Praktikum als Kabelträger oder eine Ausbildung zum Fachinformatiker anfangen dürfen. Insofern bin ich dankbar, dass es Arbeitgeber gibt, die nach den Dingen fragen die man kann, statt einem vorzuhalten was man nicht kann.
Viel Erfolg auch weiterhin,
Vince
Nachtrag: Ich kenne mindestens zwei Bachelor-Studenten (Wirtschaftsinformatik und Software-Engineering, zwei unterschiedlichen Hochschulen), die in Kürze ihren Abschluss machen, aber keine zwei Design Patterns aufzählen können. Das ist wohl nicht sonderlich repräsentativ, aber für mich sieht das zumindest so aus als wäre GoF noch keine Selbstverständlichkeit an den Hochschulen.
Salve,
ich ging davon aus, dass du mit meiner Arroganz zurechtkommst. So hab ich dich eingeschätzt. Aber wenn man keine Ecken und Kanten bietet, wird man ja im Netz auch nicht ernstgenommen.
Zurück zum Thema: Ich finde es traurig, dass anscheinend an deutschen Hochschulen Patterns kein Thema sind. In der Schweiz wird seit über 10 Jahren auf diese Dinge Wert gelegt. Prinzipien wie DRY und SOLID muss man als Software Engineer einfach kennen. Der Vorteil von Patterns und den Prinzipien ist ja, dass man sie hervorragend in eine Vorlesung unterbringen kann. Das kann man, wie du formuliert hast, einfach auswendig lernen.
Wo ich dir hingegen auch wieder zustimme ist, dass es nichts bringt diese einfach nur auswendig zu können. Wann man ein Pattern einsetzt oder wann nicht, wann man sie kombiniert etc. das kann man nur in der Praxis lernen. Das ist dann der Unterschied zwischen dem Senior und dem Junior.
Gut, vielleicht muss man hier aber auch mal unterscheiden zwischen Developer und Engineer. Ein Developer (Entwickler / Programmierer) bringt nicht die selben Voraussetzungen mit wie ein Ingenieur. Es ist auch ein anderer Job. Vom Ingenieur erwarte ich dass er hauptsächlich die Analyse (Requirements), Design und Test macht. Ein Entwickler setzt das um. Ob da ein Entwickler von Anfang an wissen muss, was Design by Interface ist, ist diskutabel. Trotzdem brauchen beide eine gemeinsame Kommunikationsbasis. Da helfen Patterns, UML, Use Cases und das ganze langweilige Zeugs, welches nichts mit Coden zu tun hat. :-P
Wenn du das Head First Pattern Buch durch hast, kauf dir noch Clean Code von Robert Martin (englisch, die deutsche Version ist naja). Das müsste eigentlich genau dein Ding sein.
Spannende Unterhaltung. Wollen wir die fortsetzen?
Gruss
Hallo Thomas,
danke für deine Buchempfehlung. Ich werde mich danach mal umschauen. Ich denke auch, dass ich das Thema Design Patterns anschließend vertiefen sollte, weil, wie du sagst, man sich das Zeug wirklich nur durch Übung aneignet, da hilft auch zehnmal soviel Theorie nicht.
Ich habe mal spaßeshalber bei den angehenden Informatik-Bachelors unter meinen Bekannten ein wenig Panik verbreitet und ihnen erzählt, wie schlecht es um ihre beruflichen Aussichten stünde, weil sie keine Design Patterns kennen. Diese fragten ihrerseits einige ihre Kommilitonen und Freunde, wieviele Design Patterns sie denn so auf Anhieb nennen könnten. Es waren nie mehr als zwei, wenn überhaupt (die da wären: Singleton und Factory). Ich fürchte, das verbreitet sich jetzt wie ein Lauffeuer. Möglicherweise habe ich damit ja jetzt einen Stein ins Rollen gebracht, der die deutschen Informatikstudiengänge revolutioniert ;)
Aber bevor du jetzt völlig den Glauben an die deutschen Hochschulen verlierst: UML und alles was da dran hängt, wurde im Studium wirklich intensiv durchgekaut. Also ich sehe das wirklich nicht so schwarz wie du, wenn du meinst, du könntest mit deutschen Akademikern nix anfangen. Aber auch damit ist es manchmal einfach so, dass selten angewandtes Wissen irgendwann verblasst und man nochmal danach googlen muss, bevor es wieder präsent und einsatzbereit ist.
Ich betrachte mich eigentlich nicht als Codemonkey, nur weil ich noch nicht soviel Zeit in Software-Design investiert habe. Zu meiner Verteidigung: Auch in meinem jetzigen Umfeld habe ich noch kein einziges Softwareprodukt von Grund auf entwickelt, sondern bisher nur fertige Produkte anderer Leute übernommen. Ich hoffe das ändert sich irgendwann, weil diese Erfahrung eben unersetzbar ist. Ich glaube die Zeit bringt das alles mit sich.
In der Tat ist es auch für mich sehr interessant, mal die Sichtweise eines erfahrenen Entwicklers zu hören. Selbstverständlich können wir gerne weiter diskutieren, fürchte nur, dass wir mit den Design Patterns mehr oder weniger durch sind. In welchen Sprachen entwickelst du denn?
Gruß,
Vince