qualitativ hochwertiger Programmcode...
-
Hallo Leute,
ich habe die ehrenvolle Aufgabe bekommen, eine Arbeit (nicht unter 100 Seiten :() zum Thema "Code-Qualitätsmanagement" zu schreiben. Nachdem ich selber noch nicht allzu viele Erfahrung im Programmieren habe, wäre es schön, wenn ihr mir ein bisschen helfen würdet, damit die Arbeit auch ein wenig Praxisbezug bekommt und nicht allzu theoretisch (und damit vielleicht komplett unbrauchbar) wird.
Deswegen hier auch gleich mal zwei bescheidene Fragen:
"Welche Kriterien muss Programmcode (nicht unbedingt die daraus resultierende Software) **erfüllen, damit er Eurer subjektiven Meinung nach qualitativ hochwertig ist?
Und wie stellt ihr sicher, dass er diese Kriterien auch erfüllt?"**
Vielleicht als Anregung hier gleich mal ein paar Dinge, die mir spontan dazu eingefallen sind.
Qualitativ hochwertiger Code:ist (möglichst) fehlerfrei -> er funktioniert -> verschiedene Testverfahren anwenden.
ist einfach und leichtverständlich geschrieben -> damit er wartbar und von anderen verstanden werden kann -> erreichbar durch gute Kommentierung und Einhaltung von Programmierrichtlinien.
wird nur einmal geschrieben und kann dann beliebig oft wiederverwendet werden -> write once use anywhere -> durch Objektorientierung.
Für zahlreiche Antworten wäre ich sehr dankbar!
So, ich gehe dann jetzt mal google füttern und Bücher wälzen.
Vielen Dank für Eure Hilfe!Ciao
shoat
-
mit den 3 punkten bin ich einverstanden ahber ich habe noch 2:
1. er muss schnell sein
2. plattformunabhängig(oder zumindest leicht portierbar)
-
schau dir mal XP (Extreme Programming) an.
da gibt es einige Verfahren zur sicherstellung der code qualitaet.
-
shoat schrieb:
wird nur einmal geschrieben und kann dann beliebig oft wiederverwendet werden -> write once use anywhere -> durch Objektorientierung.
Ist meiner Meinung nach weniger wichtig und wird häufig überbewertet. Außer einigen grundlegenden Systemklassen kann man oft wenig in anderen Systemen wieder verwenden. Gleichzeitig führt diese Forderung oft dazu, daß Entwickler ihren Spieltrieb auf die Wiederverwendung im allgemeinen Fall konzentrieren, statt die Sache einfach für den gegebenen Fall fertig zu machen und zu Potte zu kommen.
Wohlgemerkt: ich spreche von Wiederverwendung über Applikationsgrenzen hinweg. Innerhalb einer Applikation sollte man natürlich schon auf die mehrfache Anwendung einer Idee achten, falls möglich. Aber die Anforderungen an Wiederverwendung sind hier wegen des eingeschränkteren Kontexts natürlich weniger komplex.
Für mich tritt Wiederverwendung als Entwicklungsziel ganz klar an letzte Stelle, an erste Stelle setze ich Fehlerfreiheit, dann kurze Entwicklungszeit, dann Wartbarkeit.
-
die von programmen gemessenen metriken wie "zeilen kommentar/zeilen code" oder "2 punkte für ein if, 5 für ein while und 6 für ein for und dann punkte pro funktion" taugen nix.
-
Marc++us schrieb:
Für mich tritt Wiederverwendung als Entwicklungsziel ganz klar an letzte Stelle, an erste Stelle setze ich Fehlerfreiheit, dann kurze Entwicklungszeit, dann Wartbarkeit.
Ja, aber die ganze Entwicklung zielt wohl nicht auf qualitativ hochwertigen Code ab, sondern darauf, Geld zu verdienen, indem man das resultierende Programm möglichst schnell möglichst oft verkauft.
AFAIK ging es nicht darum, oder?
Kann man eigentlich generell sagen, dass die Produktivität, auf die du hier wohl wert legst, an einigen Punkten ein Widerspruch zur Qualität ist?
-
Gregor schrieb:
Kann man eigentlich generell sagen, dass die Produktivität, auf die du hier wohl wert legst, an einigen Punkten ein Widerspruch zur Qualität ist?
Überhaupt nicht. In einigen Punkten läuft es sogar anders herum - eine monströse Architektur, die mit allen Features für eine etwaige Zukunft aufgeblasen ist wird oftmals viel weniger durchgetestet und bis in alle Ecken erprobt sein, als ein schlankes Programm, das nur genau eine Aufgabe erledigt. Die Suche nach allgemeingültigen Lösungen bläht oft das Design erheblich auf und führt zu mehr Code - und damit auch zu neuen und unnötigen Fehlern.
Es hat mehr mit der Einstellung der beteiligten Entwickler zu tun, inwieweit der obligatorische Spieltrieb ausgelebt wird und ausgelebt werden kann.
Die Frage nach Wiederverwendung stellt sich häufig schon während des Entwurfs. Entwickler die starken Wert auf Wiederverwendung legen beginnen schon ab der Entwurfsphase dies einzuplanen. Nehmen wir mal so ein Beispiel, es ging darum eine Ini-Datei (nicht im Windows-Sinne) mit Einstellungen einzulesen und zu parsen. Ein Entwickler setzt sich daran und entwirft ein allgemeines Design dafür, das beliebige Daten nach diesem Schema parsen und erstellen kann. Das dauert einige Wochen, ist ein genialer Programmteil, der schon fast Qualitäten eines DOM entwickelt und kann in anderen Projekten eingesetzt werden. Eine Lösung die nur für dieses Projekt funktioniert, hätte nur einige Tage gedauert. Aber der andere Weg war natürlich interessanter. In dieser und ähnlicher Form entwickelt sich Wiederverwendung im Alltag sehr häufig.
Kommt noch dazu, daß erstellte Komponenten teilweise wieder verwendbar sind, aber wer weiß davon? Oftmals nur der Entwickler, der sie gemacht hat, aber gleichermaßen findet in kleinen bis mittleren Gruppen (wo noch keine Stabsorganisation existiert) keine zentrale Dokumentation solcher Dinge statt, so daß das Wissen über die Existenz gar nicht vorhanden ist.
Ich halte daher Wiederverwendung als primäres Entwicklungsziel, das bereits ab Designphase berücksichtigt wird, für wenig hilfreich.
Erfolgreiche Beispiele von Wiederverwendung, die ich vor allem bei externen Dienstleistern bisher beobachtet habe, sahen alle eher so aus, daß eine Komponenten (z.B. für grafische Darstellung) in einem Programm erstmalig verwendet wurde und dann bei weiteren Entwicklungen erweitert und angepasst wurde. Aber es war nie von Anfang eine große Bibliothek geplant. Die andere Form erscheint in größeren Projekten, wo man für die Implementierung eines Verhaltens bemerkt, daß man dieses Verhalten vollständig auf vorhandenen Operationen abstützen kann und nicht mehr neu entwickeln muß. Dies ergibt sich oftmals ganz wie von selbst aus einem klaren und robusten und _einfachen_ Design des Grundsystems - daß man Zusatzfunktionen auf diesen aufbauen kann und damit eine Vermeidung von Doppelprogrammierung vorliegen hat. Aber auch dann ist Wiederverwendung kein Primärziel gewesen.
Für mich fasse ich dies mal als Lehrsätze so zusammen:
- Wiederverwendbarkeit ist kein primäres Entwicklungsziel (bei einer Applikation - bei einer Lib natürlich schon), vor allem trifft die Wvwbk Annahmen über zukünftige Applikationen, was gefährlich ist und zu Fehlarbeiten führen kann.
- Robuste und schlanke Designs erlauben das Aufsetzen von zusätzlichen Funktionen unter der Vermeidung von Doppelprogrammierung, was das eigentliche Ziel der Wvwbk auf anderem Wege erreicht.
Du wirst evtl. erkennen, daß einige dieser Argumente z.B. XP oder auch Agile Development entlehnt sind.
-
Ich bin nur ein Hobbyprogrammierer. Aber bei mir funktioniert das mit der wiederverwendung recht gut. Beim ersten Projekt arbeite ich zwar viel länger, als es nötig gewesen wäre, aber die folgenden Projekte gehen wesentlich schneller voran, als es ohne die Arbeit im ersten Projekt möglich gewesen wäre. Und vor allem kann ich mich auf die Fehlerfreiheit verlassen, da es im ersten Projekt ausgibig getestet wurde.
-
Shade Of Mine schrieb:
schau dir mal XP (Extreme Programming) an.
da gibt es einige Verfahren zur sicherstellung der code qualitaet.Danke für den Tip. Ich wollte den Punkt sowieso in meine Arbeit einbringen. Sollte ich Fragen dazu haben, dann wende ich mich vertauensvoll an Dich.
Wenn Du mal Zeit und Lust hast, würde ich mich sehr freuen, wenn Du einmal mit eigenen Worten beschreiben würdest, was Du unter XP verstehst. Die Beschreibungen in den Büchern sind doch immer etwas umständlich! Vielleicht hast Du ja auch ein paar gute Links bzw. Bücherempfehlungen?
Vielen Dank bereits im voraus!
Ciao
shot
-
volkard schrieb:
die von programmen gemessenen metriken wie "zeilen kommentar/zeilen code" oder "2 punkte für ein if, 5 für ein while und 6 für ein for und dann punkte pro funktion" taugen nix.
Ein Schwerpunkt meine Arbeit soll evtl. Metriken sein!
Soweit ich es bisher verstanden habe, dann Metriken eine Möglichkeit eine Programmcode mit Hilfe von bestimmten Berechnungsverfahren zu überprüfen. (Ich habe mich noch nicht sehr damit befaßt!)
Warum taugen sie nix? Wie soll ich meinem Auftraggeber begründen, dass die Mühe hier nicht lohnt?
Wäre schön, wenn Du es mir erklären könntest!
Vielen Dank!Ciao
shoat
-
shoat schrieb:
Wenn Du mal Zeit und Lust hast, würde ich mich sehr freuen, wenn Du einmal mit eigenen Worten beschreiben würdest, was Du unter XP verstehst. Die Beschreibungen in den Büchern sind doch immer etwas umständlich! Vielleicht hast Du ja auch ein paar gute Links bzw. Bücherempfehlungen?
http://www.c-plusplus.net/titelanzeige.php?ISBN=3827317096
http://www.c-plusplus.net/titelanzeige.php?ISBN=3827318327
-
Marc++us schrieb:
Für mich tritt Wiederverwendung als Entwicklungsziel ganz klar an letzte Stelle, an erste Stelle setze ich Fehlerfreiheit, dann kurze Entwicklungszeit, dann Wartbarkeit.
Warum ist Wartbarkeit für Dich so unwichtig? Ist es nicht besser, wenn man seinen Code von Anfang an immer so gut wartbar macht wie möglich?
Soweit mir bekannt ist, muss an eigentlich jeder Software nach der Auslieferung beim Kunden noch ewig oft rumgeschraubt werden. Wenn Wartbarkeit aber im Vergleich zu kurzer Entwicklungszeit unwichtig ist, dann wird Kommentierung und Dokumentation zwangsläufig vernachlässigt. Damit wird die nachträgliche Fehlerbehebung erschwert. So ist zwar die Software eher fertig, aber die Service-Kosten steigen. Unter diesem Gesichtspunkt ist schlecht und sogar unwirtschaftlich kurze Entwicklungszeit wichtiger zu nehmen als Wartbarkeit.
Oder ist in der meiner Argumentation ein Fehler?
Allgemein möchte ich noch sagen, dass ich (persönlich) beim Programmieren wesentlich schneller vorankomme, wenn ich den Programmcode gleich mit ordentlichen Kommentare versehe, keine kryptischen Befehle verwende und ich ihn ordentlich gestalte. Und zwar einfach deswegen, weil ich dann selber besser verstehe, warum ich was an eine bestimmten Stelle wie mache. Dieses Verstehen hilft mir dabei weniger Fehler zu machen bzw. Fehler schneller zu finden. Der Mehraufwand für Kommentierung etc. wird also durch die Einsparung bei der Fehlersuche und durch Fehlervermeidung mehr als wettgemacht.
Wie ist es bei Dir?
Viele Grüße!
Ciao
shoat
-
Hallo Leute,
zuerst mal Danke für die vielen Beiträge!
Wenn ich alles richtig verstanden habe, dann kann man zusammenfassend sagen, dass "guter" Programmcode durch folgende Eigenschaften charakterisiert werden kann:
- Er ist (möglichst) fehlerfrei
- Er ist gut kommentiert / dokumentiert und damit wartbar
- Er hat eine gute Performance / ist schnell
- Er ist plattformunabhängig / leicht portabel
- Er ist (wenigstens teilweise) wiederverwendbarEinige der Punkte sind bestimmt nicht ganz unstrittig. Aber jeder der Punkte kann je nach Anwendung / Betrieb / Entwickler / Einsatzziel ein Qualitätsmerkmal darstellen!
**Fallen jemanden noch andere wichtige Punkte ein, die in dieser Aufstellung vergessen wurden?
**
Zusätzlich würde ich gerne wissen, was jeder einzelne von Euch dafür tut, dass sein Programmcode die für ihn wichtigen Merkmale erfüllt.Für zahlreiche Antworten wäre ich abermals sehr dankbar!
Nochmals vielen Dank für Eure Hilfe!Viele Grüße!
Ciao
shoat
-
Marc++us schrieb:
shoat schrieb:
Wenn Du mal Zeit und Lust hast, würde ich mich sehr freuen, wenn Du einmal mit eigenen Worten beschreiben würdest, was Du unter XP verstehst. Die Beschreibungen in den Büchern sind doch immer etwas umständlich! Vielleicht hast Du ja auch ein paar gute Links bzw. Bücherempfehlungen?
http://www.c-plusplus.net/titelanzeige.php?ISBN=3827317096
http://www.c-plusplus.net/titelanzeige.php?ISBN=3827318327Vielen Dank. Ich schau gleich mal rein!
Ciao
shoat
-
shoat schrieb:
Marc++us schrieb:
Für mich tritt Wiederverwendung als Entwicklungsziel ganz klar an letzte Stelle, an erste Stelle setze ich Fehlerfreiheit, dann kurze Entwicklungszeit, dann Wartbarkeit.
Warum ist Wartbarkeit für Dich so unwichtig? Ist es nicht besser, wenn man seinen Code von Anfang an immer so gut wartbar macht wie möglich?
Warte, warte, ich habe Wartbarkeit nicht als unwichtig eingestuft!
Ich habe nur Fehlerfreiheit vor die Wartbarkeit gesetzt...
-
Fehlerfreiheit
Ganz klar - wenn das Produkt von Anfang an funktioniert, muß ich weniger warten. -
kurze Entwicklungszeit
Wenn die Sache zu lange dauert, bekomme ich kein Geld, Leute werden ungeduldig - dann komme ich nie zur Wartung oder Wiederverwendung -
Wartbarkeit
Nun darfst Du. Natürlich ist Wartbarkeit wichtig, aber wenn man abwägen muß ist es wichtiger, daß ein Programm fehlerfrei ist, als daß es wartbar ist. Denn wenn es funktioniert, muß man es weniger warten. Wartbarkeit hat für mich kaum was mit Kommentaren zu tun - unter Wartbarkeit verstehe ich ein gutes OO-Design, stabile Klassen, die genau das tun was sie sollen, klare Trennung, und schlanke Schnittstellen, geringe Kohäsion. Dann ist das Programm wartbar. Zur Not sogar mit wenig Kommentaren. Mir bringen Kommentare gar nichts, wenn dafür die Klassen 40 Methoden haben, wo man den Unterschied nicht mehr versteht. Ein gutes Design versteht man intuitiv wenn man es sieht, auch ohne viele Kommentare (durch die Namen, Denkweise, etc). Und ein solches Design ist auch wartbar (d.h. man kann Fehler lokal eingrenzen und neue Funktionen leicht aufbauen). -
Wiederverwendung
habe ich schon beschrieben
-
-
shoat schrieb:
- Er ist gut kommentiert / dokumentiert und damit wartbar
Diese Schlußfolgerung gefällt mir nicht.
Teile es auf:
- er ist gut kommentiert/dokumentiert
- er ist wartbarWie zuvor ausgeführt, beruht Wartbarkeit auch auf gutem Design des Programms.
Schlechtes Design mit vielen Kommentaren führt nicht zur Wartbarkeit.
-
@Marcus: Du stellst die Fehlerfreiheit vor die Wartbarkeit. Da wir alle wissen, dass absolute Fehlerfreiheit nie möglich ist, und Wartungseingriffe sowieso nötig sind, würde es da nicht Sinn machen, wenn man die Wartbarkeit und die Fehlerfreiheit zumindest auf die selbe Stufe stellt, wenn nicht sogar die Wartbarkeit höher bewertet?
-junix
-
junix schrieb:
@Marcus: Du stellst die Fehlerfreiheit vor die Wartbarkeit. Da wir alle wissen, dass absolute Fehlerfreiheit nie möglich ist, und Wartungseingriffe sowieso nötig sind, würde es da nicht Sinn machen, wenn man die Wartbarkeit und die Fehlerfreiheit zumindest auf die selbe Stufe stellt, wenn nicht sogar die Wartbarkeit höher bewertet?
-junix
Das mag ich aus psychologischen Gründen nicht. Damit schafft man von Anbeginn an eine Rechtfertigung für Fehler, nach dem Motto "das wird sowieso nicht laufen, das weiß ja jeder, war schon immer so".
Das kann ich aus meiner Sicht als Ingenieur nicht akzeptieren, daß man etwas so baut, daß die beim Bauen gemachten Fehler leicht behebbar sind. Wenn Du darüber nachdenkst erkennst Du sicher, daß diese Vorgehensweise irgendwie seltsam ist.
Ich will fordern, daß die Anzahl an Fehlern von Anfang an gering ist. Diese Forderung treibt vor allem die Sorgfalt bei der Entwicklung, was wiederum zu eher robusten und wartbaren Designs führen wird. Wartbarkeit als Folge der Fehlerfreiheit.
-
Marc++us schrieb:
shoat schrieb:
- Er ist gut kommentiert / dokumentiert und damit wartbar
Diese Schlußfolgerung gefällt mir nicht.
Teile es auf:
- er ist gut kommentiert/dokumentiert
- er ist wartbarWie zuvor ausgeführt, beruht Wartbarkeit auch auf gutem Design des Programms.
Schlechtes Design mit vielen Kommentaren führt nicht zur Wartbarkeit.
Ok. Damit kann ich mich gut anfreuden. Ich werde es so in meine Aufzeichnungen übernehmen!
Danke!
Ciao
shoat
-
Marc++us schrieb:
Ich will fordern, daß die Anzahl an Fehlern von Anfang an gering ist.
Das bringt mich gleich zu meiner Frage von oben zurück.
Wie stellst Du sicher, dass Programmcode möglichst fehlerfrei ist?
Ok, Du testet!
Aber, wie?
Nur so alla: " Da schraube ich hier mal ein wenig rum und probiere da mal ein paar Fälle aus? "
Oder nutzt Du automatische Testtools? Vielleicht hast Du auch selber ein eigenes kleines Testframework? Oder etwas ganz anderes? Oder alles ein wenig?
Wäre für mich unheimlich wichtig zu wissen, wie es damit in der Praxis wirklich aussieht? Vor allem, weil es ja heißt, dass im Allgemeinen fast überall viel zu wenig getestet wird!
Ciao
shoat