Bin ich zu Blöd dafür

Hehe, sorry Kachelator, den Nickname habe ich nur, weil ich irgendwann festgestellt habe, dass den sonst nie irgendjemand hat, so kann ich immer den gleichen Nick nehmen (aber interessante Schlussfolgerung, die werde ich wohl übernehmen, wenn du erlaubst , falls mich mal wer nach dem Namen fragt... :D).
Na cool, dann war ja meine Bemerkung richtig nützlich! :-)

So langsam decken sich auch die Ursachen der unterschiedlichen Ansichten auf[... (und Folgendes)]
Da kommen wir auf einen Nenner (auch ich habe einen Taschenrechner programmiert! ;) ).

Das muss ich mir merken! :)

P.S.: Ja der Roman wirkt am Adriastrand auch viel cooler...
Wenn es ein C++-Buch mit einem Notebook für 10000000€ daneben ist, sieht das bestimmt anders aus. Abgesehen davon sollte man sich im Urlaub erholen. :rolleyes:
 
Ich fürchte mit der Wartbarkeit ist es so eine Sache. Jeder Code ist wartbar wenn er a) ordentlich designt ist und b) ordentlich kommentiert ist.

Klar, bei optimiertem Code gehört bei der Methode/Prozedur eine Beschreibung dazu WAS die Methode/Prozedur macht und WIE sie es macht und WARUM diese Zeilen Code etwas optimieren.

Das Code nicht wartbar ist liegt in 99.99% der Fälle an mangelnder Dokumentation.
 
Deine Schlussfollgerrungen sind falsch komplett falsch.

Dudadida hat gesagt.:
Weißt du Christian, das mag ja alles gut und schön sein und tatsächlich hat irgendwer meistens schon den perfekten Algorithmus für eine bestimmte Anwendung geschrieben und man braucht ihn nur noch kopieren. Und das ist ja auch gut so und das kann man ja auch nach belieben machen und spart Zeit und im professionellen Bereich auch viel Geld. ABER es ist viel befriedigender wenn man eben das Rad mal neu erfindet. Ich habe schon binäre Bäume benutzt, bevor ich wusste was das ist, ebenso ging es mir mit unzähligen anderen Standardalgorithmen, die ich mir selbst aus den Fingern gesogen habe.

Mann kann einerseits einen Sotieralgorythmus schreiben, oder anderseits einen von der API
nehmen um damit schneller und leichter ein benutzbares Endprodukt programmieren.
Mann hat durch den Suchalgorythmus mehr Zeit sich auf das Endprodukt zu konzentrieren
und seine Energien da hinein zu stecken, wo es wirklich benötigt wird.

Dudadida hat gesagt.:
Von der pädagogischen Seite ist das zehnmal mehr Wert als irgendeinen vorgekauten Code abzupinseln, weil man selbst gezwungen ist zu denken und nicht nur "wie passe ich Standard X an mein Problem an" sondern "wie löse ich das Problem"! Und guten Stil gewöhnt man sich schon zwangsläufig an, wenn man die Übersicht waren will und sich Gedanken über das macht, was man schreibt und versucht es zu verbessern (wobei es da auch einige Ausnahmen zu geben scheint, ok).

Mann pinselt nichts ab, mann ruft einfach eine Methode auf.
Und guten Stil gewöhnt mann sich nicht so einfach an indem mann sich nur Gedanken macht, sondern indem mann fremden Code liest, und in einem Team programmiert. Mann muss sich
das antrainieren, und Bücher sind da ein guter Anfang.

Dudadida hat gesagt.:
Wenn man es dann kann, gut und schön, aber ich finde es verwunderlich, dass ich teilweise immer noch von Freunden die Informatik studieren die Programmieraufgaben löse und das obwohl sie ihre teuren Bücher zu Hause haben und voll sind, von theoretischem Fachwissen, es aber nicht umsetzen können.

