Peter Bucher Ralf Westphal

Blog

Nutze den Augenblick
und teile der Welt mit, was Du zu sagen hast.

prio.conference 2009: Von der Idee zur fertigen UI – für Entwickler

Donnerstag, 29. Oktober 2009, 17:29 Uhr
Permalink | Kommentare (1) | Kommentare als RSSRSS

In den vergangenen beiden Tagen fand die prio.conference statt – zum ersten Mal seit ihrem Bestehen allerdings nicht im Kurhaus von Baden-Baden, sondern im Marriott Hotel in München.

Im Gegensatz zu vielen anderen Konferenzen ist die prio eine Konzeptkonferenz, das heißt, jedes Jahr beschäftigt sie sich mit nur einem ausgewählten Thema – dieses wird aber mit sehr viel Liebe zum Detail behandelt. Nachdem die Agenda in den vergangenen Jahren eher von abstrakten Themen wie Softwarequalität und Softwarearchitektur geprägt war, wurde für 2009 das Thema User Interface ausgewählt.

Wie bereits im vergangenen Jahr war ich auch in diesem Jahr mit einer Session im Konzept-Track vertreten. Meine Session

Von der Idee zur fertigen UI – für Entwickler

behandelte dabei die Frage, wie man zu einer gut bedien- und benutzbaren UI kommt, wenn man als Entwickler auf sich allein angewiesen ist und keinen dedizierten Designer zur Hand hat.

Kernelement dieser Session waren daher die beiden Begriffe User Model und Program Model, die für eine gute User Experience miteinander in Einklang gebracht werden müssen.

Auch dieses Jahr hat meine Session sehr viele Interessierte angezogen; die Session war mit ungefähr 120 Teilnehmern äußerst gut besucht. Im Wesentlichen habe ich in der Session die folgenden Punkte behandelt:

  • Entwickler vs Designer
  • UI-Design ist kein Grafikdesign
  • Was macht eine gute UI aus?
  • UIs kontrollieren
  • UIs sind nicht intuitiv
  • User Model vs Program Model
  • Usabilitytests
  • Auswahlmöglichkeiten
  • Konsistenz von UIs
  • Benutzer lesen keine Handbücher
  • Benutzer sind unsicher mit der Maus
  • Benutzer merken sich nichts

Insgesamt bin ich sehr zufrieden, wie alles gelaufen ist, und das Feedback, das ich bislang von den Teilnehmern erhalten habe, zeigt mir, dass die Session informativ und unterhaltsam zugleich war und positiv aufgenommen wurde.

Abschließend möchte ich noch dem Team von der prio, allen voran Ralf Westphal als Konferenzmanager, Tilman Börner als Chefredakteur der dotnetpro und den Damen der Veranstaltungsorganisation für die sehr beeindruckende Konferenz und die sehr gute Vorarbeit danken.

Stirnrunzeln über “Bugtracking ist sinnlos”

Mittwoch, 21. Oktober 2009, 09:33 Uhr
Permalink | Kommentare (5) | Kommentare als RSSRSS

Ilker Cetinkaya hinterfragt in seinem aktuellen Blogeintrag den Sinn von Bugtacking und schließt mit einem provokanten Fazit:

Bugtracking ist sinnlos!

Für ihn steht der Verwaltungsaufwand, der für ein entsprechendes System notwendig ist, in keinem Verhältnis zum Nutzen – zumindest dann nicht, wenn man ohnehin agile Methoden wie XP oder Scrum einsetzt.

Sein Vorschlag zum Umgang mit Bugs lautet:

Wenn ein Bug wirklich ein wichtiger Bug ist, dann wird er sofort gefixed. Alles andere ist entweder nicht wichtig oder wird dann erst wichtig, wenn die wichtigeren Dinge schon erledigt sind.

Doch nicht nur das Bugtracking, auch das –reporting hinterfragt Ilker. So schlägt er zusätzlich vor,

ein leichtgewichtiges Bugreporting [zu] etablieren und die Entscheidung über den Fix oder No-Fix des Bugs schnell herbei[zu]führen

Insgesamt verwundern mich diese Vorschläge sehr, denn es gibt einige Aspekte, die Ilker vollständig ignoriert: Die Entscheidbarkeit, die Nachvollziehbarkeit und zuletzt auch die Transparenz.

Er geht davon aus, dass für jeden Bug sofort entschieden werden kann, ob dessen Relevanz genügt, um zeitnah behoben zu werden. Die Entscheidung, ob ein Bug dermaßen relevant ist, dass er sofort beseitigt wird, wird in der Regel möglich sein.

