.NET Blog   ·   .NET Casts   ·   .NET GUI Foren   ·   .NET BlogBook   ·   WPF Blogger   ·   visual studio one   ·   ASP.NET professional

  • ACHTUNG - NEUES BLOG

    Ab sofort steht unter http://devtyr.norberteder.com mein neues Blog zur Verfügung. Dieses Blog wird nicht weiter betreut, bleibt aber erhalten. Neue Eintr%auml;ge erfolgen nur mehr im neuen Blog. Kommentare werden ebenfalls nicht mehr behandelt. Wer weiterhin meinen Einträgen und Aktivitäten folgen möchte, möge bitte RSS-Feeds, Verlinkungen etc. an die neue Location anpassen.
Download .NET Essentials Installer
Trickkiste

Mit Unit Tests zur einfacheren und intuitiveren Verwendung

15.09.08 - Entwicklung, Diskussionen, Software Testing, Qualitätsmgmt.
Beitrag von Norbert Eder
 Unit Tests sind ein Thema bei dem es Entwickler wie Ärzte halten: Gehe zu vier Ärzten und erhalte fünf Meinungen. Bei Unit Tests läuft es auf dieselbe Art. Also wie jetzt wirklich?

Mit den in Visual Studio integrierten Test-Möglichkeiten sollte man meinen, dass der Entwickler nun wirklich keine Ausrede mehr parat hat, Unit Tests nicht zu schreiben. Weit gefehlt. In vielen Projekten werden derartige Tests noch immer vernachlässigt bzw. im schlimmsten Fall nicht angedacht. Einen der Hintergründe - das Thema Aufwand - hatte ich schon einmal versucht, aus dem Weg zu räumen. Oft erscheinen Tests jedoch auch zu kompliziert, oder es wird diese großartige Unterstützung schlicht einfach nicht bedacht.

Für Unit Tests spricht aber nicht nur, dass damit die Fehlerfreiheit von Teilen der Software verbessert und laufend überprüft werden kann. Der Entwickler kann damit sich selbst, dem Team und neuen, zukünftigen Mitgliedern die Arbeit ebenfalls wesentlich erleichtern. Wie denn das?

Der Eckpfeiler daran ist, sich vor der tatsächlichen Implementierung eines Arbeitspaketes Gedanken zu machen, wie die resultierenden Klassen getestet werden können. Idealerweise werden die Tests vor der Entwicklung dieser Teile geschrieben, muss aber nicht zwingend passieren. Da sich der Entwickler nun im Vorfeld schon Gedanken über die Verwendung macht, wird daran gefeilt, bis eine leichte, intuitive Verwendung möglich ist. Schließlich möchte niemand 10 Zeilen Sourcecode schreiben, nur um eine einfache Berechnung auszuführen. Das Ergebnis ist also ein klares, einfach verständliches Design, welches sowohl die gestellte Aufgabe erfüllt und zudem nach der Implementierung voll funktionsfähig ist. Fehlen Gedanken zur Anwendung, kann letzterer Punkt nicht immer sichergestellt werden. Änderungen am Design sind daher im Nachhinein nötig und führen mitunter sehr schnell zu einer Verwässerung des ursprünglichen Designs.

Der Nachteil daran ist einfach erklärt: Neben der Notwendigkeit, sämtliche Dokumentationen zu ändern (Design Dokument etc.) hat sich durch die spätere Änderung das Design eventuell so stark verändert (meist durch Work-Arounds), dass die Code-Teile nicht mehr intuitiv zu verwenden sind. Team-Kollegen, neue Mitstreiter oder eventuelle Kunden, die programmiertechnisch damit in Berührung kommen, müssen sich lange durch die Dokumentation quälen anstatt durch einen ersten schnellen Tests die Funktionsweise zu verstehen. Eine einfache Sache kann also schnell zu einer Katastrophe ausarten.

