Squeng AG's logo

Vom Nicht-Programmierer zum Software-Ingenieur

Auch in der Software-Entwicklung gilt, dass Übung den Meister macht. Und je nach schulischer Ausbildung und beruflicher Weiterbildung hat man vielleicht das Glück, unter Anleitung von Lehrern, Mentoren etc. eine Stufe nach der anderen zu erklimmen. Doch wie wird man autodidaktisch Software-Ingenieur, wenn man noch Software-Entwickler ist, Software-Entwickler, wenn man noch Programmierer ist, oder Programmierer, wenn man noch Nicht-Programmierer ist? Thereʼs a book for that!

Bezeichnen Programmierer, Software-Entwickler und Software-Ingenieur nicht das gleiche? Nein! In den Worten von Jacobson et al.:

Bücher zu den Stichworten “programming”, “software development” und “software engineering” gibt es wie Sand am Meer. Viele sind sehr gut oder wenigstens gut, nicht wenige sind jedoch schlecht oder gar sehr schlecht. Man bräuchte also nicht viel Pech, um als Anfänger an ein schlechtes Buch des entsprechenden Themas zu geraten, was die Gefahr bärge, den Stoff gar nicht zu verstehen und deshalb an sich selbst zu zweifeln oder ihn falsch zu verstehen und das falsch Gelernte dereinst mühsam umlernen zu müssen.

Vom Nicht-Programmierer zum Programmierer

Kindern empfehle ich, gemeinsam mit ihren Eltern mit Scratch programmieren zu lernen. Den Eltern lege ich ausserdem Lifelong Kindergarten nahe als motivierenden & spannenden Lieferanten von Hintergrundinformationen.

Es gibt zig Programmiersprachen. Selbst wenn man sich auf diejenigen beschränkt, welche eine gewisse Verbreitung in der Software-Industrie geniessen, kommt man noch auf ein paar Dutzend. Es wäre also illusorisch, alle praxis-relevanten Programmiersprachen erlernen zu wollen; genauso illusorisch wäre es zu glauben, als professioneller Programmierer nur eine beherrschen zu müssen. Deshalb ist die Programmiersprache, mit der man programmieren lernt, sekundär. Viel wichtiger ist es, ein starkes Fundament zu legen; die zukünftig liebste (oder vermeintlich beste) Programmiersprache erlernt sich dann relativ leicht, wenn das Fundament stark ist.

Bücher, die eine Einführung in die Programmierung versprechen, gibt es zumindest in Deutsch gar nicht so viele. (Amazon listet nur etwa 500 dazu auf.) Darunter sind nichtsdestotrotz noch zu viele, welche didaktisch einiges zu wünschen übrig lassen. Beispielsweise werden Spracheigenschaften und -konzepte nicht selten rein mechanistisch beschrieben, ohne wirklich auf ihren Sinn & Zweck einzugehen. (Man stelle sich vor, dass im Deutschunterricht lieblos erwähnt wird, dass es Konjunktiv I und Konjunktiv II gibt sowie zur Illustration ein paar Konjugationstabellen gezeigt werden, ohne jemals darauf einzugehen, wann & wie Konjunktiv I resp. II korrekt verwendet werden.)

Dabei habe ich grundsätzlich nichts gegen Bücher, die kurz & bündig eine Programmiersprache einführen. Horstmanns … for the Impatient-Bücher z.B. mag ich sehr; er setzt jedoch auch klipp & klar Programmierkenntnisse voraus.

Auf jeden Fall kann ich Introduction to Programming and Problem-Solving Using Scala empfehlen und zwar die Kapitel 1 bis 10 sowie 13, 15 und 16. Hinweise auf weitere sehr gute Bücher, insbesondere deutschsprachige, nehme ich sehr gerne entgegen.

Vom Programmierer zum Software-Entwickler

Security as a Forethought

Heutzutage wäre es unverantwortlich, Software ohne Rücksicht auf ihre Sicherheit zu entwickeln. Zwar muss die Betreiberin der Software sich mit Fragen des Datenschutzes und der Privatheit auseinandersetzen und ihre Politik (gegenüber Kunden, Benutzern etc.) festlegen, welche teils mit Sicherheitsmechanismen durchgesetzt wird. Doch Softwaresicherheit (nicht zu verwechseln mit Sicherheitssoftware) ist die Verantwortung jeder einzelnen Software-Entwicklerin und jedes einzelnen Software-Entwicklers.

eine meiner Unterrichtsfolien aus dem Jahr 2015