Im Endeffekt bedeutet das nämlich, dass all jene Bugs gefixt werden, die bei Verwendung eines Bugtrackingsystems mit oberster Priorität und als höchst kritisch gekennzeichnet worden wären.

Die Frage ist aber, was mit einem Bug geschehen soll, der diese Kriterien nicht erfüllt. Dazu schlägt Ilker vor:

Ist er nicht wichtig genug (also ist entweder ein anderer Bug oder ein anstehendes Feature wichtiger), so wird der Report weggeworfen.

Interessanterweise schreibt er direkt im nachfolgenden Satz:

Der Benutzer wird benachrichtigt dass der Fehler momentan nicht korrigiert wird.

Beachtenswert an diesem Satz ist für mich das Wort momentan – das heißt, Ilker räumt ein, dass es sinnvoll sein könnte, den Bug zu einem späteren Zeitpunkt zu fixen. Doch wie merken sich die Entwickler diesen Bug und dessen Details, wenn sie ihn nirgends notieren dürfen?

Es liegt auf der Hand, dass dabei über kurz oder lang Bugs vergessen werden, oder dass zumindest Details verloren gehen, die zur Behebung potenziell wichtig gewesen wären.

Interessant finde ich auch, welches Resultat Ilker anführt: Durch den Verzicht auf Bugtracking und die sofortige Entscheidung wird direkt an den Benutzer kommuniziert, ob der von ihm gemeldete Bug behoben wird oder nicht. Dies nennt er:

Ehrlich, sachlich, klar.

Ohne Frage wird die Transparenz über die sofortige Entscheidung erhöht – jegliche sonstige Transparenz geht allerdings verloren – nicht nur für die Entwickler, auch für den Benutzer:

  • Ohne Bugtracking weiß niemand, welche Bugs vor langer Zeit abgelehnt wurden, insbesondere aus welchen Gründen dies geschehen ist.
  • Ohne Bugtracking weiß niemand, wie oft welcher Bug auftritt – dies kann man nur noch nach persönlichem Gutdünken schätzen.
  • Ohne Bugtracking bekommt der Benutzer nur die Aussage, dass sein Bug momentan nicht behoben wird – was damit zukünftig geschieht, kann er nicht nachverfolgen.
  • Ohne Bugtracking weiß niemand, wie viele gefundene, aber ungefixte Bugs es in einer Software gibt.

Diese Liste ließe sich noch lang fortsetzen. Worauf ich hinauswill, wird aber deutlich: Bugtracking ist nicht nur nicht sinnlos, es ist sogar enorm wichtig für den Erfolg eines Projekts!

In einem einzigen Punkt kann ich Ilker allerdings dennoch zustimmen:

[…] wenn man wirklich das Produkt stetig weiterentwickeln möchte auch immer sich zum Ziel setzen muss, ein möglichst fehlerfreies Produkt auszuliefern.

Dieser Aussage stimme ich vollkommen zu – lediglich die Konsequenzen, die er daraus zieht, kann ich weder nachvollziehen noch gutheißen.

.NET Professionals im Profil: Peter Bucher

Donnerstag, 15. Oktober 2009, 09:37 Uhr
Permalink | Kommentare (2) | Kommentare als RSSRSS

Peter Bucher arbeitet als Webentwickler für die Firma cobra in Konstanz am Bodensee und und wurde von Microsoft bereits drei Mal in Folge als MVP für ASP und ASP.NET ausgezeichnet. Nachdem er zunächst mit ASP Classic gearbeitet hat, kam er über DirectX zu C# und .NET. Peter Bucher engagiert sich aktiv in der Community und leitet die .NET Usergroup Konstanz-Kreuzlingen. Sie erreichen ihn über seine Webseite und sein Blog.

Golo Roden: Peter, wie bist Du zur Softwareentwicklung gekommen? Wie und wann hast Du angefangen?

Peter Bucher: Ich habe ursprünglich eine Ausbildung im Bereich Hard- und Softwaresupport gemacht. Jedoch habe ich mich auch schon vor dieser Ausbildung sehr viel mit PCs, das heißt mit Hard- und Software, beschäftigt und wusste daher schon recht viel. Im Laufe der Ausbildung wurde es mir mit der Zeit langweilig, weil sich die Arbeiten und Probleme dort häufig wiederholten, ich schon vieles in diesem Bereich kannte und ich daher nicht mehr sehr viel dazulernen konnte.