Der weitere Ablauf liegt ebenso auf der Hand: Irgendwann wird ein anderer findiger Entwickler diesen Sourcecode zur Überarbeitung markieren. Es entsteht ein Arbeitspaket mit der Prioritätsstufe niedrig - wenn sich einmal Zeit findet. Bis dieser Tag angebrochen ist (in der Regel nie) werden an diesen Stellen vermutlich zahlreiche Funktionserweiterungen implementiert. Ein einfaches Austauschen ist somit auch nicht mehr möglich. Treten zu einem späteren Zeitpunkt gerade hier vermehrt Fehler auf, wird ein alter Spruch missbraucht: Das ist im Laufe der Zeit so gewachsen..

Als Tipp kann ich daher nur jedem Entwickler mitgeben: Bereits im Vorfeld sind Gedanken über die spätere Verwendung von Code-Teilen notwendig. Sinnvoll kann es natürlich sein, nach einem ersten Grob-Design mit einem Testfall zu beginnen. Anhand dessen kann abgeleitet werden, ob die angedachte Verwendungsweise tatsächlich gut ist, oder ob Nacharbeit notwendig ist. Nach zwei bis drei Iterationen über diese Punkte hat sich ein Verständnis für dieses Arbeitspaket entwickelt und auch die Verwendung sollte weitaus klarer und intuitiver sein, als dies vermutlich beim ersten Ansatz der Fall war.

  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Einfache Verbesserungen für kleine Teams

11.09.08 - Diskussionen, Patterns, Projektmgmt., Qualitätsmgmt.
Beitrag von Norbert Eder
 Immer wieder, wenn ich mit kleinen Entwickler-Teams zu tun habe, sehe ich, dass dieselben Probleme vorhanden sind. Meist dreht es sich um die folgenden Punkte:
  • Das Projekt wurde nicht ausreichend spezifiziert. Der Auslöser für das Projekt kennt die genauen Anforderungen, brachte diese jedoch nie vollständig in ein Dokument. Sollte ein Dokument vorhanden sein, findet dieses oft nicht den Weg zum Entwickler. Daher erhält dieser oft unzureichende Informationen, um das Projekt erfolgreich durch zu führen.
  • Keine Arbeitspakete. Soll ein Projekt durchgeführt werden, muss eine Analysephase durchlaufen werden. Im Zuge dieser Phase sind Arbeitspakete zu definieren. Diese erleichtern zum Einen die Abgrenzung zu anderen ToDo's und ermöglichen eine Kontrolle. Zeitschätzungen dafür werden sehr oft ebenfalls nicht angegeben. Deswegen gestaltet sich eine Kontrolle schwierig.
  • "Drauf-los-Entwicklung". Die Vorgaben sind bekannt und es wird einfach einmal entwickelt. Zukünftige Anforderungen werden nicht in Betracht gezogen, auch wird erst bei der Integration der einzelnen Teile in Erfahrung gebracht, ob diese überhaupt miteinander harmonieren. In den meisten Fällen sind größere Änderungen notwendig.
  • Kontrolle. Zum Thema Kontrolle gibt es zwei Wege die hauptsächlich durchschritten werden: Entweder findet keine Kontrolle statt (oder erst ca. 2 Wochen vor Auslieferung) oder es wird versucht das ultimative Kontrollsystem einzuführen. Oft wird hierbei jedoch auf notwendige Vorarbeiten vergessen, wodurch eine Kontrolle gar nicht durchgeführt werden kann (Arbeitspakete in Kombination mit Zeitschätzungen als Beispiel).
  • Ressourcen-Planung. Ressourcen müssen geplant werden. Freie Kapazitäten sollten vor Annahme eines Projektes bekannt sein. Ebenso sollte bekannt sein, dass eventuell zwischenzeitlich Ressourcen für andere Projekte abgestellt werden müssen - und zu welchem Umfang. Viele Teams werden von plötzlicher Ressourcen-Knappheit überrascht, da plötzlich Entwickler zu anderen Projekten abgezogen werden müssen. Es gilt daher eine saubere Ressourcen-Planung durch zu führen und - wenn notwendig - frühzeitig für Ausgleich zu sorgen.
  • Der fehlende Architekt. Nicht jeder Softwareentwickler ist zum Architekten geboren. Großes Wissen und viel Erfahrung ist notwendig, um zukunftssichere Grundgerüste zu entwickeln. Gerade kleine Teams haben oft keinen "gelernten" Architekten zur Verfügung. In diesem Fall kommt es für die meisten Projekte billiger, sich zumindest für das Grundgerüst eine entsprechende Person zu zu kaufen.