Das Informatikstudium befähigt noch lange nicht zum programmieren. Ich muss das immer wieder bei Bewerbungen die hier eintrudeln erkennen.
Nur Informatikstudenten die sich nebenbei mit der Programmierung beschäftigen, werden
auch gute Programmierer.
Das Informatikstudium ist viel zu theoretisch. Und Bücher allein machen auch noch keinen
guten Programmierer. Mann muss schon was dafür tun, sprich Theoretisches Wissen +
Praktische Erfahrung.

Dudadida hat gesagt.:
Dass die IT-Branche da anders denkt und lieber Wert setzt auf billig und billig und billig ist klar, schließlich ist man ja nicht mehr gezwungen mit langsamen Systemen zu arbeiten und man kann vollkommen in Richtung Wartbarkeit und Kostenersparnis denken, aber das ist meiner Meinung nach von der programmiertechnischen Seite her nicht der beste Weg, weil so nach außen hin nicht die beste Software produziert wird, damit hat's nur der Programmierer leichter.

Sorry, aber so wie du denkst wurde auch zu den Zeiten, die mann allgemein als Softwarekrise betrachtet gedacht. Der Punkt ist, früher konnten sich nur Grosskonzerne wie Siemens individualsoftware leisten, da die Kosten mehrere Hundertausende € verschlungen.
Heutzutage sind die preise für Individualsoftware in einem Bereich, in dem sich auch Mittelständische Firmen das leisten kann. Der Markt nach bezahlbarer Indidualsoftware ist
gross geworden. Früher gab für ein solches Projekt sehr lange Entwicklungszeiten, die über mehrere Jahre gingen. Heute sinds oft wenige Monate.
Aber das programmieren heute hat sich geändert, mann hat grosse Frameworks die einem Arbeit abnehmen, mann hat extrem gute IDEs die einen helfen, es gibt Dinge wie Testdriven Development, XtremeProgramming, es gibt Model Driven Architektur und Projekte wie
Apache Jakarta Commons, die einen viele Arbeit abnehmen.
Das wichtige in der modernen Programmierung ist das konzentrieren auf den Knackpunkt bei
der Software, die logic.
Das dies schlechte Software ist, die nicht alle Algorythmen selber schreibt, kannst du komplett vergessen, denn gerade Software wie Oracle DB, Eclipse, Apache Tomcat, JBoss, KDE usw
machen extremen gebraucht von dieser Code wiederverwenbarkeit.
Sämmtlicher professioneller Code basiert zum grössten Teil auf wiederverwendete Algorythmen.

Dudadida hat gesagt.:
PS.: Oh Mann, wer nimmt denn ein C++ Buch mit an den Strand... das lenkt doch nur vom wesentlichen ab... *g*

ähm ich :-)
Mann kann so beschäftigt tun, wärend mann ....
... aber lassen wir das :-)
 
Naja, wer das Optimieren anfängt bevor das Produkt funktioniert ist selber schuld. Aber weglassen ist unnötige Verschwendung von Ressourcen und das Gerücht, mit der nächsten Hardwaregeneration wird's schon besser ist wie gesagt nur ein Gerücht.
 
Dudadida hat gesagt.:
Aber ich glaube das ist in jedem Fachbereich irgendwo ähnlich. In Medizin ist es bspw. ganz krass, da werden ja bewusst Theorieroboter herangezogen, die das ganze 1500 Seiten Innere Medizin Buch auswendig hervorbeten können. Und ohne wirklich praktisch tätig geworden zu sein werden die Studenten so auf die unvorbereiteten Patienten losgelassen werden, die sogar noch Vertrauen aufbringen, weil auf dem Namensschild schließlich "Arzt" steht.

Meine ex hat jetzt vor nem Monat?! ihr letztes Staatsexamen fertig. Ich war in der Zeit
als sie ihr Physikum gemacht hat mit ihr zusammen, und da war das mit der Theorie
schon ziemlich heftig, mit welchem Lehraufwand das verbunden ist.

Aber so wie ich mitbekommen habe, hatte sie sehr wohl ihr Praktisches Jahr in der
Klink und auch sonst war es etwas weniger Theoretisch nach dem Physikum.

mhhh