Darum habe ich dann angefangen, mich mit Programmierung zu beschäftigen. Das Interessante an der Softwareentwicklung ist, dass sie ein stetiges Lernen von neuen Dingen erfordert, was mir zusagt.

Zuerst habe ich ein wenig mit Visual Basic 6 herumgespielt, danach dann mit VBScript, Classic ASP – einfach deshalb, weil die Webentwicklung beziehungsweise die Beschäftigung mit Design, HTML und CSS ohnehin schon länger ein Hobby war und mir die statischen Seiten nicht mehr genügten. Mein hauptsächliches Themengebiet war also VBScript beziehungsweise Classic ASP, zunächst nur privat, doch dann konnte ich einige kleinere Projekte für meine Lehrfirma erledigen.

Irgendwann stieß ich dann auf ASP.NET Zone, was damals noch ASP Forum hieß, und habe dort technische Fragen gestellt. Später, als ich dann schon mehr wusste, habe ich das wieder an die Community zurückgegeben, indem ich auch anderen Mitgliedern geholfen habe.

Im zweiten Ausbildungsjahr bekam ich zum ersten Mal die Auszeichnung zum MVP für ASP und ASP.NET. Zu dieser Zeit habe ich mich noch nicht all zu viel mit .NET beschäftigt, und meine ersten Gehversuche waren wenig erfolgreich, da es einfach zu viel neue Themen auf einmal waren. Jedoch wollte ich mich dennoch in .NET einarbeiten, da es interessant aussah und es zudem der nächste logische Schritt war.

Daher habe ich mich eines kleinen Tricks beholfen, um in .NET einzusteigen. Weil es mit ASP.NET nicht auf Anhieb geklappt hat, versuchte ich es statt dessen mit Windows Forms und DirectX, um in C# und VB.NET hineinzukommen. Genau genommen war ASP.NET deshalb zu groß für den Anfang, weil mit ASP.NET das ganze Paradigma von Windows Forms wie beispielsweise Events sowie die Statusverwaltung dazu kam, zusätzlich zum Lernen einer neuen Programmiersprache, OOP, ...

Dieses Vorgehen war eine gute Idee, denn damit konnte ich Erfahrungen mit Profilern sammeln, sowie lernen, was beachtet werden muss, damit eine Anwendung schnell und zügig ausgeführt wird. Quasi nebenbei habe ich mich dadurch sehr gut in C# und das .NET Framework eingearbeitet.

Nachdem ich einigermaßen sattelfest in C# und OOP sowie dem .NET Framework war, wagte ich mich wieder an den Umstieg auf ASP.NET, was dann auch wunderbar klappte. Seitdem arbeite ich hauptsächlich mit ASP.NET WebForms, ab und zu mit ASP.NET MVC und – wenn ich die Zeit dazu finde – ein bisschen mit der Manged DirectX API namens XNA.

Golo Roden: Du hast gesagt, dass .NET der nächste logische Schritt gewesen sei – welche Rolle nehmen in dieser Hinsicht Silverlight beziehungsweise RIA-Technologien im Allgemeinen für Dich ein?

Peter Bucher: In dem Moment, als ich mit .NET angefangen habe, überhaupt keine. Erst ein wenig später kam dann der AJAX-Hype, sowie der Flash- und Silverlight- beziehungsweise RIA-Hype. Ich war und bin immer noch konservativ eingestellt, wenn es um RIA-Technologien geht, dasselbe auch bei Javascript: Nur so viel wie nötig und so wenig wie möglich.

Diese Technologien setze ich deshalb nur dann ein, wenn es Sinn ergibt. Komplette Anwendungen mit Silverlight oder Flash machen meines Erachtens in den seltensten Fällen Sinn, vor allem nicht im Web. Dazu habe ich auch schon bei dem Streitgespräch Heißt die Zukunft RIA? von uns eine Meinung abgegeben.

Dabei muss jedoch immer unterschieden werden, ob eine Anwendung im Inter- oder im Intranet ausgeführt werden soll, wie auch, was die Anwendung letztlich leisten muss.

Im Allgemeinen kann ich sagen, das ich sicherlich etwas mit Silverlight entwickeln werde, sobald es erforderlich ist und ich mich in diese Technologie einarbeiten soll. Allerdings denke ich, dass wenn sich jemand bereits auf einen Bereich von .NET spezialisiert hat, sollte er sich möglichst nicht davon wegbewegen. Natürlich ist eine Sicht auf die anderen Technologien wichtig und hilfreich, aber sich ernsthaft einzuarbeiten halte ich nicht für rentabel bei einer schon sehr stark vorhandenen Spezialisierung.