Dies sind einige Punkte, auf die ich immer wieder in der Praxis stoße. Die einen Teams leben dabei nach dem Motto "Es wird schon irgendwie gehen", wobei die anderen definitiv nach Verbesserung streben. Ich persönlich kann nur jedem Team bzw. jedem kleinen Softwareunternehmen raten, sich zumindest für ein paar Stunden einen Spezialisten zu zu kaufen. Sind bisherige Abläufe bekannt (grobe Abläufe lassen sich in kurzer Zeit ohne Weiteres feststellen), können selbst kleine Änderungen große positive Auswirkungen auslösen.

Will ein Unternehmen dafür kein Geld an externe Personen vergeben, dann sollten zumindest meine aufgeführten Punkte mit der eigenen Vorgehensweise reflektiert werden. Alleine daraus lassen sich einige Verbesserungsmaßnahmen ableiten.

  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Nervig hoch 2: FxCop + WPF

14.05.08 - Entwicklung, Qualitätsmgmt., .NET, WPF
Beitrag von Norbert Eder
 Ein Großteil des FxCop Ruleset ist bei meinen Projekten ständig aktiviert und hilft so, den Code sauberer, sicherer und performanter zu halten.

Aber gerade in Kombination mit WPF ergeben sich daraus natürlich einige Probleme oder besser gesagt, Ärgernisse. Nehmen wir die Regel CA1823. Diese besagt, dass ein Feld nicht verwendet wird, oder ihm nie ein Wert zugewiesen wurde. Derartige Regeln werden bei mir grundsätzlich als Fehler und nicht als Warnung behandelt.

Wie kommt man nun dazu, sich über diesen Fehler zu ärgern? Ganz einfach. Man vergebe einem Element einen x:Name. Dadurch wird es im generierten File (.g.cs) angelegt, damit aus der Codebehind-Datei darauf zugegriffen werden kann. Eventuell möchte man dies jedoch nicht, sondern vergibt dem Element bloß einen Namen, um per Binding darauf zuzugreifen.

Und schon taucht dieser Fehler auf und schreit nahezu danach, suppressed zu werden - was ja eigentlich vermieden werden sollte.

Wäre schön, wenn sich diesbezüglich zukünftig etwas tun würde ..

  8 Kommentare - 16001 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


.NET BlogBook Ausgabe 6

14.04.08 - Entwicklung, Diskussionen, Patterns, Software Testing, Projektmgmt., Qualitätsmgmt., .NET, Grundlagen, Base Framework, WPF, ASP.NET, Silverlight, Mobile Devices, Datenverwaltung, Visual Studio, Allerlei, Microsoft Office, SQL Server
Beitrag von Norbert Eder
 Ab sofort steht die 6. Ausgabe des .NET BlogBooks zur Verfügung. Insgesamt stehen nun fast 330 Seiten an puren Informationen und Praxiswissen zur Verfügung.

Noch dazu wurden einige Anregungen aufgegriffen. Es gibt ein neues Cover (ein herzliches Dankeschön an 69° media solutions). Ebenfalls wurden unnötige dunkle Stellen entfernt, die beim Ausdrucken maximal Toner verbrauchen, sonst jedoch keinerlei Wirkung erzielen.

Hauptsächlich wurde das BlogBook um Wissen rund um die Windows Presentation Foundation erweitert, aber auch andere Punkte kamen hinzu. Ein Blick lohnt sich allemal.

Weitere Informationen sind auf der Homepage unter http://www.dotnet-blogbook.com zu finden.

Für Anregungen, Wünsche und (konstruktive) Kritik haben wir natürlich weiterhin ein offenes Ohr.
  6 Kommentare - 1363 mal angesehen   |  1 Trackbacks   |  Permalink  |  Trackback-URL


