Enbugging — Was ich auf den Delphi-Tagen erzählen will

“Wenn Debugging der Vorgang ist, Fehler aus einem Programm zu entfernen, dann ist Programmierung der Vorgang, Fehler in ein Programm einzubauen.” Und ich fürchte das stimmt. Debugging ist manchmal nervig, auf jeden Fall aber zeitaufwändig. Und dabei sind wir doch eigentlich selbst schuld: Mühelos bauen wir Fehler in unseren Code ein, damit wir diese dann wieder mit viel Mühe erkennen, lokalisieren und beheben können.

Schön wäre es doch, wenn wir die Fehler gar nicht erst einbauen würden. Wir tun das nicht bewusst. Man könnte das jetzt einfach als Nachlässigkeit oder “Versehen” abtun, aber meistens ist es mehr: Wir erzeugen Bedingungen unter denen Bugs leicht entstehen. Wir tricksen und quasi selbst aus, indem wir unsere Programme so entwerfen, dass wir fast unausweichlich Bugs machen müssen, wenn wir nicht höllisch aufpassen. Uns ist das nicht immer bewusst, aber es ist so. Einige solche Bugschleudern hab ich selbst schon fabriziert.

Um dem zu begegnen gibt es IMHO drei Dinge, die wir tun können:

1. Verstehen wie Code funktioniert, welche Probleme und Fallstricke existieren und welche Fehler man machen kann.
2. Verstehen welche Fehler man persönlich macht.
3. Bedingungen erzeugen, unter denen Bugs nicht so leicht entstehen oder zumindest schneller erkannt werden.

Das ist mehr oder weniger das, was ich auf den diesjährigen Delphi-Tagen in Köln erzählen will. Einen Vorgeschmack gibts schonmal hier: Download: Enbugging-preview (Größe: 383.76 kB; bisher 164 mal heruntergeladen)

Ich hab viel zu erzählen und weiß noch nicht ganz, ob ich davon noch etwas kürzen oder verändern muss. Deshalb erstmal nur das Kapitel zur Einführung. Den Rest gibts dann als finale Version nach oder kurz vor den Delphi-Tagen. Das, was ich hier zeige, ist zwar mit Abstand das langweiligste Kapitel, aber zumindest ist ein Inhaltsverzeichnis dabei, sodass man schonmal nen Eindruck gewinnen sollte, ob es sich lohnt, mir zu zu hören.

Alles in Allem werde ich nichts bahnbrechend Neues vorstellen. Das ist teilweise Erstsemester-Stoff [1], aber ich werde versuchen, aufzuzeigen, warum das wirklich praxisrelevant ist. Relevanter als ich das im ersten Semester erkannt hab. Es wird ne Menge Beispiele geben, die auch mit Abstand die meiste Arbeit gemacht haben und hoffentlich den ein oder anderen Aha-Effekt erzeugen. Mal sehen, ob mir das gelingt. Zumindest ist das mein Ziel.

Vorab kann ich schonmal sagen, dass ich den Titel geklaut hab. Und zwar von diesem sehr lesenswerten Artikel: The Art of Enbugging von Andy Hunt und Dave Thomas.

[1] OK, wirklich nur teilweise

Eiffel: Das Esperanto unter den Programmiersprachen

Ich gehöre zu denjenigen, die sich gerne immer mal wieder eine neue Programmiersprache ansehen. Nicht um in jeder dieser Programmiersprachen letztendlich auch produktiv zu arbeiten, aber um mal “übern Tellerrand zu gucken”.

Das Ganze ist nicht nur interessant, sondern hat auch den Vorteil, dass man sehr viel über unterschiedliche Herangehensweisen und Programmierkulturen erfährt. Die einzelnen Sprachen unterscheiden sich nicht nur in der Syntax, sondern auch in der Denkweise, wie Probleme gelöst bzw. Code geschrieben wird. Sowas ist manchmal augenöffnend und kann auch mal helfen, kreative Lösungen für schwierige Probleme zu finden, die man in “seiner” Programmiersprache hat.