Designing Secure Software ist Pflichtlektüre für alle (angehenden) Software-Entwickler. Darüber hinaus ist es unabdingbar, sich auch mit Softwaresicherheit in Bezug auf die eingesetzte Programmiersprache (z.B. Java) sowie aller anderen Technologien (z.B. Web) auseinanderzusetzen.

Objektorientierte Programmierung

Heutzutage kommt man typischerweise schon in Berührung mit objektorientierter Programmierung (OOP), wenn man programmieren lernt. Auch das oben empfohlene Buch sowie sein zweiter Band bieten eine Einführung in OOP. In den letzten Jahrzehnten hat sich OOP auf breiter Front durchgesetzt, so dass Software-Entwickler sich auch damit auseinandersetzen sollten, wenn sie in erster Linie noch mit einer nicht-objektorientierten Programmiersprache wie z.B. C strukturiert programmieren.

Mein Lieblingsbuch zu OOP ist Objektorientierte Programmierung in Oberon-2. Da das Buch jedoch schon etwa ein Vierteljahrhundert auf dem Buckel hat, könnte Objektorientierte Programmierung (m)eine Empfehlung wert sein.

Funktionale Programmierung

Etwa 2003 hat mich Sebastian Mödersheim auf die Vorzüge der funktionalen Programmierung hingewiesen. Als erfahrener Haskell-Programmierer wusste er, wovon er spricht. Ich hingegen masste mir mit meinen sage & schreibe fast zwei Jahren Industrie-Erfahrung das Urteil an, dass funktionale Programmierung vielleicht für Theoretiker interessant sei, aber doch nicht relevant für Praktiker. Sebastians Hinweis auf Beating the Averages änderte noch nichts an meiner Fehleinschätzung. (Erst Jahre später, nachdem ich Paul Graham via Y Combinator [nochmals] kennengelernt und begonnen hatte, seine Essays zu lesen, realisierte ich, dass ich doch schon mal etwas von ihm gelesen, aber noch viel zu wenig ernst genommen hatte …)

Heute finden sich glücklicherweise viele Konzepte aus rein funktionalen Programmiersprachen in modernen, hybriden Programmiersprachen. Müsste man sie als Software-Entwickler wieder hergeben, würde man sie schmerzlich vermissen. Umgekehrt kann man immens davon profitieren und grosse Freude daran haben, wenn man sich etwas tiefer mit ihnen auseinandersetzt (und einmal mehr nicht nur mit ihrer Mechanik). Deshalb ist Teil I von Functional and Concurrent Programming Pflicht (und Functional Programming in Scala Kür).

Entwurf & Architektur

Wenn sie nicht gerade aus der Feder der gleichen Autoren stammen, findet man kaum zwei Definitionen von Software-Architektur resp. Stellenbeschriebe von Software-Architekten, welche sich einig sind. Im Software-Kontext wird sogar unterschieden zwischen “entwerfen” (to design), das als Verb existiert, und “architekten” (to architect), das auch im Englischen nicht als Verb existiert …

Im Geiste von KISS (Keep it simple, Squeng!) würde meine Definition eigentlich lauten: Software-Architekten entwerfen Software resp. Software-Architektur ist das Resultat von Software-Entwurf. Anders ausgedrückt würde ich Designer und Architekt im Kontext von Software als synonym betrachten. (Deshalb riskiere ich auch kein 🤯 bei der Feststellung, dass z.B. Innenarchitektur resp. Innenarchitekt mit interior design resp. interior designer übersetzt wird.)

Konsequenterweise dürfte ich auch nicht unterschieden zwischen design patterns und architecture patterns, aber muss halt akzeptieren, dass damit in der Praxis verschiedene Dimensionen impliziert werden. (Vor Jahrzehnten hatte auch ich mal “architecture is high-level design and design is low-level architecture” geschrieben.) Und dass verschiedene Dimensionen unterschieden werden, ist tatsächlich sinnvoll, so wie auch in der Nicht-Software-Architektur z.B. zwischen Stadtarchitekten und Innenarchitekten unterschieden wird. Deshalb folgt nun eine Liste von lesenswerten Büchern:

Testen

Zwar war ich mir der Wichtigkeit des Testens schon immer bewusst, dennoch musste man mich zwischen 25 und 45 zum Testen verknurren. Zwischen 45 und 65 will ich es viel besser machen, zumal ich mittlerweile grossen Gefallen am Thema gefunden habe, nicht zuletzt, weil Testen nicht nur die Implementation, sondern auch den Entwurf von Software unterstützt. Allerspätestens seit Effective Software Testing hätte ich ohnehin keine Ausrede mehr.

FORTSETZUNG FOLGT …

Vom Software-Entwickler zum Software-Ingenieur

FORTSETZUNG FOLGT …