Klar, bei optimiertem Code gehört bei der Methode/Prozedur eine Beschreibung dazu WAS die Methode/Prozedur macht und WIE sie es macht und WARUM diese Zeilen Code etwas optimieren.
Das sehe ich anders. Wenn ich eine Methode habe die eine Beschreibung benötigt weil sie nicht selbstredent ist, dann wird die Methode über den Jordan geschickt und ich schreibe den
betreffenden Code neu, da er hässlich ist.
Erst wenn ich dann beim neuschreiben merke das ich nicht drumherum komme eine erklärungsbedürftige Methode zu schreiben, wird diese ausführlich kommentiert.

Eine Methode wie:
public String[] getParametermap(HttpRequest ) oder int extractIdentifier(paramMap); sind selbstredent und benötigen keiner Kommentierung. Es ist sogar oftmals so das Kommentare sich eher störend auf die lesbarkei auswirken.

Wann schreibt mann denn Kommentare?
a) Es ist nicht auf den ersten Blick ersichtlich was passiert
b) Bestimmte Rückgabewerte haben eine besondere Bedeutung
c) Betreffende Codeteil wird von irgendwo aufgerufen, es muss dieser Aufruf in die Analyse mit einbezogen werden, Abhängigkeiten
d) nicht leicht zu erkennender Algorythmus z.b Rekursiever aufruf mit entsprechenden sprung Variablen
...

Was kann mann machen?
a) Den code so umbauen das er selbstredender wird, Code in entsprechende Methoden auslagern die gut benannte werden.
b) Mit Enums und vergleichbaren arbeiten die wiederrum aufgrund des Bezeichners ihre bedeutung verraten.
c) Den Code mehr modularisieren, so das die Enge verbindung verloren geht. Wenn dies nicht
möglich ist, dies eher durch einen Ausführbaren Test, z.b JUnit dokumentieren.
d) wenn möglich vereinfachen. Wenn nicht möglich ist hier ein Kommentar angebracht.

Also meiner Meinung nach werden Kommentare oftmals unsinnig eingesetzt und sind eine entschuldigung für schlechtes Design.
 
Original geschrieben von Christian Fein
Mann kann einerseits einen Sotieralgorythmus schreiben, oder anderseits einen von der API
nehmen um damit schneller und leichter ein benutzbares Endprodukt programmieren.
Mann hat durch den Suchalgorythmus mehr Zeit sich auf das Endprodukt zu konzentrieren
und seine Energien da hinein zu stecken, wo es wirklich benötigt wird.
[...]
Mann pinselt nichts ab, mann ruft einfach eine Methode auf.
Und guten Stil gewöhnt mann sich nicht so einfach an indem mann sich nur Gedanken macht, sondern indem mann fremden Code liest, und in einem Team programmiert. Mann muss sich
das antrainieren, und Bücher sind da ein guter Anfang.

Ich geb's auf. Sorry, aber ich habe irgendwie den Eindruck, dass du gar nicht versuchst zu verstehen was ich meine. Mir geht's hier nicht darum in kürzester Zeit das tollste Programm zu schreiben, sondern das Programmieren zu lernen. Da bringt es einen meiner Meinung nach weiter, wenn man den Suchalgorithmus selber schreibt.

ähm ich
Mann kann so beschäftigt tun, wärend mann ....
... aber lassen wir das

...ist ein Argument... :)
 
Original geschrieben von Christian Fein

Das sehe ich anders. Wenn ich eine Methode habe die eine Beschreibung benötigt weil sie nicht selbstredent ist, dann wird die Methode über den Jordan geschickt und ich schreibe den
betreffenden Code neu, da er hässlich ist.
Erst wenn ich dann beim neuschreiben merke das ich nicht drumherum komme eine erklärungsbedürftige Methode zu schreiben, wird diese ausführlich kommentiert.

Ich habe in meinem Leben noch keine selbsterklärende Methode entdeckt die nicht-triviale Algorithmen enthält.
Bitte schreibe mir doch einmal eine Huffmankompression die sich selbständig erkläre, d.h. bei der man ohne Kenntnis des Algorithmus einfach so feststellt was da geschieht. Das will ich sehen - andernfalls sehe ich deine Behauptung als wiederlegt an.