Das heißt natürlich nicht, dass man anfangen sollte, die eigene Sprachkur zu missachten. Im Gegenteil: Manchmal ist es sinnvoller, eine schlechte, aber allseits bekannte Lösung zu verwenden, als eine elegante, die für andere Entwickler “fremdartig” wirkt. Code schreibt man i.d.R. ja nicht nur für sich selbst, sondern auch für die anderen Entwickler im Team, etc.

Aber für schwierige, nicht-alltägliche Probleme kann man auch mal eine kreative Lösung gebrauchen. Und dafür ist es ganz gut, wenn man mit anderen Sprachen und Programmierkulturen in Kontakt kommt. Außerdem ist es mit Programmiersprachkulturen ähnlich wie mit natürlichen Sprachen: Sie verändern und beeinflussen sich gegenseitig und das ist eine Bereicherung. [1]

Ich bin nicht der einzige, der so denkt. In “The Pragmatic Programmer” [2] geben Andy Hunt und Dave Thomas den Rat: “Learn at least one new language every year.” Und da komm ich sogar in etwa hin. Die meisten davon kann ich nicht (mehr) wirklich gut. Wirklich produktiv einsetzen kann ich momentan davon nur ne Hand voll. Aber darum gehts ja auch nicht.

Nun, ich hab mich jetzt ein bisschen mit Eiffel beschäftigt. Aus Zeitgründen leider nur oberflächlich. So hab ich praktisch keinen echten Code geschrieben sondern nur Tutorials und Code gelesen. Das bedeutet natürlich, dass viel von der Syntax bald wieder verflogen sein wird. Aber wie gesagt: Darum gehts mir gar nicht.

Ich hab also einen Eindruck von Eiffel bekommen. Um jetzt mehr als ein Bauchgefühl vermitteln zu können, müsste ich wohl wirklich mal ein paar hundert Zeilen Code schreiben. Aber dafür hab ich momentan keine Zeit. Hier also nur mal ein erster Eindruck. weiter lesen »

Softwareentwicklungs-Prinzipien: Eine Übersicht

Ich hatte ja schon angekündigt, dass ich mein Versprechen auf den letzten Delphi-Tagen in Raten erfüllen werde. Immer mal wieder landet etwas zu den Softwareentwicklungs-”Daumenregeln” oder -Prinzipien hier im Blog. Vielleicht werde ich die Artikelserie irgendwann in ein Tutorial packen oder auf andere Weise verarbeiten. Mal sehen.

Zuerst aber ist mal ein grober Überblick notwendig und diesen möchte ich hier geben.

Wie schon mehrfach erwähnt, sehe ich Softwareentwicklung als das ständige Ausbalancieren von “Daumenregeln” oder “Prinzipien”. Solche Daumenregeln gibt es eine ganze Menge. Ich hab bisher schon so an die hundert dieser Regeln zusammengetragen und werde die hoffentlich auch bald mal sortieren und hier posten. Diese Daumenregeln können sehr unterschiedlich sein. Manche sind sehr allgemein, andere hingegen auf ganz bestimmte Probleme spezialisiert. Viele dieser Daumenregeln, sind einfach nur Spezialisierungen oder Abwandlungen anderer, aber es ist auch nicht selten, dass sich einzelne Regeln widersprechen. Es ist dann jeweils ein geeigneter Mittelweg, ein Kompromiss zu suchen. Man kann diese Regeln auch als Kräfte betrachten, die in unterschiedliche Richtungen ziehen. So gesehen ist das Ziel ein Kräftegleichgewicht.

Das was ich hier schreibe, ist keine für alle Ewigkeiten gültige Wahrheit, an der nicht gerüttelt werden darf. Im Übrigen bin ich der Meinung, dass es so etwas gar nicht gibt. Aus nahe liegenden Gründen werde ich hier also meine persönliche Sichtweise auf die Softwareentwicklung darstellen. Man darf hier gerne anderer Meinung sein. Vieles ist Ansichtssache und auch wenn manche der Prinzipien (nicht aber alle) weithin anerkannte Lehrmeinung sind, sollte man trotzdem überlegen, ob man diese nachvollziehen kann. Im Übrigen wird man diese hier vorgestellten Daumenregeln nur dann wirklich anwenden können, wenn man die für zumindest einigermaßen sinnvoll erachtet.