Golo Roden: Wie siehst Du denn die Marktchancen für ASP.NET im Vergleich zu PHP oder Java? Warum sollte jemand, der heute anfängt, sich mit Webentwicklung zu beschäftigen, gerade auf ASP.NET setzen?

Peter Bucher: ASP.NET und Java gehören eher in den Enterprisemarkt, PHP hingegen findet sich meistens bei kleineren Firmen und vor allem bei Hobbyisten.

Das heißt jedoch überhaupt nicht, dass es nur dort hingehört oder nur dort zu finden ist. So sind auch größere Anwendungen bereits mit PHP umgesetzt worden, ebenso gibt es kleinere Anwendungen mit ASP.NET als verwendeter Technologie.

In den letzten Jahren wurde ASP.NET auch für Privatanwender sowie kleinere und mittlere Firmen interessanter. Es gibt sehr gute Angebote von Microsoft wie beispielsweise, dass die Express-Edition von Visual Studio Web Developer kostenlos abgegeben wird. Damit kann schon fast alles erreicht werden. Es fehlt lediglich die Möglichkeit, Addins zu nutzen, was vermutlich die größte Schwäche ist – jedoch hindert das letztlich niemanden daran, etwas in ASP.NET umzusetzen.

Darüber hinaus wurden die Hostinggebühren für Windows Server immer geringer, denn es gibt inzwischen spezielle Versionen von Windows Server, die für das Web optimiert beziehungsweise limitiert sind und daher günstiger zu haben sind. Für Startups oder kleinere Firmen unter zehn Mitarbeitern gibt es zudem seit neuestem sogar ein Programm namens WebsiteSpark, in dessen Rahmen Microsoft kostenlose Lizenzen für alle Entwicklungswerkzeuge, Grafikwerkzeuge sowie Serverbetriebssysteme für ganze 3 Jahre anbietet.

Neben diesen Gründen für ASP.NET gibt es jedoch auch noch einen technischen Aspekt, und dabei werde ich keine Nachteile der anderen Technologien aufzeigen, sondern nur Vorteile von ASP.NET sowie der .NET-Platform: Wer mit ASP.NET entwickelt, entwickelt letztlich mit .NET-Sprachen und dem .NET Framework. Wer mit Windows Forms, WPF oder Silverlight entwickelt, ebenso. Wer mit Windows Mobile entwickelt, arbeitet zumindest mit einem Subset des Frameworks – jedoch sind genau die selben Sprachen nutzbar.

Ich möchte darauf hinaus, das sich Entwickler auf eine oder zwei Sprachen sowie ein einziges Basisframework zuzüglich eines zusätzlichen, spezialisierten Frameworks wie ASP.NET, WPF oder ähnliches beziehungweise auf ein Subset des .NET Frameworks fokussieren müssen – nicht mehr und nicht weniger. Damit können sie theoretisch in allen Bereichen arbeiten, vom .NET Micro Framework bis zum .NET Compact Framework, über ASP.NET bis hin zum großen .NET Framwork.

Für Umsteiger erleichtert das einiges und Einsteiger können nach einer gewissen Lernphase mit dem schon vorhandenen Wissen relativ schnell einen anderen Bereich von .NET kennenlernen. Zusätzlich ist es natürlich so, dass .NET und die dafür verfügbaren Sprachen die Vorteile aus den schon vorhandenen Technologien mitgenommen, deren Nachteile aber möglichst nicht übernommen haben.

Golo Roden: Gibt es in ASP.NET entwickelte Projekte, die Dich besonders fasziniert haben – an denen Du eventuell auch beteiligt warst?

Peter Bucher: Mich faszinieren viele Teile eines Projekts. Ein solcher Teil war beispielsweise eine Lizenzverwaltung für eine Webanwendung. Dabei ging es darum, einen Algorithmus zu erstellen, mit dessen Hilfe Lizenzen erzeugt werden können. Dazu schrieb ich dann auch die API, um den Algorithmus zu kapseln und in der Anwendung zu benutzen, sowie natürlich die Integration in die Windows- und die Webanwendung.

Dieses Projekt war ein sogenanntes Greenfield-Projekt, das heißt, ich konnte von der grünen Wiese aus starten und hatte keinen Legacy Code, den ich erweitern musste.