Aufwandsschätzungen verbessern

04.02.08 - Entwicklung, Diskussionen, Qualitätsmgmt.
Beitrag von Norbert Eder
 Aufwandsschätzungen gehören quasi zur täglichen Arbeit eines Softwareentwicklers – zumindest sollte es das. Gerade für den Projektmanager ist es nicht unerheblich, über den zu planenden Aufwand Bescheid zu wissen, als auch feststellen zu können, wie der derzeitige Stand ist. Daher müssen Aufwände für erfasst werden für:
  • das gesamte Projekt
  • daraus resultierende Komponenten
  • daraus resultierende einzelne Tasks


Kontrolle der Aufwände


Einer der wichtigsten Aspekte daran ist es, dass die ursprünglich abgegebenen Schätzungen ständig neu betrachtet und gegebenenfalls aktualisiert werden. In vielen Unternehmen unterbleibt dieser Schritt, wodurch das Projektmanagement oft keine aktuellen Zahlen zur Verfügung hat und Verzögerungen nicht sofort erkannt werden.
Aber auch der Entwickler selbst kann von der Überarbeitung der Aufwandsschätzungen profitieren. Zumindest sollten die ursprünglich geschätzten Aufwände mit dem tatsächlichen Aufwand verglichen werden. Dadurch werden Verzögerungen festgehalten und stellen einen wichtigen Ansatzpunkt zur Analyse dar. Unter anderem können dadurch folgende Fragen beantwortet werden:
  • Bei welchen Aufgaben wurden die ursprünglichen Schätzungen überschritten?
  • Betrifft dies ähnliche Aufgaben bzw. die Arbeit mit speziellen Techniken/Technologien?
  • Welche Probleme sind dafür verantwortlich?

Auf Basis der Antworten zu diesen Fragen können Schritte eingeleitet werden, um die Aufwandsschätzungen beim nächsten Mal zu verfeinern bzw. um grundlegende Probleme aufzuarbeiten. Dies hilft nicht nur dem gesamten Projekt, sondern jeder einzelne Entwickler bekommt ein immer besseres Gefühl für die zu schätzenden Aufgaben und schließlich können dadurch eigene Schwachpunkte gefunden und bekämpft werden. Es resultiert also eine Verbesserungsliste der eigenen Fähigkeiten. Ganz gut, wenn man bedenkt, dass damit die Qualität der eigenen Arbeit wesentlich verbessert werden kann.

Gegenüberstellung


Welche Daten sollten nun gegenüber gestellt werden? Ich kann hier hauptsächlich aus meiner persönlichen Erfahrung sprechen und wiedergeben, welche Daten von mir ausgewertet werden:
  • Ticket (aus Ticketing-System)
  • Ursprüngliche Schätzung
  • Gesamter Aufwand
  • Abweichung in Stunden
  • Abweichung in Prozent
  • Bei Problemen eine entsprechende Angabe darüber

Diese Liste kann in entsprechenden Tools (beispielsweise Excel) gut erstellt und gewartet werden. Ebenfalls lassen sich entsprechende Diagramme anfertigen, die anhand des Verlaufs über zahlreiche Aufgaben hinweg eine Tendenz anzeigen und somit auch erkennen lassen, ob Reaktionen auf etwaige Verzögerungen tatsächlichen Einfluss ausüben.

Fazit


Aufwandsschätzungen müssen gemacht werden und in vielen Fällen passiert dies auch durch den tatsächlichen Entwickler. Damit dieser nun an seinen Fähigkeiten arbeiten kann empfiehlt es sich, die eigenen Angaben und Leistungen auch ständig zu messen und zu bewerten. Mit einfachen Mitteln können hier sehr gute Ergebnisse erzielt werden.

  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Code-Dokumentation einfach gemacht!

