qualitativ hochwertiger Programmcode...
-
shoat schrieb:
Allerdings bleibe ich dabei, dass man die externen Schnittstellen erschöpfend beschreiben muss. D. h. die Dokumentation muss einem alles sagen, was man benötigt, um die Funktion bzw. Klasse korrekt nutzen kann. Es ist schließlich so, dass man bei einigen Libs keine Möglichkeit hat den Quellcode (abgesehen von den Prototypen natürlich) einzusehen. (Wohl aber die aus den Kommentaren entstehene Dokumentation!)
Jo! Genau! Da habe ich im Prinzip ja auch gar nichts gegen. Bloß eine Kleinigkeit fehlt bei deiner Forderung, und die ist halt schon ziemlich wichtig:
[...]die Dokumentation muss einem qualifizierten Entwickler alles sagen, was [er] über die Deklaration hinaus benötigt, um die Funktion bzw. Klasse korrekt [zu] nutzen[...]
So weit sind wir gar nicht (mehr) auseinander. Jetzt fordere noch, daß alle Namen "sprechend" sein sollen: Bingo!!!
volkard schrieb:
ich warte auf die metrikenbefürworter. immerhin werden die ja eingesetzt. immerhin lernt man an hochschulen, wie toll die sind.
Tja, ich schätze, da kannst du lange warten. Sie sind alles andere als toll. Und mal im Ernst: Mag sein, daß man an den Hochschulen was von Informatik versteht, aber von Software-Entwicklung?!!!
Zu "Wie stellt ihr sicher....":
Ich glaube, es zeichnet sich langsam(?) ab, daß es der Entwicklungs-Prozeß also solcher ist, der bei den meisten relevanten Punkten für gute Software sorgt. Keine Tools, keine Metriken, keine Threorien usw., sondern die Art und Weise, wie ein Team organisiert ist und geführt wird, und wie innerhalb des Teams kommuniziert wird. Vielleicht auch, wie man Ziele formuliert bzw. welche Ziele man sich setzt. Ein pragmatischer Prozeß ist ein guter Prozeß, also ein Prozeß, der sein Hauptgewicht darauf legt, qualitativ guten Code herzustellen. Punkt! Das scheint mir auch in Marcus' Aussagen (z.B. zur Gewichtung von Wiederverwendbarkeit) rüberzukommen.Stefan.
-
Marc++us schrieb:
Pfüüüüü.... halt mal den Ball flach.
Vielleicht war er auch der Ansicht, es wäre offensichtlich.Ich wollte niemanden auf den Schlips treten, wenn er mich aber zitiert und dann von irgendetwas ganz anderen erzählt, dann finde ich es doch ziemlich seltsam. Aber wahrscheinlich habe ich ihn nur wieder mißverstanden...
Marc++us schrieb:
Wenn Du als Richtung einfach einen int-Parameter reinwirfst, ohne Kommentar, dann ist klar daß der Code mit dem Modulo(3) unverständlich ist.
Denn korrekt wäre es hier gewesen eine Legende für den int-Parameter zu machen ...
Genau dass erzähle ich auch die ganze Zeit!
Viele Grüße!
Ciao
shoat
-
Marc++us schrieb:
Bisher war es eine interessante und lehrreiche Diskussion, der aufmerksame Zuhörer konnte einiges mitnehmen.
Ich kann Dir nur zustimmen. Ich persönlich habe schon sehr viel gelernt. Insbesondere auch durch volkards und Deine Beiträge.
Marc++us schrieb:
Eigentlich dachte ich, wir sprechen von diesem Thema... das steht doch alles da.
Es stand eben nicht alles da! Über einige Themen, wie z. B. Performance, wurde noch nichts oder noch nicht viel gesagt. Deswegen habe ich die Fragen erneut gestellt um auch dazu (mehr) Feedback zu erhalten und nicht nur noch über Kommentare zu reden. Deine letzte Antwort zu alle diesen Punkte hat wieder einige ganz neue Sachen enthalten, über die ich nachdenken und googeln werde. Danke dafür!
Ciao
shoat
-
DStefan schrieb:
Jo! Genau! Da habe ich im Prinzip ja auch gar nichts gegen. Bloß eine Kleinigkeit fehlt bei deiner Forderung, und die ist halt schon ziemlich wichtig:
[...]die Dokumentation muss einem qualifizierten Entwickler alles sagen, was [er] über die Deklaration hinaus benötigt, um die Funktion bzw. Klasse korrekt [zu] nutzen[...]
Ok. darauf kann man sich doch einigen! Allerdings ist dann doch noch zu definieren, was man unter einem qualifizierten Entwickler versteht.
Nehmen wir zum Beispiel das JDK. Damit muss jeder sich jeder Java-Entwickler (auch und v. a. die erst angehenden und wenig erfahrenen) auseinandersetzen. Wäre es nicht angemessen, dass die Schnittstellenbeschreibungen hier etwas ausführlicher gestaltet werden, da man davon ausgehen muss, dass auch viele Anfänger die verschiedenen Libs nutzen woll / müssen. Oder sollte man darauf bestehen, dass sie sich die ihnen fehlenden Informationen aus Büchern oder sonst wo zusammentragen?
Dies ist eine offene Frage. Ich habe dazu keine definitve Meinung. Vielleicht helft ihr mir eine eigene Meinung zu bilden!
DStefan schrieb:
So weit sind wir gar nicht (mehr) auseinander.
Ganz offentsichtlich meinen wir schon die ganze Zeit ziemlich das Selbe...
DStefan schrieb:
Jetzt fordere noch, daß alle Namen "sprechend" sein sollen: Bingo!!!
Damit hast Du sicher vollkommen recht! Dagegen hatte ich auch noch nie einen Einwand. Ganz im Gegenteil!
Vielen Dank!
Ciao
shoat
-
shoat schrieb:
Dies ist eine offene Frage. Ich habe dazu keine definitve Meinung. Vielleicht helft ihr mir eine eigene Meinung zu bilden!
Das ist ganz einfach: es gibt einen substantiellen Unterschied zwischen der Doku eines Frameworks oder eine API (wie hier dem JDK) und der Doku einer Applikation - hier gibt's ganz andere Zielgruppen, und auch andere Vorkenntnisse.
Bei einem Framework mußt Du quasi von einem vollkommenen Neuling ausgehen, der diese Funktion erstmalig benutzt und mit den internen Abläufen in keinster Weise vertraut ist. Vor allem kann man gar nicht wirklich hinter die Schnittstelle schauen, das ist eine reine Blackbox.
Bei einer Applikation ist der Kreis der Leser und Anwender einer Schnittstelle viel stärker eingegrenzt - man ist mit der Problemwelt eher vertraut, kennt die Begriffe, es gibt auch ein Wissen über die internen Abläufe im Team (soviele Leute werden im Team nie ausgewechselt).
Daher sieht die Doku in solchen Fällen ganz anders aus.
-
volkard schrieb:
ich warte auf die metrikenbefürworter. immerhin werden die ja eingesetzt. immerhin lernt man an hochschulen, wie toll die sind.
Ich habe an der (Fach-) Hochschule noch nie etwas zu Metriken gehört. Ok, irgendwann sollten wir in Software Engeneering mal ein Referat halten und da stand auch dieses Thema zur Auswahl. Allerdings hat es keiner ausgewählt, also wurde ich auch nicht damit behelligt. Dagegen hat uns der Prof. selbst schon etwas von XP und Prototyping erzählt.
Erst im Betrieb wurde ich dann mit dem Thema Metriken konfrontiert!
DStefan schrieb:
Und mal im Ernst: Mag sein, daß man an den Hochschulen was von Informatik versteht, aber von Software-Entwicklung?!!!
Natürlich gibt es solche und solche Professoren. Aber ich kann mich eigentlich nicht beschweren. Diejenigen, bei den ich Programmieren und Software-Engeenering hatte, waren davor selber Software-Entwickler (z. B. bei sd&m bzw. siemens). Ich weiß nicht recht, warum die keine Ahnung von Software-Entwicklung haben sollen?
Ok. Sie sind bestimmt nicht mehr ganz up2date, aber die Grundlagen sollten sie einem schon vermitteln können.
DStefan schrieb:
Zu "Wie stellt ihr sicher....":
Ich glaube, es zeichnet sich langsam(?) ab, daß es der Entwicklungs-Prozeß also solcher ist, der bei den meisten relevanten Punkten für gute Software sorgt. Keine Tools, keine Metriken, keine Threorien usw., sondern die Art und Weise, wie ein Team organisiert ist und geführt wird, und wie innerhalb des Teams kommuniziert wird. Vielleicht auch, wie man Ziele formuliert bzw. welche Ziele man sich setzt. Ein pragmatischer Prozeß ist ein guter Prozeß, also ein Prozeß, der sein Hauptgewicht darauf legt, qualitativ guten Code herzustellen. Punkt! Das scheint mir auch in Marcus' Aussagen (z.B. zur Gewichtung von Wiederverwendbarkeit) rüberzukommen.Danke für diesen Beitrag! Ich werde Teile davon in meine Arbeit aufnehmen!
Ciao
shoat
-
Marc++us schrieb:
shoat schrieb:
Dies ist eine offene Frage. Ich habe dazu keine definitve Meinung. Vielleicht helft ihr mir eine eigene Meinung zu bilden!
Das ist ganz einfach: es gibt einen substantiellen Unterschied zwischen der Doku eines Frameworks oder eine API (wie hier dem JDK) und der Doku einer Applikation - hier gibt's ganz andere Zielgruppen, und auch andere Vorkenntnisse.
Bei einem Framework mußt Du quasi von einem vollkommenen Neuling ausgehen, der diese Funktion erstmalig benutzt und mit den internen Abläufen in keinster Weise vertraut ist. Vor allem kann man gar nicht wirklich hinter die Schnittstelle schauen, das ist eine reine Blackbox.
Bei einer Applikation ist der Kreis der Leser und Anwender einer Schnittstelle viel stärker eingegrenzt - man ist mit der Problemwelt eher vertraut, kennt die Begriffe, es gibt auch ein Wissen über die internen Abläufe im Team (soviele Leute werden im Team nie ausgewechselt).
Daher sieht die Doku in solchen Fällen ganz anders aus.
Kann man also sagen, dass man die Schnittstellendokumentation auf Zielgruppe zuschneiden
muss?Kann man allgemein soweit gehen, dass man sich beim Kommentieren (nicht nur bei der Schnittstellendoku) immer darüber Gedanken machen muss, für wenn er gedacht ist?
Kann man sogar sagen, dass der Programmierer seine Kommentare vorrangig auf den potentiellen Leser abstimmen muss und nicht danach gehen darf, welche Art von Kommentaren er persönlich am Liebsten vorfinden würde?
Vielen Dank für Deinen Beitrag!
Ciao
shoat
-
shoat schrieb:
... Du bist ja auf meine Argumentation gar nicht eingegangen ...
Schade, ich hatte ursprünglich gedacht, Du wolltest mir helfen.
such dir die antwort aus
-
shoat schrieb:
Kann man also sagen, dass man die Schnittstellendokumentation auf Zielgruppe zuschneiden muss?
man muß bereits beim coden dran denken. so zu coden, daß die arbeitskollegen mitspielen können, nennt sich teamgeist.
also weiterhin: lieber lesbaren code bauen als unlesbaren zu kommentieren. allerdings gibs gewisse untergrenzen. wenn einer nicht mit modulo umgehen kann oder keine zeiger kennt, dann stellt man sich einfach vor, der wäre nicht im team und optimiert für die anderen.
-
übrigens: meine gelungenste code-dokumentation war ein tutorial. damals hab ich ein paar (wirre template-) klassen um die ODBC-Schnittstelle gebaut (unter anderem werte cachen für mehr performance). es wäre völliger unfug gewesen, die klassen und methoden ohne kontext einzeln zu beschreiben. also hab ich ein tutorial gebaut, wie der user die klassen einsetz. zuerstmal nur db öffnen und nen wert aus ner tabelle lesen. dann auch mal 100 werte lesen. mal was schreiben. mal ne abfrage machen und so.
zielgruppe war mir unbekannt, wußte nur, daß die doku auf englisch zu sein hatte.
-
Den Ausdruck Test-Driven-Design habe ich zwar noch nicht gehört. Aber Du hast Recht. Ich habe vorerst recht viel Material. JUnit oder ein vergleichbares Opensource-Tool soll ein zentraler Bestandteil, des aufzubauenden Testframeworks, werden!
Test-Driven-Design sieht so aus, das due erst einen Test zu einer Funktion schreibst, und erst anschließend die Funktion implementierst. So kannst du sicher sein, dass deine Funktion alles kann, was von ihr verlang wird.
nutzlos. das ist nur ne umformulierung des programmcodes. wirksamer ist ne testfunktion, die nur den zweck hat, die funktion zu testen.
Unit-Test vs. Post-Kondition?
Außerdem erklär das mit der Umformulierung nochmal kurz. Der algorithmus zum Berechnen der Wurzel sieht ja so aus :
w[n+1] = (w[n] + radiant / w[n]) / 2;das lässt man dann in ner Schleife laufen, bis w[n] == w[n+1]. Ein schnellerer Algorithmus ist mir nicht bekannt.
/edit: letzter Teil war nutzlos.
-
Hallo erstmal!
Hier bin ich wieder!
Hat zwar ein wenig gedauert, da ich den ganzen Input, den ich bekommen habe, erst mal verdauen mußte. Aber jetzt bin ich wieder da und habe auch wieder reichlich neue Fragen!volkard schrieb:
ich warte auf die metrikenbefürworter. immerhin werden die ja eingesetzt. immerhin lernt man an hochschulen, wie toll die sind.
Ich habe jemanden gefunden. Mein Chef mag sie natürlich!
Er ist also nicht der eine von hundert. Nun ja vielleicht doch, hier gleich mal, wie er sie einsetzen will:Hier - in meinem Betrieb - gibt es zahllose J2EE-Anwendungen (für verteilte Systeme). Die Anwendungen sind dabei grundsätzlich immer sehr ähnlich aufgebaut. Per Definition ist es dabei wichtig, dass einige Funktionen / Klassen sehr klein (effizient) bleiben müssen (und auch fast immer können).
Da es aber ständig unzahlige neue Anwendungen mit noch viel mehr genau solcher Funktionen gibt, möchte er über Metriken (wahrscheinlich reichen hier sogar schon die LOCs) automatisch schnell herausfinden können, ob die diese (o. g.)Funktionen / Klassen bei der entsprechenden J2EE-Anwendung in einem bestimmten Toleranzbereich liegen. Alle die nicht in dem Bereich liegen müssen, werden dann noch mal separat kontrolliert und evtl. verbessert.
Er möchte also nicht den Code an sich (oder gar den Programmierer) komplett bewerten, sondern nur mögliche Schwachpunkte in Systemen finden. Die gefundenen Stellen werden dann auch nicht sofort als Fehler angesehen, sondern zuerst einmal genauer unter die Lupe genommen.
Was haltet ihr davon? Oder gibt es dafür einen einfacheren Weg?
Vielen Dank!
Ciao
shoat
-
volkard schrieb:
such dir die antwort aus
Oh! Hatte ich doch glatt übersehen.
Hmm ... äh ... nun ja ... obwohl ich A sehr lustig finde, wähle ich doch
"Du hast eine eigene Meinung, die Du hier auch gnadenlos vertrittst!
Außerdem bist Du sehr genau und weist mich auf Fehler hin.
Gelegentlich verstehe ich Dich auch einfach nur falsch."Danke für Deine Beiträge!
Ciao
shoat
-
volkard schrieb:
also weiterhin: lieber lesbaren code bauen als unlesbaren zu kommentieren.
Mit der Reihenfolge habe ich gar kein Problem. Natürlich zuerst einen lesbaren Code bauen und diesen dann bei Bedarf kommentieren.
volkard schrieb:
allerdings gibs gewisse untergrenzen.
Genau, dass war (für mich) das Problem. Was sind die Untergrenzen? Welches Wissen kann ich vom Leser des Codes und der Kommentare / Dokumentation erwarten?
Diese Fragen haben sich allerdings für mich mittlerweile (Dank Euerer Hilfe) erst einmal beantwortet.
Ciao
shoat
-
Jetzt habe ich auch gleich noch eine Frage:
Im Laufe meiner Recherchen stoße ich immer wieder die Begriffe, wie
- Capability Maturity Model (CMM)
- Rational Unified Proces (RUP)
- Modell View Controller (MVC)
- PrototypingWie wichtig / wie zeitgerecht sind dahinterstehenden Ideen eigentlich noch?
( MVC scheint ja zumindest Marc++us für ziemlich wichtig zu halten! )Vielen Dank!
Ciao
shoat
-
Ach ja,
kann mir vielleicht jemand ein gutes (Open-Source-) Tool zum Durchführen von Lasttest empfehlen?
Meint - ich suche ein Tool, bei dem ich den gleichzeitigen Zugriff von sehr vielen unterschiedlichen Clients auf eine Web-Applikation simulieren kann!Und wie überprüfe ich überhaupt eine GUI? Ich habe noch nichts in dieser Richtung gefunden und kann mir auch nicht recht vorstellen, wie es funktionieren soll! Kennt jemand dafür ein gutes (Open-Source-) Tool?
Vielen Dank!
Ciao
shoat
-
shoat schrieb:
Hier - in meinem Betrieb - gibt es zahllose J2EE-Anwendungen (für verteilte Systeme).
meine argumente galte für c++ oder ähnliche sprachen.
shoat schrieb:
Die Anwendungen sind dabei grundsätzlich immer sehr ähnlich aufgebaut. Per Definition ist es dabei wichtig, dass einige Funktionen / Klassen sehr klein (effizient) bleiben müssen (und auch fast immer können).
Da es aber ständig unzahlige neue Anwendungen mit noch viel mehr genau solcher Funktionen gibt, möchte er über Metriken (wahrscheinlich reichen hier sogar schon die LOCs) automatisch schnell herausfinden können, ob die diese (o. g.)Funktionen / Klassen bei der entsprechenden J2EE-Anwendung in einem bestimmten Toleranzbereich liegen. Alle die nicht in dem Bereich liegen müssen, werden dann noch mal separat kontrolliert und evtl. verbessert.
das müssen aber sehr, sehr viele sein, daß er nicht auch so sichten kann. nachdem er zwhn davon genauer gelesen hat, kann er doch 11 bis 100 in weniger als einer minute checken und 101 bis 1000 in sekunden.
shoat schrieb:
Er möchte also nicht den Code an sich (oder gar den Programmierer) komplett bewerten, sondern nur mögliche Schwachpunkte in Systemen finden. Die gefundenen Stellen werden dann auch nicht sofort als Fehler angesehen, sondern zuerst einmal genauer unter die Lupe genommen.
wortspalterei.
ich sage voraus, daß die ergebnisse (also rauswürfe durch programm) mit den wunschergebnissen (also rauswürfe durch mensch) einfach nicht korrelieren.
später wird dann gelernt, an welchen metriken man schrauben muß, um in der tat ne positive korrelation hinzukriegen. die wird aber wie üblich nur ne gemeinsame kausalverantwortliche variable anzeigen, keinen kausalen zusammenhang zwischen metrik und codequali. zum beispiel würde man in c++ die minderverwendung von templates und const als anzeiger nehmen für schlechte kommentare. mit ersterem findet man raus, wer nube ist, und der macht auch letzteres. in einem wort: "computermystik".
-
@Volkrad: könntest du bitte noch auf meine letzte Frage antworten? Interessiert micht wirklich.
-
Helium schrieb:
@Volkrad: könntest du bitte noch auf meine letzte Frage antworten? Interessiert micht wirklich.
meinste damit echt
Unit-Test vs. Post-Kondition?
?
-
volkard schrieb:
meine argumente galte für c++ oder ähnliche sprachen.
Ok. Danke für den Hinweis. Allerdings fällt mir im Moment nicht ein, was an einem generischen Ansatz wie Metriken in Java (J2EE = "Java 2 Enterprise Edition") unterschiedlich zu C++ sein soll.
volkard schrieb:
das müssen aber sehr, sehr viele sein, daß er nicht auch so sichten kann.
Ich habe nur einen sehr geringen Einblick (bin relativ neu), aber es sind wirklich sehr, sehr viele verschiedenen Anwendungen (Beans).
Es ist definitiv ein zu großer Aufwand, alle potentiellen Funktionen aller Anwendungen nochmal durch einen Dritten zu kontrollieren. Dafür ist sind es einfach zu viele. Nicht, dass man es nicht gerne machen würde, aber man bräuchte dafür einen eigenen Tester oder sogar eine Testabteilung. Dies wird aber von den Kunden nicht bezahlt, also fehlt einfach das Geld dazu. Also sucht man einen anderen Weg trotzdem so viel wie möglich zu kontrollieren / testen.
volkard schrieb:
nachdem er zehn davon genauer gelesen hat, kann er doch 11 bis 100 in weniger als einer minute checken und 101 bis 1000 in sekunden.
So wurde es ja bisher gemacht. Er ist alle sequentiell durchgegangen und hat dabei festgestellt, dass im Großen und Ganzen die allerallermeisten ok sind. Bei den anderen wurde einfach zuviel auf einmal bzw. sogar unnötig gemacht, damit wurde es zu langsam.
Mittlerweile sind es allerdings zu viele neue (und die alten werden auch ständig geändert), um wirklich noch alle kontrollieren zu können. Jetzt sucht er (was ich grundsätzlich ganz legitim finde) nach einen einfachen Weg, nicht mehr alle in die Hand nehmen zu müssen, sondern eben wesentlich weniger. Er will es mit Metriken versuchen. Oder gibt es einen besseren Ansatz?
shoat schrieb:
wortspalterei. ... keinen kausalen zusammenhang zwischen metrik und codequali.
Hier ist (nach Aussage meines Chefs) kein Tool zur Bewertung der allgemeinen Code-Qualität gesucht, sondern ein Möglichkeit um gezielt Fehler zu suchen, um ihm so seine Arbeit zu erleichtern.
Ob und wie man an der Metrik schrauben muss, um die tatsächlichen Fehler zu finden ist dann doch eigentlich egal, solange sie dann auch gefunden werden. Eigentlich spricht doch auch nichts dagegen, die Fehlersuche zu automatisieren, wenn es möglich ist. Und ob es möglich ist, soll ich auch erst herausfinden.
Also nochmal, nach Aussage meines Chefs sind Metriken dumm wie Brot. Deswegen möchte er sie nur in bestimmten Zusammenhängen einsetzen, wie der gezielten Fehlersuche, wenn es denn möglich ist. Alles andere ist ihm vollkommen Banane!
So ok? Oder was soll ich im sonst sagen? Abbringen wird er sich sowieso nicht mehr lassen, denn er hat sich schon festgelegt.
Ciao
shoat