Wie oft baut ihr euer Programm um?
-
-
Täglich, ich verdiene mein Geld damit.
-
Was Tyrdal damit sagen will ist wohl etwas in die Richtung wie:
"The software isn't finished until the last user is dead."
— Sidney Markowitz...und dass die Software -- vor allem bei evolutionären Entwicklungsmodellen -- einem ständigen Refactoring-, Review- und Verbesserungsprozess unterliegt.
Das reicht von besserer Bezeichnerbenennung über Code-Extrahierung bis hin zum Umbau ganzer Architekturen.
-
Ich programmiere solange an einem Programm, bis alle Funktionalitäten, die der Kunde sich wünscht - und unter einem realistischen Zeitaufwand umsetzbar sind - nach dem "Clean Code Kodex" implementiert wurden.
Zum Thema Clean Code: http://www.clean-code-developer.de/
-
Viel interessanter wäre doch die Frage, in welchem Takt ihr auf den Compiler Button drückt (oder eben make usw. ausführt)?
Für jeden Fliegenschiss, oder programmiert ihr erstmal nen Stück Code runter und schaut dann, ob's compiliert?
-
Compiler-Button-Takt?
Kommt auf die Entwicklungsumgebung an
Es gab da einige RAD-Tools, die zickig wurden, wenn man nicht nur den letzten Schritt ändern wollte.
Je nach dem, wenn es läuft und ich nichts vermisse, warum ändern?
Wenn sich die Anforderungen ändern, dann halt das Programm um bauen.Wozu soll so eine Frage gut sein?
Warum antworte ich auch noch?
-
Bessere Frage schrieb:
Viel interessanter wäre doch die Frage, in welchem Takt ihr auf den Compiler Button drückt (oder eben make usw. ausführt)?
Für jeden Fliegenschiss, oder programmiert ihr erstmal nen Stück Code runter und schaut dann, ob's compiliert?
kommt immer auf die stelle an... aber auch das ist mir im moment nicht wichtig.
Phisherman schrieb:
Ich programmiere solange an einem Programm, bis alle Funktionalitäten, die der Kunde sich wünscht - und unter einem realistischen Zeitaufwand umsetzbar sind - nach dem "Clean Code Kodex" implementiert wurden.
hab keine kunden und bin der einzigste user und entwickler meiner software... zeitaufwand ist so ne sache, meine eltern haben mir jetzt die pistole auf die brust gesetzt, bis ende des jahres muss ich raus aus dem nest
-
4 teens schrieb:
Je nach dem, wenn es läuft und ich nichts vermisse, warum ändern?
Wenn sich die Anforderungen ändern, dann halt das Programm um bauen.wenn ich es 'fertig' hab, tauchen immer wieder stellen auf, die einfach langsam sind und ich mir einbilde mit einer anderen architektur schneller zu sein, dann wird umgebaut - ein teufelskreis
-
Hast du dir mal den von mir geposteten Link angeschaut? Falls nicht, solltests du es mal. Dort steht genau dein Problem drin:
Quelle: http://www.clean-code-developer.de/Roter-Grad.ashx
Im Vordergrund steht immer die Verständlichkeit von Code. Optimierter Code ist aber oft alles andere als lesbar. Indem er auf das absolut Notwendige in kürzester Form reduziert ist, mag er zwar die funktionalen und nicht funktionalen Anforderungen des Kunden erfüllen – doch er spiegelt sie meist nicht mehr verständlich wider. Das ist kontraproduktiv im Sinne der meist gewünschten Langlebigkeit einer Software.[...]Die Pfadfinderregel ist also nicht so gemeint, dass immer weiter nach Codeoptimierungen gestrebt werden sollte. Sie bezieht sich vielmehr auf deren Gegenteil: Verständlichkeit und Evolvierbarkeit.
-
die einfach langsam sind und ich mir einbilde mit einer anderen architektur schneller zu sein
architektur hat für mich nichts mit einer konkreten funktionsimplementation oder mikro-/codeoptimierungen zu tun, auch kleinere 'klassen' wenn man in c überhaupt von sowas reden kann, baue ich in letzter zeit eher selten um und kann sie relativ gut wiederverwenden aber wenn ich vor einer mauer steh, wo ich unbedingt durch will, muss die einfach weg
-
Eine letzte Idee von mir: Wie wäre es, vor dem Implementieren der Programmfunktionalitäten ein (UML-)Diagramm zu erstellen, um damit effizienter, weil einfacher lesbar, "langsamen" oder dir nicht zusagenden Code zu korrigieren?
-
uml kann erfahrung nicht ersetzen, wenn ich davon etwas mehr hätte, würde es sicher was bringen.
-
Bessere Frage schrieb:
Viel interessanter wäre doch die Frage, in welchem Takt ihr auf den Compiler Button drückt (oder eben make usw. ausführt)?
Für jeden Fliegenschiss, oder programmiert ihr erstmal nen Stück Code runter und
schaut dann, ob's compiliert?Mehr als 10 Zeilen programmiere ich so gut wie nie, ohne den Compiler anzuwerfen. Da ich mit C# arbeite, ist das kein Problem da die Compilezeiten sehr gering sind.
Phisherman schrieb:
Eine letzte Idee von mir: Wie wäre es, vor dem Implementieren der Programmfunktionalitäten ein (UML-)Diagramm zu erstellen, um damit effizienter, weil einfacher lesbar, "langsamen" oder dir nicht zusagenden Code zu korrigieren?
UML ist die größte Trollaktion in der Softwaregeschichte. Es hat exkat Null Wert, UML-Bildchen zu malen. Für einen Programmierer ist Code immer einfacher lesbar als Diagramme. Die Diagramme enthalten keine nützliche Information, die sich nicht wesentlich präziser und ohne Mehraufwand auch in Code ausdrücken liesen.
UML ist was für Wirtschaftsinformatiker und Dünnbrettentwickler, die nicht richtig programmieren können und ihre Software-Enigneering Vorlesungen kritiklos geschluckt haben.
-
Oder anders: Ein total verhurtes Klassendesign wird nicht auf magische Weise besser, nur weil man es vorher in ein UML-Diagramm gegossen hat. Und ein gutes Klassendesign ergibt sich umgekehrt nicht einfacher durch UML. Eher im Gegenteil. Der Detailteufel liegt in der Sprache.
-
lolalter schrieb:
UML ist die größte Trollaktion in der Softwaregeschichte. Es hat exkat Null Wert, UML-Bildchen zu malen. Für einen Programmierer ist Code immer einfacher lesbar als Diagramme. Die Diagramme enthalten keine nützliche Information, die sich nicht wesentlich präziser und ohne Mehraufwand auch in Code ausdrücken liesen.
Das ist Quatsch.
Wenn du erstmal deine Klassendiagramme mit einem Plotter auf A0 Papier gedruckt hast, dann wirst du von UML begeistert sein, wieviel Überblick es dir auf einen Blick bietet.
Das kannste du mit normalem sequentiellen Code nicht.
-
2d Plotter schrieb:
Das kannste du mit normalem sequentiellen Code nicht.
Dafür sind Kassenrollen wunderbar geeignet. Mein Chef bezahlt pro Meter Code.
-
Ich drücke Compielerbutton erst, wenn ich mit allem, was ich an dem Tag schreiben wollte, fertig bin. Die Aktion verursacht mir zu viel Ablenkung und durch ständiges Drücken werden die Syntaxfehler auch nicht von alleine gehen und mit der Zeit wird man einfach besser darin, die zu vermeiden.