14.11.07 - Entwicklung, Diskussionen, Qualitätsmgmt., .NET, Grundlagen, Visual Studio, Allerlei, Tools, 3rd Party Tools
Beitrag von Norbert Eder
 Die Dokumentation des Sourcecodes ist ein wichtiger - aber leider oft vernachlässigter - Bestandteil der Softwareentwickler. Vor allem Frameworks wollen gut dokumentiert werden, damit ein beliebiger Entwickler sofort damit loslegen kann, ohne sich lange einarbeiten zu müssen.

Nun ist es so, dass Visual Studio hier nicht besonders viel mitbringt. Lediglich das Schreiben der Kommentare in XML-Files, die später via IntelliSense eingebunden werden. Ein Tool zur Generierung von Hilfe-Dateien wird nicht über die IDE zur Verfügung gestellt. Aber es gibt auch andere Lösungen.

Benötigte Tools/Frameworks


Bevor mit der Generierung der Sourcecode-Dokumentation gestartet werden kann, müssen einige Frameworks/Tools installiert werden. Zentraler Bestandteil für diese Variante ist Sandcastle. Hier nun eine Liste der zu installierenden Produkte:

Hinweise: Der HTML Help Workshop ist nur für die Generierung von HTML 2.x Dokumentationen notwendig und muss nur installiert werden, wenn sich dieser noch nicht auf dem Rechner befindet.

Installation


Die ersten beiden Produkte kommen jeweils als MSI-Pakete daher. Daher sind diese sehr einfach in der Installation. Der HTML Workshop kann normal herunter geladen werden und muss nur in der Projekt-Konfiguration im Sandcastle Help File Builder in der Eigenschaft HtmlHelp2xCompilerPath angegeben werden. Nun noch GhostDoc installieren und schon ist man fast fertig.

Vorarbeiten


Wichtig ist, dass beim Build-Prozess XML-Kommentare ebenfalls generiert werden. Dazu ist die Einstellung in den Eigenschaften der jeweiligen Assemblies unter dem Punkt Build zu setzen.



Nun müssen natürlich auch noch sämtliche Kommentare geschrieben werden. Um sich viel Arbeit zu ersparen kann nun GhostDoc eingesetzt werden. Dieses unterstützt bei der Generierung der Dokumentation und liefert auch Vorschläge, die in einigen Fällen noch weiter angepasst werden müssen, aber grundsätzlich ist damit eine solide Basis geschaffen.



Generierung der Dokumentation


Mit Hilfe der Sandcastle Help File Builder GUI kann nun auf einfache Art und Weise ein Dokumentations-Projekt angelegt werden. Hierzu sind die notwendigen Assemblies anzugeben. Die vorhandenen XML-Dateien werden automatisch hinzugeladen und müssen daher nicht extra angegeben werden.

Wurden nun beispielsweise Frameworks á la NUnit, NLog etc. verwendet wird der Builder beim Ausführen beanstanden, dass referenzierte Assemblies nicht gefunden werden können. Anstatt diese über Add hinzuzufügen, empfiehlt es sich, diese im Builder unter Dependencies einzupflegen.

Nun müssen noch Einstellungen getroffen werden, welche Templates für Generierung verwendet werden, ob 1.x, 2.x generiert werden soll, oder gar eine Website und viele weitere Einstellungen wie Überschriften usw.

Ein wichtiger Punkt ist unter Namespaces zu finden: Hier ist es möglich einzustellen, welche Namespaces in der Dokumentation aufscheinen und es kann zusätzlich eine Beschreibung für diese eingegeben werden.

Wurde alles konfiguriert, kann die Generierung gestartet werden. Diese dauert zwar ein wenig länger als man erwartet, dafür ist das Ergebnis (vorausgesetzt es wurde brav dokumentiert) sehr fein und kann für die Weitergabe oder interne Verwendung herangezogen werden.



Fazit


Mit Hilfe dieser wenigen Tools und ca. 10 - 15 Minuten Installation und Konfiguration kann ein komplettes Dokumentations-System aufgesetzt werden. Die Dokumentation selbst kann uns leider niemand abnehmen, aber das soll keine Ausrede sein. Ich persönlich setze obige Kombination schon länger ein und bin bis dato sehr zufrieden.