Daneben habe ich privat viele Greenfield-Projekte aufgezogen, darunter viele kleinere Sachen wie beispielsweise eine Bibliothek, die es ermöglicht, Objektlisten direkt als XML zu speichern, das ganze automatisiert und ohne aufwändige Konfiguration. Mein größtes Übungsprojekt, das ich immer wieder von neuem umbaue und daran neue Technologien evaluiere, ist meine private Webseite. Interessant ist dabei auch, dass ich daran viel am Backend gearbeitet habe, dies nach Außen aber überhaupt nicht sichtbar wurde.

Fremde Projekte können mich auch faszinieren, jedoch natürlich nie so, wie etwas selbst geschaffenes, das so funktioniert, wie ich es mir vorgestellt habe und worin viel Liebe zum Detail steckt. Um ehrlich zu sein, ist mir relativ wenig Code untergekommen, von dem ich behaupten könnte, das er mich fasziniert. Zumindest keine komplette Anwendung, kleinere Snippets oder Komponenten schon eher.

Ich bin jetzt beim Thema Codestyle angekommen, und merke das erst jetzt. Fremde Projekte gibt es eine Menge, die mich von ihrem Aufbau, der Komplexität oder wegen ihres APIs faszinieren. Dazu zählen beispielsweise NHibernate, Rhino.Mocks, autofac und SubText, um nur einige zu nennen.

Golo Roden: Ein wesentliches Merkmal der IT ist, dass man beständig mit neuen Entwicklungen konfrontiert wird, und diesen folgen muss. Woher nimmst Du die Motivation, Dich quasi jeden Tag weiterzubilden und mit Neuem zu beschäftigen?

Peter Bucher: Das ist eine sehr gute Frage. Damit habe ich mich persönlich auch schon beschäftigt, darum fällt mir die Antwort relativ leicht. Wenn wir vorne anfangen, ist es wohl am verständlichsten: Ich hatte schon von klein auf einen angeborenen „Tüftlerinstinkt“, habe also alles, was mich interessierte, angeschaut und damit herumgespielt.

Als mein Vater den ersten Computer kaufte, war ich sofort davon fasziniert. Später kam ein zweiter Computer hinzu und ich durfte den alten 386er für mich haben. Das hatte auch seinen Grund, denn vorher habe ich den Computer meines Vaters immer umgestellt, manchmal sogar so viel, dass er nicht mehr gestartet hat.

Mit meinem eigenen Computer habe ich genau dasselbe gemacht und so mit der Zeit natürlich Dinge gelernt, die ich sonst nie herausgefunden hätte. Nach einer gewissen Zeit war es kein Problem mehr, meine gemachten Fehler wieder rückgängig zu machen, also beispielsweise Windows neu zu installieren. Wichtig ist: Ich bin eher praktisch angehaucht, sehr interessiert, probiere sehr viel aus und lerne aus Fehlern.

Ich habe, wie bereits gesagt, mit der Programmierung angefangen, weil mich der Computersupport langweilte und er für mich ausgeschöpft war. Das kann bei der Softwareentwicklung nie passieren – ich weiß, man soll niemals nie sagen, aber hier und jetzt schon. Meine Motivation kommt also aus meinem sehr großen Interesse an der Sache, meinem Tüftlerinstinkt und schlussendlich aus dem Wissensdurst, den ich in mir habe.

Es ist ganz klar, dass irgendwann, irgendwo eine Grenze gezogen werden muss, nämlich dann, wenn sich die Frage stellt: Was lerne ich? Wie lange? Und wofür? Auf Grund meiner Berufslaufbahn, bei der auch mit der MVP-Auszeichung nochmals die Weichen gestellt wurden, habe ich mich komplett auf die Webentwicklung mit ASP.NET spezialisiert und vernachlässige jetzt beispielsweise die Spieleentwicklung, obwohl sie mich nach wie vor noch interessiert.

Zusammengefasst kann ich also sagen: Das Lernen fällt mir in diesem Bereich sehr leicht, weil eben das große Interesse da ist. Ich würde sogar sagen, dsas ich implizit lerne. Kinder lernen sehr schnell und mit großer Leichtigkeit, aber wieso? Weil es sie interessiert, sie haben ein riesengroßes Interesse an fast allem, darum lernen sie alles sehr gut und sehr schnell.

