{"id":412,"date":"2008-03-06T15:37:54","date_gmt":"2008-03-06T13:37:54","guid":{"rendered":"http:\/\/www.puls200.de\/?p=412"},"modified":"2008-03-06T15:37:54","modified_gmt":"2008-03-06T13:37:54","slug":"fehlerquellen","status":"publish","type":"post","link":"https:\/\/www.puls200.de\/?p=412","title":{"rendered":"Fehlerquellen"},"content":{"rendered":"<p>Nach inzwischen einigen Jahren in der Bearbeitung von Fehlern bei CRM Software beginnen sich ein paar klare Linien abzuzeichnen. Man kann es sicher verallgemeinern, aber das la\u00df ich erstmal. Wenn man f\u00fcr ein etwas gr\u00f6\u00dferes Projekt verantwortlich ist, bekommt man nat\u00fcrlich auch alle Fehler mit die der Kunde meldet oder die intern entdeckt werden. Durch unser Anfragesystem werden sie in Gruppen klassifiziert, entsprechend den Softwaremodulen bzw. den logischen Einheiten. Beispiel: Materialverwaltung, Kundenstamm, usw.<br \/>\nIn diesen zynischen Zeiten der Gewinnmaximierung steht nat\u00fcrlich immer die Begrenzung der Kosten obenan, das ist bei uns nicht anders. Nachdem das nun eine Zeitlang fr\u00f6hlich ausgewertet wurde kam heraus, was alle schon l\u00e4ngst wu\u00dften: Die Dauerbaustellen machen die meisten Probleme. Nichts ungew\u00f6hnliches soweit. Jetzt werde ich nat\u00fcrlich oft nach der <em>Ursache <\/em>dieser Probleme gefragt (das ist der unangenehme Teil mit der Verantwortung). Die Antwort ist entweder kurz das Symptom (Schludrigkeit, Verschlimmbesserung, Funktionalit\u00e4t nicht kapiert, Seiteneffekt \u00fcbersehen, Inkompetenz (ja, gibt es auch), mehrdeutige Konzeption, Verteilungs- oder Runtimefehler, falsche Versionierung, Altlasten) oder ich versuche mich in einem Vortrag \u00fcber den Grund, weshalb diese Probleme an besagter Stelle geh\u00e4uft auftreten. Im Duell zwischen Konzeption und Entwicklung gibt es nat\u00fcrlich kaum eine Chance, diese Probleme der Konzeption zuzuschieben, so attraktiv es auch erscheinen mag. Aber trotzdem gibt es eine Beziehung zwischen gewissen Konzepten und einem Berg von Programmfehlern. Durch geeignete Konzeptionierung lassen sich diese Engp\u00e4sse n\u00e4mlich bedeutend verringern. So k\u00f6nnte man es machen:<\/p>\n<ul>\n<li>Abl\u00e4ufe und Verfahren sollten m\u00f6glichst gleich sein. Das erwartet der Benutzer und erleichtert der Entwicklung die Verwendung von gemeinsamen Code.<\/li>\n<li>Der Anwendungsfall sollte so simpel wie m\u00f6glich sein. Ernsthaft. So <strong>simpel<\/strong> wie es geht. Aber wenn es nun mal komplex ist? Dann in primitive Einzelteile zerhacken. Denn die Entwickler sind Simpel, und die Kunden erst recht ;-)\n<\/li>\n<li>Nie, gar nie, einfach <em>nie im Leben <\/em>sollte eine neue Funktionalit\u00e4t quasi als \"Trittbrettfahrer\" auf eine vorhandene Funktion \"aufgepfropft\" werden. Das geschieht etwa so: <em>\"Huch, der Kunde will gern eine neue Funktion XYZ, aber hier haben wir ein Modul, das macht schon XY, also machen wir doch eine kleine Erweiterung daf\u00fcr und basteln eine Markierung rein, mit der man unterscheiden kann, ob das Modul jetzt XY wie gewohnt oder XYZ macht\"<\/em>. Das ist zun\u00e4chst sicher plausibel, denn die Kosten bleiben im Rahmen. Doch sp\u00e4ter geht die Entwicklung weiter und bald wird klar, da\u00df hier zwei ein Bett teilen, die nicht zusammen geh\u00f6ren. Nur ist leider in der Zwischenzeit alles viel zu kompliziert geworden, als da\u00df man sie noch mit vertretbaren Aufwand trennen k\u00f6nnte.<br \/>\nIch meine das nicht aus Entwicklungssicht (da ist die Lage anders: gemeinsamer Code in die Basisklasse, usw.) sondern aus konzeptioneller: \"<em>Die Extrabonuspunkte sind ja so \u00e4hnlich wie die Sonderbonuspunkte.. naja, also, dann k\u00f6nnten wir sie ja zusammen in einer Maske anzeigen nur im Falle von XYZ mu\u00df dann in der Spalte ZZZ anders gerechnet werden....<\/em>\". Man ahnt ja, worauf das hinausl\u00e4uft.\n<\/li>\n<\/ul>\n<p>Auf seiten der Entwicklung wird nur zu gern der Fehler gemacht, den Code unter entwicklungsm\u00e4\u00dfigen Gesichtspunkten in verschiedene Module zu unterteilen. Beispiel: \"Diese drei Funktionen verwenden alle die Library XY, von daher m\u00fcssen sie in ein Modul zusammengefa\u00dft werden\". Nat\u00fcrlich gibt es immer wiederkehrende Elemente, die man gut zusammenfassen kann: Datenbankkonnektivit\u00e4t, Kommunikationsmodule, Standardmasken. Aber nur zu oft passiert es, da\u00df zum Beispiel zur Aufl\u00f6sung des Referenzpfads irgendein Modul hinzugef\u00fcgt wird, nur weil dort eine Methode ist, die man gerne verwenden w\u00fcrde. Die L\u00f6sung hie\u00dfe eigentlich Refakturierung und wird leider nicht von allen Kollegen verstanden und ausgef\u00fchrt. Das Ergebnis ist dann, da\u00df auf einmal Abh\u00e4ngigkeiten zwischen Dingen bestehen, die aus Anwendersicht nichts miteinander zu tun haben. Der Kunde versteht dann (zu Recht) nicht, warum z.B. f\u00fcr die Funktion des Wareneingangs das Kundendienstmodul ben\u00f6tigt wird.<br \/>\nHier gilt einfach, die Abh\u00e4ngigkeiten so gering wie m\u00f6glich zu halten. Das hat den Vorteil, da\u00df man es leichter hat, wenn z.B. nur einzelne Programmteile portiert werden sollen. Ich hab gut reden! Darf ich doch jeden Tag mit einer Codebasis arbeiten, an der o.g. Probleme zuhauf vorhanden sind. Ein Grund brauche ich halt um das mal loszuwerden ;-)<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Nach inzwischen einigen Jahren in der Bearbeitung von Fehlern bei CRM Software beginnen sich ein paar klare Linien abzuzeichnen. Man kann es sicher verallgemeinern, aber das la\u00df ich erstmal. Wenn man f\u00fcr ein etwas gr\u00f6\u00dferes Projekt verantwortlich ist, bekommt man &hellip; <a href=\"https:\/\/www.puls200.de\/?p=412\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0},"categories":[23],"tags":[],"_links":{"self":[{"href":"https:\/\/www.puls200.de\/index.php?rest_route=\/wp\/v2\/posts\/412"}],"collection":[{"href":"https:\/\/www.puls200.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.puls200.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.puls200.de\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.puls200.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=412"}],"version-history":[{"count":0,"href":"https:\/\/www.puls200.de\/index.php?rest_route=\/wp\/v2\/posts\/412\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.puls200.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=412"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.puls200.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=412"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.puls200.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=412"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}