Sicherlich wird es Möglichkeiten geben, dies weiter zu verbessern, wer hier also eine andere Konfiguration einsetzt bzw. Vorteile für seine Lösung anbieten kann, der sei hiermit eingeladen, mir dies mitzuteilen. Ebenfalls würde mich interessieren, ob ihr Code-Dokumentationen schreibt, oder nicht, inklusive einer kurzen Begründung.
  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


FxCop in der Version 1.36 Beta verfügbar

11.10.07 - Qualitätsmgmt., .NET, Allerlei
Beitrag von Norbert Eder
 Ab sofort steht die 1.36 Beta von FxCop zur Verfügung. Unter anderem sind folgende Punkte inkludiert:
  • 200+ bug fixes that reduce noise, missing analysis and rule crashes
  • Support for analyzing anonymous methods and lambda expressions
  • New option for skipping analysis over tool generated code
  • Better support for C++/CLI and the Compact Framework
  • Language 'friendly' API names in the UI and resolutions (ie Visual Basic syntax if running over a Visual Basic binary)
  • New globalization, design and usage rules
  • Performance improvements that cut analysis by 2x and use half as much memory
  • Documentation that is now available on MSDN

Auf zum Download.
Auf zur Dokumentation

Weitere Informationen sind auch im Visual Studio Code Analysis Team Blog verfügbar.
  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


NAnt: Solution aus Visual SourceSafe aktualisieren

27.09.07 - Entwicklung, Software Testing, Qualitätsmgmt., .NET, Allerlei
Beitrag von Norbert Eder
 Zu NAnt gibt es ja das Zusatzpaket NAntContrib welches den Task vssget zur Verfügung stellt. Dadurch kann die letzte Version aus dem SourceSafe geladen werden.

Blöderweise funktioniert dies nur bei Visual SourceSafe 6.0d, jedoch nicht mehr mit SourceSafe 2005. Der Grund hierfür liegt darin, dass nicht doe Commandline-Funktionalität verwendet wird, sondern die Visual Studio Integrations-Schnittstelle.

Grundsätzlich wäre das nicht weiter schlimm, würde eine Side-by-Side-Installation der Versionen 6.0d und 2005 möglich sein. Ist es aber nicht. Die zuletzt installierte Version setzt den verwendeten Provider. Ergo auch keine wirkliche Lösung.

Abhilfe schafft hier:

1. NAntContrib selbst anpassen und die notwendigen Änderungen durchführen (denn das Projekt scheint auch nicht mehr wirklich aktiv zu sein)

2. Visual SourceSave 6.0d installieren und nicht 2005 verwenden

3. Einen alternativen Weg finden, beispielsweise diesen Vorgang über einen MSBuild-Task abzubilden, wobei hier dann insgesamt zwei Build-Werkzeuge ins Spiel kommen - auch nicht optimal.

Wird der komplette Prozess auf einem eigenen Server ausgeführt kann dieser ja entsprechend konfiguriert werden. Darin liegt nicht das Problem. Vielmehr ist es nervig, wenn auf der lokalen Maschine Tests durchgeführt werden müssen (Debugging etc.). Klar kann hier eine VM verwendet werden, ist aber vielleicht auch wie mit Bomben auf Tauben schießen.

Hat hier jemand vielleicht einen entsprechenden Tipp parat um NAntContrib auch mit SourceSafe 2005 zum Laufen zu bewegen, speziell den vssget-Task?

Zusätzlich gehe ich einmal davon aus, dass NAntContrib in Verbindung mit dem Team System wohl auch eher ein Problem sein wird.

  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Resultiert mangelhafte Software teilweise aus Kritikunfähigkeit?

08.08.07 - Entwicklung, Diskussionen, Qualitätsmgmt.
Beitrag von Norbert Eder
 Eine Frage die sich mir immer wieder und immer häufiger stellt. Niemand will Software die nur so vor Fehlern strotzt. Entwickler wollen erfolgreiche Anwendungen schreiben. Aber was hat das jetzt mit der Fragestellung zu tun?