Ich beziehe mich hier hauptsächlich auf objektorientierte Softwareentwicklung, prinzipiell gilt das meiste aber auch für andere Programmierparadigmen, bzw. sind leicht auf solche übertragbar. Jetzt will ich erstmal einen groben Überblick über die meiner Meinung nach wichtigsten Prinzipien geben. Genaueres folgt dann irgendwann mal in einzelnen Artikel zu den jeweiligen Prinzipien.

Die drei obersten Daumenregeln

“Die obersten drei Regeln der Softwareentwicklung”, wie ich sie hier mal nennen will, beschreiben, wie man mit den ganzen hier vorgestellten Regeln umgehen soll. weiter lesen »

Gefangen, nicht gefunden! #10

Informatik

• Das Windows-Setup wird auch immer schlechter. Letztens hab ich meinem Cousin nen DualBoot eingerichtet. Bei der Linux-Installation Platz für Win gelassen, dann Vista-Setup gestartet. ==> “Es wurde kein Systemvolume gefunden, das den Installationskriterien entspricht.” Äh… die gewählte Partition war die erste auf der einzigen Platte und war auch schon NTFS-partitioniert und auch groß genug. Was bitte fehlt da noch? Und die Fehlermeldung ist natürlich mal wieder ziemlich nichts-sagend. Die allwissende Müllhalde hat diverse merkwürdige Vorschläge geliefert (u.a. mit XP-CD booten und von da aus formatieren). Letztendlich hat es sich heraus gestellt, dass man händisch mit diskpart die Partition als aktiv markieren musste. Und dann hats geklappt. Warum bitte kann das Windows-Setup das nicht selbst tun?
• Zwischendurch hab ich schon gedacht, die Spam-Bots werden intelligenter. Statt sinnlos 20 Kommentare mit Potenzmittel-Werbung zu hinterlassen, kommen jetzt viel weniger und mache davon sind sogar schon auf deutsch und verzichten auf Werbung im Kommentar. Und mit ein bisschen Glück passt der Text sogar zum Artikel. Beispiel:
  

  An sich ne gute Sache, ich frag mich nur, ob das auch dauerhaft brauchbar bleibt.

  Das war ein Kommentar in meinem Artikel Opera-Profil mit Windows teilen. Der Text passt perfekt. Würde man ja fast freischalten, wenn da nicht der Benutzername “Spiel Roulette” wäre und ne einschlägige Website angegeben wäre. Außerdem wurde der Artikel zwei Mal kommentiert. Mit gleicher Mail-Adresse, unterschiedlichem Benutzernamen und anderem – diesmal etwas weniger gut passenden – Text. Schlussfolgerung: Entweder sind die Spam-Bots schlauer geworden oder sie haben mich in die Liste gepackt “Sinnloses Bombardement hilft nix, aber vielleicht isser ja blöd genug, deutsche Kommentare zu akzeptieren.” Immerhin hab ich jetzt weniger Spam zu löschen… Mittlerweile wird der Spam aber auch schon wieder mehr und wieder dümmer. *seufz*

• Ich lese gerade The Pragmatic Programmer und dort ein sehr interessantes Kapitel über Exceptions. Dazu muss ich auch mal was bloggen. Das hat auf jeden Fall einen eigenen Blog-Post verdient. Das Buch kann ich jedenfalls weiter empfehlen.

Anderes; heute: Recht

• Ich höre in der Uni gerade (freiwillig) Zivilrecht. Vom Prof. empfohlen: Tele-Jura. Ist ganz interessant und gut gemacht.
• Ein interessanter Vortrag von Udo Vetter (lawblog) über rechtliche Aspekte des Bloggens.