Bei mir ist dieses Interesse auf bestimmte Bereiche im Leben fixiert, bei denen mir das Lernen sehr leicht fällt und auch keine wirkliche Anstrengung bedeutet, im Sinne von: Weil ich es gerne mache. Durch diese Tatsache kann ich mir auch erklären, wieso ich zum Autodidakten geworden bin und mir das meiste selbst beigebracht habe, wobei ich bei anderen lernenden Aktivitäten, wie beispielsweise einem Fach in der Schule, durch den Lehrer beigebracht, niemals eine solche Motivation aufgebracht habe.

Die Motivation kommt also aus den Interessen und aus den vielen kleinen und großen Erfolgserlebnissen, sowie auch durch das wiederum implizite Lernen, während ich anderen in der Community weiterhelfe.

Einen sehr wichtigen Punkt möchte ich noch erwähnen: Das Filtern. Im heutigen Informationszeitalter werden wir geradezu mit Informationen überschüttet. Dabei genügt schon die Informationsflut in der IT-Industrie, privates kann man dabei außen vor lassen. Dort ist es wichtig, am besten das herauszufiltern, was interessiert und einen Nutzen bringen könnte. Wenn das nicht gemacht wird, zerbricht man an der Flut und irgendwann platzt der Kopf, oder man bringt keine Energie für die wirklich wichtigen Dinge mehr auf.

Golo Roden: Wenn sich ein Anfänger heute mit dem Thema Softwareentwicklung befassen will – welche Voraussetzungen sollte er Deiner Meinung nach dafür mitbringen, und was siehst Du als No-Go an?

Peter Bucher: Wenn es darum geht, die Softwareentwicklung als Berufsziel zu haben, kann ich mich eigentlich auf mein Posting vom Streitgespräch Woran erkennt man einen guten Entwickler? beziehen.

Einen Weg, wie man im Lauf der Zeit besser werden kann, wurde auch bereits in einem Streitgespräch, Die Forderung nach Softwarequalität, thematisiert.

Grundsätzlich bin ich der Meinung das nicht jeder Kandidat als Softwareentwickler geeignet ist, sowie ich auch nicht unbedingt beziehungsweise nur bedingt beispielsweise als Schreiner oder Koch geeignet wäre. Das liegt nicht daran, das es jemand nicht könnte, sondern wie er es kann und vorallem wie sehr es ihn interessiert.

Interesse alleine genügt nicht, da von irgendwoher auch die Motivation zur Lernen aufgebracht werden muss. Wie das in meinem Fall aussieht, habe ich bereits beschrieben, aber das kann von Kandidat zu Kandidat natürlich unterschiedlich aussehen.

Ein No-Go wäre die zu einseitige Fixierung auf Theorie oder Praxis. Das kann auf Dauer nicht gut gehen. Wichtig ist also, das schon von Anfang an Theorie und Praxis miteinander verbunden werden, um weiterzukommen.

Zu hohe Anfangsziele beeinträchtigen die Motivation erheblich, auch der Blick zu anderen Entwicklern, die um einiges weiter sind, mit einem Vergleich zu sich selbst, sind meistens ernüchternd. Darum ist es am besten, sich mit sich selbst vor einem Monat oder einem Jahr zu vergleichen, und sich klar zu machen, dass erstens jeder einmal klein angefangen hat und es, egal was man tut, immer jemanden gibt, der besser auf dem Gebiet ist.

Golo Roden: Bei der Vielzahl an Technologien, die es heute gibt: Womit sollte ein Anfänger heutzutage anzufangen?

Peter Bucher: Ich gehe an dieser Stelle nicht auf die Technologien ein, da sonst garantiert irgendjemand nicht zufrieden ist, mit dem was ich sage. Der Anfänger sollte jedoch damit anfangen, womit er ein gutes Gefühl hat und womit er seine ersten Projekziele erreichen kann. Am besten ist es, vor einer Entscheidung für eine bestimmte Technologie ein paar kleinere Prototypen bauen und diese zu vergleichen, denn auf diese Art sieht man schnell, wie sich das Arbeiten mit der Technologie anfühlt und ob sie den Anforderungen standhält.

Wenn es darum geht, in die Softwareentwicklung einzusteigen, sollte im weiteren Verlauf eine Ausrichtung auf den aktuellen Markt stattfinden, das heißt, man sollte sich entscheiden, in welche Richtung man gehen möchte und welche Technologien dafür eingesetzt werden. Schlussendlich ist dann noch die mehr oder weniger finale Entscheidung zu fällen, worauf man sich spezialisieren möchte. Ohne Spezialisierung wird man schließlich zu keinem Spezialisten, und eine Spezialisierung auf alles ist nicht realistisch.

