|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Für technische und konzeptuelle Texte bin ich in Englisch noch schneller und genauer als in Deutsch oder Niederländisch.
Sprache Level
Englisch fließend
Deutsch fließend
Niederländisch Muttersprache
Französisch, Italienisch verstehen
Samples aus von mir geschriebener Dokumentation auf Englisch finden Sie über die Seite Projects / Work Samples.
Qualität und Entwicklungs-Grundsätze
Nach dem Finden von Lösungen für algorithmische Probleme, ist eine meiner stärksten Motivationen in einem Auftrag, die Software am Projektende in einem guten Zustand zu hinterlassen, das heißt: übersichtlich strukturiert, gut getestet (komplett mit automatisierten regression tests), und komplett mit einer guten Dokumentation der Struktur und Algorithmik.
In der abgelieferten Software ist es für mich das allerwichtigste, dass der
Code zugänglich (accessible) ist für den Autraggeber, d.h. für die
Mitarbeiter des Auftraggebers. Diese Zugänglichkeit beinhaltet dass
übersichtlich ist wie die Software aufgebaut (strukturiert) ist, und dass
einsichtlich und verständlich ist wie die Algorithmen funktionieren.
Dies wird erreicht nicht nur dadurch dass übersichtlich kodiert wird, sondern
noch wichtiger durch einen übersichtichen logischen Aufbau (in Modulen,
Datenstrukturen, Datenfluss), und durch eine übersichtiche und einsichtliche
Dokumentation der Aufbau und Algorithmik.
Die Erfahrung hat mich gelehrt dass es eine praktische Tatsache ist dass, für
jeden beliebigen Teil und Funktionalitätsaspekt einer Software, dass dieser
mit 100% Sicherheit nicht funktioniert solange er nicht getestet wurde.
"Software testen" bedeutet dabei für mich nicht dass nur theoretisch
annehmlich gemacht wird dass es funkioniert, sondern dass tatsächlich praktisch
demonstriert wird dass es funktioniert.
Praktische Demonstration, auf reelle praktische Daten, ist daher meines Erachtens
unerlässlich, und zwar so früh wie möglich und in allen Teilschritten der
Entwicklung. Jeder Algorithmus den man sich überlegt sollte unmittelbar
getestet werden, noch vor Einbau in das Gesamtprogramm.
Logische Fehler zu finden ist ein nichttrivialer, und sehr wesentlicher, Aspekt der
praktischen Softwareentwicklung. Jeder der Erfahrung mit Softwareentwicklung
hat, weiß dass, in 95% der neuentwickelten Software, logische Fehler nach
der Entwicklung oft eine ganze Weile unentdeckt bleiben, manchmal sogar über
Jahre.
Das Schlimmste das man als Softwareentwickler tun kann ist, Fehler zu
verstecken, in dem man so programmiert dass die Fehler die auftauchen sich nicht
aüßern. Das ist wie Fehler über lange Zeit unaufgemerkt bleiben.
Der Weg, zu fehlerfreier Software zu kommen, ist nicht, die Fehler zu verstecken,
sondern so zu programmieren dass auf logische Fehler aggressiv überprüft
wird, und so dass die logischen Fehler die detektiert werden sich auch deutlich
aüßern.
Fehlerdetektion — Self-Testing
Die aggressive Fehlerüberprüfung bewirkt man dadurch dass man so kodiert dass die Software während dem normalen Programmlauf im gewissen Sinne sichselbst testet, nämlich dadurch dass an jeder Stelle wo eine Kondition abgeprüft werden kann die gemäß design immer erfüllt sein sollte, diese Kondition überprüft wird durch eine assertion im Code. (NB: Diese assertions kommen zu den Algorithmentests, Modultests und Regressionstests zusätzlich dazu, und ersetzen diese nicht.)
Dass detektierte Fehler sich auch deutlich aüßern bewirkt man durch
fail-early, das heißt: dadurch dass die self-testing assertions so lang
wie möglich aktiviert bleiben, und dadurch dass die Aktion die ausgeführt
wird wenn eine assertion fehlschlägt von einer Art ist die nicht unaufgemerkt
bleibt. Letzteres bedeutet dass das Programm normalerweise immer sofort
abgebrochen wird sobald ein logischer Fehler detektiert wird; so maximiert
man die Fehlerfindungsrate und erreicht man am schnellsten die erwüschte
Fehlerfreiheit.
Ich glaube fest daran, dass die self-testing assertions, solange nicht ein
wichtiger spezieller Grund dagegen spricht, normalerweise immer aktiv
sein sollten, auch in ausgelieferter Produktionssoftware — dies ist der Weg wie
man die Art von Fehlern fängt die "im Labor" kaum auftauchen und die man beim
Erstellen der Modultests und Regressionstests übersieht.
Ein Merkmal von gutem software engineering ist natürlich, dass Software
modulär aufgebaut ist (jedes Modul hat einen wohldefinierten und
minimalen Zweck, schmale Schnittstellen, und die inputs und outputs haben
wohldefinierte Wertebereiche).
Die Module bilden einen hierarchischen Aufbau (übergreifende high-level Module
benutzen einfachere low-level Module).
Ein sehr wichtiger Grund für Modularität ist dass dies es erlaubt, die
Modulen separat zu testen.
Das Testen der einfacheren low-level Modulen ist einfacher wegen ihren einfacheren
Funktionalitätsbereiche; Folge davon ist, dass man dadurch dass man auch die
low-level Module einzeln testet, das Netz womit man Fehler detektiert sehr
maßgeblich verdichtet.
Beim Abliefern einer Software von nichttrivialer Komplexität ist es wichtig, dass
bei der Software auch Regressionstests abgeliefert werden, d.h. ein Paket
von Tests die automatisiert ausgeführt werden können und automatisiert
verglichen werden können mit den zu dem jeweiligen Test festgelegten erwarteten
outputs.
Zweck von Regressionstests ist, einmal einkodierte Funktionalität abzusichern
gegen versehentliche spätere Zerstörung wann der Code später noch einmal
angefasst wird. Regressionstests sind Pflicht für jede nichttriviale
Software die Weiterentwicklung und Modifizierung zulassen will.
Die Regressionstests sollten sollten automatisiert ausgeführt werden können,
damit es ermöglicht wird, die Tests bei einer Code-Änderung immer sofort
auszuführen.
Ein Paket von Regressionstests sollte idealerweise erstellt werden für jedes Modul, auf allen hierachischen Modul-Ebenen — d.h. Regressionstests sind automatisierte Modultests.
Dokumentation is meines Erachtens lebenswichtig für Software die eine gewisse Komplexität übersteigt, u/o die nicht nur einmalig angewendet wird sondern längerfristig nutzbar und erweiterbar sein sollte. Das Abliefern von Software ohne Dokumentation beschränkt meines Erachtens sehr stark den Wert der Investition in ihre Entwicklung. Eine übersichtliche und einsichtliche Dokumentation macht die Software zugänglich für Wartung, Änderung und Weiterentwicklung, und öffnet so die Investition für einen breiteren und allgemeineren Einsatz.
Eher relativ unüblicherweise für einen Software-Entwickler, schreibe nicht
nur gern Software, sondern auch gern Texte — nämlich Texte die Einsicht
übermitteln in Mechanismen, Algorithmen, und Logik der Aufbau, von Software
oder von anderen Arten technischer/
Dokumentation ist an erster Stelle natürlich Teil meiner normalen Arbeit als
Software-Entwickler.
Jedoch ich biete auch als Dienst an, Software und Algorithmen die ich nicht
selbst entwickelt habe zu dokumentieren. Genauer: Was ich anbiete ist,
die Logik und Mechanismen zu dokumentieren wie eine Software intern funktioniert;
das heißt: Design- und Algorithmik-Dokumentation.
In dieser Doku-Dienstleistung habe ich
enige Erfahrung.
Ich arbeite mich sehr schnell ein in neue Software und Algorithmen. Es
kann die Qualität der Dokumentation erhöhen wenn sie geschrieben wird von
einer Person die von außen reinkommt mit einem frischen Blick — denn als
Entwickler kann es passieren dass man so tief in der Sache drin ist dass man
beim Schreiben Sachen übersieht die zum Verständnis wichtig sind für den Leser.
Meine Doku-Dienstleistung umfasst nicht: Benutzer-Handbücher, und rein
formale Dokumente wie z.B. Testberichte.
Meine Stärke liegt darin, praktische und funktionierende Lösungen zu finden für
konkrete Probleme. Das Problem wird in den meisten Fällen am Anfang nur
noch vage formuliert sein, und es ist Teil meiner Arbeit und meines Berufs,
die Problemformulierung zu einem klaren Stand zu bringen. Jedoch der
Auftrag sollte ein ein konkretes, praktisches, und messbares Ziel
haben, das bekannt und gegeben ist, wenn auch Anfangs nur sehr vage und
abstrakt formuliert. Zum Beispiel, die Aufgabe die die zu erstellende
Software zu erledigen hat sollte bekannt und gegeben sein (wenn auch nur vage
und abstrakt). Für solche Aufträge finde ich immer eine funktionierende
und saubere Lösung.
Forschung ist eine meiner Stärken, aber funktioniert bei mir nur
Zielorientiert.
Die Erfahrung hat gezeigt, dass ich nicht gut geeignet bin für Aufträge die
nur daraus bestehen, ein Thema im Allgemeinen zu erforschen, d.h. in denen
nicht schon am Anfang ein konkretes zu lösendes End-Ziel gegeben ist (wenn
auch vage formuliert).
Meine Stärke ist gerade, gegeben ein konkretes Problem, über Forschung
und über konzeptuelles out-of-the-box thinking, zu Lösungen zu kommen
die auch auf abstrakter konzeptueller Ebene innovativ sind und sauber
zusammenstecken. Die Konkretheit des Zieles wirkt nur fördernd auf meine
abstrakte Problemlösungsfähigkeit, und beschränkt sie keineswegs.
Mein Hintergrundwissen umfasst u.A.:
Mein Schwerpunkt ist C/C++, von ANSI C bis zu dem C++11 Standard für C++.
C++ ist für mich zurzeit etwas "natürlicher" als reines ANSI C. Meine
Bandbreite reicht von C++, über C, bis zu Optimierung von Code-Fragmenten in
assembler.
Jedoch ich denke und entwerfe ausgesprochen viel eher auf abstrakter Ebene als auf
Code-Ebene. Allgemeine Konzepte, ein übersichtlicher logischer Entwurf,
und ein guter Programmierstil sind m.E. wichtiger als die Details einer
Programmiersprache.
Auch in assembler ist es möglich, gut strukturierten Code zu entwickeln. Und
auch in procedure-oriented Programmiersprachen ist es möglich objekt-orientiert
zu entwickeln.
C++ ist eine sich stetig entwickelnde Programmiersprache, und nimmt ständig neue
Elemente auf, die Entwickler schon seit langer Zeit über eigene Hilfskonstrukte
kodiert haben.
Weitere Kenntnisse: Prolog, formale Spezifikationssprachen (Z, predicate calculus);
sehr gute Kenntnisse in Postscript; und natürlich XML und SQL.
Ich bin sehr analytisch eingestellt:
Was mich im Allgemeinen und am stärksten motiviert, ist zu entdecken wie neue und
für mich noch unbekannte Sachen funktioneren, d.h. über welche Mechanismen.
Für mich ist es wichtig, in diesen Mechanismen ein genaues
Einsicht zu erreichen. Ich glaube, aus Erfahrung, dass wenn eine
Problemstellung sauber verstanden wird, dass dann die Lösung sich fast "von
selbst" präsentiert.
Zwar bin ich ein ausgesprochen abstrakter Denker, jedoch Theorie ist für mich
nicht Selbstzweck sondern Hilfsmittel:
Das einzige das für mich am Ende
zählt ist dass Lösungen erzeugt werden die in der realen Welt tatsächlich
praktisch funktionieren. Die Praxis ist der einzige wirkliche Test.
In persönlicher Umgang bin ich sehr unbürokratisch und kleinunternehmerisch
eingestellt. Was funktioniert und produktiv ist, hat für mich Vorfahrt
über Formelles.
Programmiersprache Level Jahre Erfahrung
C++ expert 20
C expert 20
assembler gut 3
matlab gut 2
Java gut 4
FORTRAN (-77 und -90) gut 1 - 2
BASIC, VBA gut 3
UNIX shell scripts (sh/bash/ksh/C) gut 5
Python adequat 1 - 2
Perl adequat 1
Pascal einige Erfahrung 1 - 2
Lisp einige Erfahrung 1
Smalltalk einige Kennisse 1