Womit wir auch wieder bei der Optimierung sind. Huffman eine Durchsatzverdopplung zu bringen ist sicherlich einiges an Dokumentation wert..

Genau das gleiche in String-Routinen oder ähnlichem. Wenn ich mich recht entsinne, programmierst du hauptsächlich bzw. auch Java. Wenn da die Klassenbibliotheken auf einmal um Faktor 2-3 langsamer sind in den häufig benötigten Routinen dann würdest du die Sprache weglegen.
Klar hat es keinen Sinn eine Taschenrechnerapplikation bezüblich Geschwindigkeit zu optimieren - aber wenn sich bei einer Applikation die Rechenzeit von 10h auf 5h kürzen läßt (was nicht unrealistisch ist bein nicht optimierten Applikationen), dann ist das wesentlich. Gleiches bei Webservern - wenn die plötzlich doppelt so viele dynamische Webseiten ausliefern können spart das einiges an Geld.
Ich denke es kommt auf das Ziel drauf an. Ich kenne genügend Anwendungen die ein plus an Geschwindigkeit leicht vertragen könnten.

zu den JUnits - manchmal geht das nicht weil man nicht den ganzen Wertebereich mit Tests abdecken kann. Dann stehst du damit im Regen.
 
Dudadida hat gesagt.:
Ich geb's auf. Sorry, aber ich habe irgendwie den Eindruck, dass du gar nicht versuchst zu verstehen was ich meine. Mir geht's hier nicht darum in kürzester Zeit das tollste Programm zu schreiben, sondern das Programmieren zu lernen. Da bringt es einen meiner Meinung nach weiter, wenn man den Suchalgorithmus selber schreibt.

Das habe ich nicht bestritten. Ich habe irgendwo geschrieben das es sehr wohl von Vorteil ist wenn
mann einmal irgendeine Art von Sort geschrieben hat, selbst wenn mann später Arrays.sort() nutzt.
Zusätzlich habe ich auch geschrieben das mann Programmieren lernt indem mann Theorie und Praxis verbindet. Aber es geht nicht darum das es nötig ist das mann jeden Algorythmus selber mal geschrieben haben muss, denn es gibt genügend Dinge in der Welt des Programmierers die ebenso aufwendig zu lernen sind, und einen höheren Praktischen Nutzen haben. So wie eben die Design Patterns, der praktische Nutzen in der Programmierung ist sehr viel höher.
Denn das Ziel des Programmieren lernens kann nur das Programmieren von Software (welche auch immer) bedeuten, und da ist es wichtig das mann sich auf die wirklichen Probleme die Software mitsich bringt eingeht.

squeaker hat gesagt.:
Ich habe in meinem Leben noch keine selbsterklärende Methode entdeckt die nicht-triviale Algorithmen enthält.
Bitte schreibe mir doch einmal eine Huffmankompression die sich selbständig erkläre, d.h. bei der man ohne Kenntnis des Algorithmus einfach so feststellt was da geschieht. Das will ich sehen - andernfalls sehe ich deine Behauptung als wiederlegt an.

Welche Behauptung widerlegt:
diese:
d) wenn möglich vereinfachen. Wenn nicht möglich ist hier ein Kommentar angebracht.
Oder existieren bei dir nur Methoden die solche Algorythmen beherbergen? Eigentlich sind
Methoden in denen wirklich etwas passiert das nicht trivial ist höchstens 10 % aller Methoden.
Falls dies nicht der Fall ist trifft Lösung nr.
a) Den code so umbauen das er selbstredender wird, Code in entsprechende Methoden auslagern die gut benannte werden.
in Kraft.