Dennoch ist es nützlich, zumindest zu einem gewissen Grad auch ein Generalist zu sein, der sich später spezialisiert und zum Spezialisten wird, der allerdings über ein breit gefächertes Allgemeinwissen verfügt.

.NET Professionals im Profil

Sonntag, 4. Oktober 2009, 20:45 Uhr
Permalink | Kommentare (10) | Kommentare als RSSRSS

Softwareentwicklung ist ein faszinierendes Thema – keine Frage. Doch wie gelingt der Einstieg? Wie und womit sollte man beginnen? Woher die Motivation und die Energie nehmen, auf Dauer beständig Neues zu lernen? Welche Voraussetzungen sollte man als Anfänger überhaupt erfüllen, um auf Dauer erfolgreich sein zu können?

All diese Fragen beschäftigen jene, die heute versuchen, einen vernünftigen Einstieg in die Softwareentwicklung zu finden.

Doch diese Fragen haben auch all jene beschäftigt, denen der Einstieg bereits gelungen ist und die sich inzwischen professionell – entweder beruflich oder in der Community –mit Softwareentwicklung beschäftigen.

Warum also nicht einfach fragen, wie es ihnen bei ihrem Einstieg ergangen ist? Welche Hürden sie zu überwindern hatten, welche Erfolgserlebnisse sie hatten, und woher sie ihre Motivation genommen haben?

Dies ist die Idee von .NET Professionals im Profil: Jeden Monat interviewe ich eine Person, die im Bereich .NET professionell tätig ist und sich beruflich oder in der Community einen Namen gemacht hat, zu diesem Thema.

Am 15. Oktober 2009 wird es beginnen …

Vererben oder aggregieren?

Donnerstag, 1. Oktober 2009, 09:37 Uhr
Permalink | Kommentare (2) | Kommentare als RSSRSS

Am 13. Oktober 2008 haben Peter Bucher und ich unter dem Titel Noch Fragen, Bucher? Ja, Roden! angekündigt, jeweils zum ersten eines jeden Monats einen Kommentar zu einem vorab gemeinsam gewählten Thema verfassen zu wollen. Bisher sind in dieser Reihe folgende Kommentare erschienen:

Heute, am 1. Oktober 2009, ist es nun wieder so weit, und unser Thema für diesen Monat lautet:

Vererben oder aggregieren?

So wohl Peter wie auch ich haben uns unabhängig voneinander im Vorfeld unsere Gedanken gemacht, wie wir diesem Thema gegenüberstehen. Peters Kommentar findet sich zeitgleich in seinem Blog, folgend nun mein Kommentar zu diesem Thema:

In der Welt der modernen Softwareentwicklung haben die objektorientierten Sprachen in den vergangenen Jahrzehnten die primäre Rolle eingenommen – von Sprachen wie C++, Java und C# bis hin zu neuen Entwicklung wie Scala: All diese Sprachen unterstützen die objektorientierte Programmierung, teilweise basieren sie sogar gänzlich darauf.

Auch die Literatur hat sich dieser Tendenz angenommen: Kein Einsteiger lernt heute zu programmieren, ohne nicht zumindest einige wenige Schritte in der objektorientierten Programmierung gewagt zu haben. Doch wie wird Objektorientierung üblicherweise vermittelt?

In der Regel werden zunächst die Begriffe Klasse und Objekt erläutert, um sich im Anschluss daran an fortgeschrittene Themen wie Vererbung und generische Typen zu wagen. Prinzipiell ist daran auch nichts auszusetzen – wenn an dieser Stelle nicht in der Regel auch Schluss wäre.

Für die objektorientierte Programmierung stellt Vererbung zwar ein Schlüsselkonzept dar, jedoch wird es in der Praxis bei weitem nicht dermaßen häufig eingesetzt wie einem die Theorie weismachen will: Der Grund hierfür liegt schlichtweg darin, dass Vererbung für zahlreiche Szenarien wenn überhaupt, dann nur bedingt geeignet ist.

Als Begründung hierfür sei das Liskovsche Substitutionsprinzip angeführt, das im Jahr 1993 von Barbara Liskov und Jeanette Wing formuliert wurde, und auch den von Clean Code Developer propagierten Prinzipien angehört.