Der Weg zu guter Software führt nicht nur über das Testing derselben. Jahrelange Erfahrung und ständiges Lernen tragen ihren Teil dazu bei. Von Heute auf Morgen schreibt niemand eine perfekte Software. Da gehört schon einiges an Lernerei dazu. Nun trifft man im Internet immer wieder auf Personen, die mit Kritik nicht umgehen können - denn ihre Lösung ist definitiv die beste. Grundsätzlich muss sich jeder bewusst sein, dass es immer wieder jemanden gibt, der noch besser ist und entsprechende Tipps geben kann (sofern er dies tut). Darüber sollte man froh sein, da der eigene Horizont dadurch erweitert wird und es einem hilft, eine bestimmte Problematik aus verschiedenen Blickwinkeln zu erfassen. Aber was tun, wenn dies jemand nicht anerkennen möchte? Meiner Meinung nach stehen zwei Möglichkeiten zur Verfügung:

- Ignorieren
- Ausdiskutieren

Ich persönlich stehe ja eher zu zweiter Variante. Warum? Nun, wird eine Lösung, die zwar funktioniert, aber beispielsweise Sicherheitsprobleme mit sich bringt, nicht verbessert, lernen andere davon. Dies kann im Endeffekt darin resultieren, dass sich dieser Lösungsweg im Lernenden manifestiert und dieser Ansatz fortan immer verwendet wird. In jeder neuen Anwendung, über Jahre hinweg. Problematik? Jede dieser Anwendungen enthält ein potentielles Sicherheitsrisiko. Wird die vorgeschlagene Lösung jedoch von jemandem verbessert, kann sich der Werte Leser auf Basis der geführten Diskussion selbst ein Bild davon verschaffen und alle aufgebrachten (Gegen)Argumente analysieren. Verwendet wird zukünftig meist die bessere Variante (und natürlich könnte diese weiter verbessert werden).

Wichtig ist an dieser Stelle nur - und das ist ein weiterer Knackpunkt - dass sich der Lernende auch tatsächlich damit beschäftigt. Jemandem, der lediglich auf der Suche nach einem Code-Schnipsel ist damit er ein Problem schnell lösen kann, welches er ohnehin nicht umsetzen will, kann man ohnehin wenig bis nichts beibringen. Aber allen Lernwilligen sollte die Chance geboten werden, korrekte Informationen zu erhalten als auch die notwendige Unterstützung. Schließlich hilft dies der gesamten Softwareindustrie und nicht zuletzt den Benutzern, unserer Kundschaft.
  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Rude Q&A - Die etwas andere FAQ

26.06.07 - Entwicklung, Diskussionen, Qualitätsmgmt.
Beitrag von Norbert Eder
 Frequently Asked Questions (FAQ) sind hinreichend bekannt. Was aber hat es mit dem Begriff Rude Q&A auf sich? Sehr einfach erklärt.

Zu jedem Projekt (Software oder nicht) können tonnenweise Fragen gestellt werden. Manche sind für alle von Interesse (typischer Fall für eine FAQ), manche sind unangenehm und würden am liebsten nicht beantwortet werden bzw. sind ohnehin nicht für die Allgemeinheit bestimmt (sinnvoll für eine Rude Q&A). Zusammenfassend: Eine Rude Q&A enthält alle unangenehmen Fragen zu einem Produkt, Unternehmen etc.

Was bringt das nun? Fragen sind da, um sich mit ihnen zu beschäftigen, und sie auch zu beantworten. Vor allem unangenehme Fragen werden oft nicht beantwortet, sei es aus eigener Angst heraus oder bedingt durch andere Gründe. Fakt ist jedoch, dass man auf alle Fragen eine Antwort parat haben sollte. Durch die Beschäftigung mit einer Frage wird also eine Vorbereitung betrieben, die sich im Falle des Falles auf jeden Fall auszahlt. Zudem empfiehlt es sich, die notierten Fragen von Zeit zu Zeit zu überarbeiten, denn schlechte Antworten sind oft schlimmer, als gar keine.

via Scott Berkun

  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL



Zurück Weiter