Oder aber du programmierst im Augenblick ein neues Verschlüsselungsverfahren, dann kann es durchaus sein das mann mit 10 % nicht zurecht kommt. Aber ansonsten sollte das mit den 10 % schon stimmmen.
Zudem ist die Frage wenn ich eine Methode schreibe die etwas nicht triviales mache dann sollte sie dennoch so designed sein das Parameter der Methode und Rückgabewert der Methode klar sind. Zudem sollte die Methode fertig sein, das heisst es besteht kein Bedarf an dieser Methode etwas zu ändern. Änderrungen die aufkommen werden durch das Design abgefangen.
Für denjenigen der die Methode nutzt muss klar sein was die Methode durchführt und wie sie angewendet wird.

Genau das gleiche in String-Routinen oder ähnlichem. Wenn ich mich recht entsinne, programmierst du hauptsächlich bzw. auch Java. Wenn da die Klassenbibliotheken auf einmal um Faktor 2-3 langsamer sind in den häufig benötigten Routinen dann würdest du die Sprache weglegen.
Die Frage ist doch, sind diese Routinen der Flaschenhals oder nicht. Sprich was sagt mein Profiler? Wieviel verlier ich durch die 2-3 mal langsamer. Wenn ich in einer Operation 20 Millisekunden verliere dann werde ich diese Routinen auch weiterhin nutzen. Denn ich weiss
das diese Methoden Threadsicher sind, und auch wenn ich jetzt noch nicht sie in einer Multithreadumgebung aufrufe, so steht mir die Option für die Zukunft offen. Optimier ich aber meine eigenen Routinen und die sind nicht Threadsave spaaren mir aber 20 ms, so habe ich
Erweiterungsproblem sobald ich sie über verschiedene Threads aufrufe.
Der Flaschenhals bei Anwendungen die langsam sind, befindet sich meist bei Externen Zugriffen, IO Operationen, Datenbank verbindungen, SOAP Verbindungen, RMI usw.
Gerade in den Bereichen lassen sich ganz andere Performancegewinne erreichen, die keinen
faden Beigeschmack haben.

zu den JUnits - manchmal geht das nicht weil man nicht den ganzen Wertebereich mit Tests abdecken kann. Dann stehst du damit im Regen.
Dafür gibt es MockObjecte. Mann kann soziemlich alle Daten modelieren und simulieren.
Wenn es Dinge gibt die sich nicht simulieren lassen, dann haben wir zumeist wiederrum schlechte s zusehr unmodales Design.
 
Wie modelierst du eine Funktion die von RxR nach R abbildet? Testet dein Mock-Objekt alle Werte?

Ich habe nie davon gesprochen alles zu optimieren - ich glaube ich habe vorher auch mal das Wort Profiler erwähnt (zumindest gedacht). Optimieren ist ne feine Sache, aber man muss wissen, was man tut.

Was richtig eklig ist und wovon man eigentlich die Finger lassen sollte:
Selbstmodifizierender Code - hässlich, einfach hässlich.
 
Ein Beispiel für schlecht zu testendes sind z.b Servlets die wichtige Daten aus von ServletContainer bereitgestellte Objecte beziehen. Z.b eben ServletContext Object, und ähnliches.

Es hält einen nichts davon ab, Daten vorzugeben. So kann ich durchaus ein ServletContext Object selber erzeugen und in der JUnit ein TestServlet von diesem Servlet ableiten welches die Methode getServletContext() überschreibt und somit mein eigenes ServletContext zurückgibt. Benötige ich nur die Attribute aus dem ServletContext so überschreibe ich in meienm ServletContext die Methoden getAttribute und setAttribute und schreibe / lese aus einem extra definierten HashMap.
So habe ich die Möglichkeit die Werte die das ServletContext beherbergt von Hand zu definieren, und somit auch die Möglichkeit auch bestimmte Werte zu erwarten.

Um Zusammenhänge zu dokumentieren sind JUnit wirklich eine sehr gute Wahl, denn
mann erkennt wie wird ein ein Teil angewendet, welche Ergebnisse werden erwartet und
weiteres.

Ich betone nochmals es gibt Dinge die zu dokumentieren sind, aber ganz oft sind Dinge
einfach falsch wenn sie eine ausgiebige Dokumentation benötigen.
 
Zurück