Frei formuliert besagt dieses Prinzip, dass abgeleitete Typen das gleiche Verhalten aufweisen müssen wie der Typ, von dem sie abgeleitet wurden. Obwohl diese Forderung zunächst trivial und logisch erscheint, wird sie in der Praxis häufig verletzt: Nämlich dann, wenn der abgeleitete Typ die Funktionalität nicht erweitert, sondern einschränkt.

Das Standardbeispiel für eine Verletzung des Liskovschen Substitutionsprinzips ist die Ableitung einer Kreis- von einer Ellipsenklasse – oder analog dazu die Ableitung einer Quadrat- von einer Rechteckklasse. In beiden Fällen schränkt die abgeleitete Klasse die Möglichkeiten zur Manipulation des Objekts semantisch ein.

Auf Grund der Anschaulichkeit und der Verbreitung dieses Beispiels trägt es sogar einen eigenen Namen, so ist es nämlich als Kreis-Ellipse-Problem bekannt.

Ein Beispiel für den gelungenen Einsatz von Vererbung stellen hingegen die diversen grafischen Steuerelemente in .NET dar. Unabhängig davon, welcher technologische Teilbereich betrachtet wird (ASP.NET, Silverlight, WPF, …), das Prinzip ist immer das gleiche: Alle grafischen Steuerelemente sind von einer gemeinsamen Basisklasse Control abgeleitet, die alle allgemeinen Eigenschaften und Methoden definiert.

Generell gilt jedoch, dass Vererbung sparsam eingesetzt werden sollte: Gerade weil es dermaßen leicht ist, eine Klasse von einer anderen abzuleiten, sollte man als Entwickler besondere Vorsicht walten lassen.

Was aber, wenn Vererbung prinzipiell tatsächlich Sinn ergeben würde, der abgeleitete Typ jedoch in seiner Funktionalität eingeschränkt werden müsste?

Als Beispiel hierfür sei eine Rechnungsverwaltung genannt, in der Rechnungen zwar hinzugefügt werden können, aus rechtlichen Gründen jedoch nicht mehr gelöscht werden dürfen, wenn sie erst einmal gebucht sind.

Sicherlich bietet es sich an, zur Datenhaltung der Rechnungen von dem generischen Typ List<T> abzuleiten, schließlich erhält man damit auf einfache Weise nicht nur typsicheren Zugriff auf die einzelnen Rechnungen, sondern erhält quasi zum Nulltarif auch diverse Methoden zum Verwalten, Durchsuchen und Sortieren dieser Liste.

Problematisch ist jedoch, dass nun auch eine Methode Remove zur Verfügung steht, mit der einmal gebuchte Rechnungen wieder entfernt werden könnten – die Aufgabe lautet also, diese Möglichkeit zu eliminieren. Da es in der Vererbung keine Möglichkeit gibt, eine Methode der Basisklasse in einer abgeleiteten Klasse zu entfernen, gibt es de facto nur zwei Möglichkeiten:

  • Zum einen kann die Methode überschrieben werden. In diesem Fall gibt es wiederum zwei Varianten, denn einerseits kann die Methode schlichtweg mit einer leeren Methode überschrieben werden, andererseits könnte in der überschriebenen Variante auch eine NotImplementedException geworden werden. In beiden Fällen wäre das Problem insofern gelöst, dass die Remove-Methode zwar noch aufgerufen werden kann, der Aufruf jedoch keine Auswirkungen auf die Liste hat.
  • Zum anderen kann auf Vererbung verzichtet werden. In diesem Fall stellt sich aber die Frage, wie die Datenstruktur implementiert werden soll – schließlich kann die Lösung aus naheliegenden Gründen auch nicht lauten, dass für solche Fälle eine eigene Liste entwickelt werden muss.

Die Lösung lautet: Es sollte ein eigener Datentyp kreiert werden, der eine Liste als internen Datenspeicher enthält – den Zugriff darauf jedoch über eigene Methoden reguliert. Dieses Verfahren wird als Aggregation bezeichnet, An die Stelle einer is-a-Beziehung tritt also eine is-part-of-Beziehung.

Welche Variante sich für welchen Fall empfiehlt, hängt vom jeweiligen konkreten Kontext ab. Als Faustregel kann jedoch gelten: Wenn der abgeleitete Typ den Basistyp ausschließlich erweitert, sich in semantischer Hinsicht wie der zugehörige Basistyp verhält und es sich tatsächlich um eine is-a-Beziehung handelt, dann kann Vererbung in Betracht gezogen werden.

Im Zweifelsfall wie auch für alle anderen Fälle empfiehlt sich jedoch der Einsatz von Aggregation.