Interessanter Artikel für die Führungsebene
[QUOTE=mogel]Interessanter Artikel für die Führungsebene
So kann man denen das nicht kommunizieren. Eher so: “Alter verwirrender Code schlecht, bäh, bäh, aber viel Gewinn, Kohle, Scheffel, Reibach wenn wir das verbessern. Zum Abschluss meiner Powerpoint-Präsentation möchte ich noch einige Bilder nackter Frauen herzeigen, damit alle wieder aufwachen.”
Benutzt wer die erwähnte Software?
Habe hie zwar Sonar eingefuehrt, wird aber fleissig ignoriert, daher werde ich dieses Plugin wohl nie testen… zumindest hier 
Sonar ist super, wie ich finde. Das Problem ist wirklich, dass zu wenige auf solche Dinge achten. Da muss man im Team einfach für sensibilisieren. Dieses Plugin kannte ich allerdings noch nicht.
ich habe beim Kunden den Build-Server so gestrickt das deren Quellcode automatisch mit cppcheck geprüft wird. Nur wechseln die ständig die Position im SVN wo deren Quellcode liegt (fragt bitte nicht warum). Für Java nehme ich findbugs
Ich muss mal Sonar testen. cppcheck hat letztens eine unitialisierte Variable nicht gefunden - was sich natürlich in C++ entsprechend bemerkbar macht -.-
[QUOTE=mogel]ich habe beim Kunden den Build-Server so gestrickt das deren Quellcode automatisch mit cppcheck geprüft wird. Nur wechseln die ständig die Position im SVN wo deren Quellcode liegt (fragt bitte nicht warum). Für Java nehme ich findbugs
[/QUOTE]
Mein Sonar “Rules” enthalten u.a. auch Findbugs, PMD, CPD, etc. pp. und sind nach Clean Code modifiziert/angepasst.
Sonar hat viele Vorteile gegenueber “nackten” FindBugs, zB. den Verlauf ueber die Zeit zu ueberwachen etc. pp.
Backtrack: Landei hatte … “woanders”… auch mal http://jaxenter.de/artikel/Codequalitaet-Funktioniert-ist-nicht-genug-0 gepostet. Wie auch schon dort kann ich hier nur sagen, dass mir einiges davon ziemlich idealistisch erscheint, und es bei “überschuldeten” Projekten irgendwann einfach keinen Sinn mehr macht, sich über solche Sachen Gedanken zu machen. Man hangelt sich von Release zu Release, und hofft, dass irgendwann der “Schuldenschnitt” kommt (d.h. die Software verkauft wird, damit jemand anderes sich um den Dreck kümmern darf :D). Wenn man solche Werkzeuge aber “frühzeitig” einsetzt, können die vielleicht schon helfen, dem schlimmsten entgegen zu wirken…
Das sehe ich anders. Ein Unternehmen sollte immer versuchen, die Schulden abzubauen. Nur dann lernt man aus Fehlern, die vorher gemacht wurden. Nur so kann man besser werden. Selbst beim “Hangeln von Release zu Release” kann man den Code jeden Tag verbessern.
Ich finde, es macht immer Sinn, sich damit zu beschäftigen. Ich kann auch nachträglich Tests für Defekte schreiben. Ich kann auch nachträglich den Code besser strukturieren. Erst im Kleinen und wenn alle mitgehen auch eingeplant im Großen.
Das Problem ist IME, dass man Dinge wie “minor Refactoring” und “major Refactoring” nur sehr schlecht nach “oben verkaufen” kann.
“Was haben wir davon? Wieviele Features springen dabei fuer uns/Kunden dabei raus?”
Sowas geht IMHO nur, wenn der Leiter der SW Abteilung das fest einplant und nicht erst als einzelposten verkaufen muss.
D.h. wenn man Aufwand fuer Aenderungen in einem Altsystem schaetzt, muessen diese Zahlen bereits enthalten sein und duerfen nicht als “optionaler Aufwand ohne direkten Nutzen” dargestellt werden.
Leider ist der Markt mit “ich machs dir billiger” Firmen ueberschwemmt und nicht selten sind Entscheidungstraeger oft nur deswegen Entscheidungstraeger weil sie die Schiene “schneller und billiger” gefahren sind.
Anosnten kann Refactoring tierischen Spass machen, meist bei Greenfieldanwendungen mit TDD, aber Legacy-System zu aendern ist nicht witzig… vior allem wenn nicht genug Tests vorhanden sind und keiner mehr weiss was das Ding genau koennen soll.
Wenn man jetzt nicht von brutalen Legacy-Systemen ausgeht, die nur hart zu ändern sind, aber von einfachen verschuldeten Projekten, kann man auch gut Refactoring betreiben, ohne es verkaufen zu müssen. Jedes Mal, wenn man ein Stück Code wegen einer Story anfasst, kann man diesen Teil refactoren.
So sehe ich das auch. Allerdings sollten die Firmen bei so etwas mitgehen. Es muss auch dem „Management“ klar gemacht werden, was der Vorteil ist. Und verständlicher Code ist ein ungemein wichtiger Vorteil. Wenn das nicht klar wird, muss man vielleicht die Firma wechseln. Das ist ja aktuell überhaupt kein Problem.