Wieviel Zeit braucht ihr für was beim Programmieren?
-
Wieviel Prozent der Zeit braucht ihr geschätzt für welche Tätigkeiten beim Programmieren?
Also z.B. 20% für SW Design/Planung, 10% für Code tippen, 20% für Ausprobieren und Testen, 20% für Bugs fixen, ?% für was ihr sonst so macht...So Sachen wie Projektzeiten planen oder andere Tester testen lassen, sind hier nicht gemeint.
Bei Zeiten für Bugs fixen, meine ich nicht Bugs die ihr von Kunden bekommt, sondern Fehler die in eurer ersten Umsetzung sind, also irgendwelche falschen oder vergessenen Bedingungen, Flüchtigkeitsfehler oder sonstige Sachen die erst auffallen, wenn ihr euren Code selber testet.
-
das kommt alles immer darauf an, was du machen willst und in wie fern du dich in dem bereich auskennst. beispielsweise brauche ich oft bei sachen, mit denen ich mich sehr wenig bis noch nie beschäftigt habe ersteinmal 30% zum recherchieren und dazulernen..
Im algemeinen aber immer so 20% plaung und klassendesign; 10% code tippen; 40% testen verbessern testen und weiter entwickeln und testen; 20% für bugfixes und die letzten 10% für nachträgliche änderungen des klassendesigns etc.
-
Schwer zu sagen... Planung und Klassenentwurf passiert oft auch nebenbei, wenn man schon mal anfängt oder recherchiert. Sowas schreib ich eh selten auf, sondern hab das meist im Kopf, von dem her kann man schlecht sagen, wieviel das genau ausmacht.
Code tippen eigentlich nicht so viel... Wohl schon mehr als 10%, aber vielleicht Größenordnung 20-30. Das meiste ist Testen und Debuggen.
-
Kommt drauf an. Bei kleinen Aufträgen ist es wohl eher wenig Planung und viel Tippen. Bei großen Aufträgen und insbesondere bei privaten Geschichten bin ich eigentlich nur am planen. (~85% der Zeit vermutlich.)
Mit testen verbringe ich eigentlich eher wenig Zeit, zumindest bei C++. Irgendwie läuft das meiste einfach.
(Abgesehen natürlich von dem einen Compilerfehler und dem einen Bug den man immer hat. Wenn diese Fehler nicht kommen, war entweder die Aufgabe trivial, oder der Compiler ist kaputt.
)
-
Ich brauche ewig.
-
Alte Regel der Programmierung: Nur triviale Programme sind bugfrei, aber welches Programm ist trivial?" Man kann auch anders fragen: "Was kostet ein Stück Programm?"
-
Wenn man mich beim Programmieren beobachten würde, dann würden man mich selten viel Tippen sehen, sondern eher Recherchieren, oder auf ein Blatt Papier irgendwelche geometrischen Formen verbinden sehen. Auch hoch im Kurs steht das einfach starren auf Code, der irgendwie nicht so will wie ich mir das vorgestellt hatte.
Als ich das noch beruflich gemacht hatte, kam ich mir immer blöd vor, weil ich recht wenig mir der Tastatur gemacht habe und alle immer bestimmt dachten, der arbeitet ja gar nicht.
Ich bin mir bis heute nicht sicher, ob ich da so ziemlich allein bin mit meiner Art zu Programmieren.
-
cooky451 schrieb:
Bei großen Aufträgen und insbesondere bei privaten Geschichten bin ich eigentlich nur am planen. (~85% der Zeit vermutlich.)
Bei privaten Projekten bin ich schon seit Jahren bei 100% planen. Ich denke eigentlich nur noch über Architektur, den Aufbau, die Anforderungen usw. nach, male Diagramme, aber programmier gar nichts. Programmiert hab ich schon genug, mittlerweile macht mir der reine Entwurf in der Hinsicht mehr Spass. Somit muss ich auch nicht testen oder Bugs fixen.
-
Und woher weißt du dann ob das Entworfene überhaupt funktionieren würde? Macht ja nicht viel Sinn irgendwas zu planen was sich zwar gut anhört, aber bei der Implementierung dann Probleme geben würde.
-
100% schrieb:
Und woher weißt du dann ob das Entworfene überhaupt funktionieren würde? Macht ja nicht viel Sinn irgendwas zu planen was sich zwar gut anhört, aber bei der Implementierung dann Probleme geben würde.
Weiß ich nicht. Würde es wahrscheinlich auch nicht, so wie die meiste Software halt. Darum gehts ja nicht. Warum programmiert man überhaupt? Privat geht es selten um das Ziel, ein marktreifes Produkt zu entwickeln. Man will Spass haben und was lernen. Code eintippen ist für mich mittlerweile größtenteils Routine, dazu kann ich mich privat kaum noch überwinden. Ich kann mir die Projekte jetzt auch sehr viel besser vorstellen, als früher. Als Schüler musste ich noch sehr viel ausprogrammieren, um die Probleme zu merken, ich musste vieles austüfteln. Jetzt kann ich mir das meiste eh schon vorstellen. Die tatsächliche Implementierung an sich spielt keine so große Rolle mehr, mir gehts nur um Konzepte und die Architektur. Was würde es mir bringen, da tatsächlich mit dem Programmieren anzufangen? Ich weiß von vornherein, dass es sehr viel Aufwand wäre, auf den ich keine Lust mehr hätte und dann würde ich es früher oder später aufgeben. Und das was ich mir überlege wäre auch nicht so stark von konkreten Implementierungsproblemen betroffen, man muss sich nur tief genug reindenken, dann kann man sehr viele Probleme schon vorher erkennen, unwahrscheinlich, dass man da was so gravierendes übersieht, dass man die komplette Architektur über den Haufen schmeißen müsste (macht man bei richtigen Projekten ja eh nie). Und solche Gedankenspiele machen mir mittlerweile viel mehr Spass, als Code einzutippen. Aber wie gesagt, natürlich ist es denkbar, dass bei der konkreten Umsetzung dann noch einiges auffallen würde, weswegen man das Konzept ändern müsste, aber das ist normal.
-
Schreib doch ein Buch drüber, wo du so ein paar Standardanwendungen mal auf dem Reißbrett entwickelst. Ich würde sowas gerne lesen, denn ich habe noch bei jeder Klasse die zu meinen Projekten dazu kommt nicht immer das beste Gefühl. Aber irgendwie muss ich anfangen und auch mal was fertig machen, egal ob es dann schlecht designt ist. Lieber ein schlecht gemachtes Programm(vom Code her) als gar keins.
-
So schlecht ist der Ansatz nicht. Perfekt geplant und zu Papier gebracht. Dann fotografiert und einem Compiler VisualMake übergeben. Der macht daraus das Programm. Ich melde schon mal für den Produktnamen VisualMake meine Urheberschaft an.
-
Lichtweite schrieb:
Schreib doch ein Buch drüber, wo du so ein paar Standardanwendungen mal auf dem Reißbrett entwickelst. Ich würde sowas gerne lesen, denn ich habe noch bei jeder Klasse die zu meinen Projekten dazu kommt nicht immer das beste Gefühl.
Es gibt viele Bücher über Softwarearchitektur. Ich bin nicht gut genug, was entscheidendes beitragen zu können.
Lichtweite schrieb:
Lieber ein schlecht gemachtes Programm(vom Code her) als gar keins.
Warum? Ich hab mich explizit nur auf private Projekte bezogen. Und privat programmier ich wie gesagt eben nicht mehr, dabei kommt zu 99% sowieso kein "Programm" raus, es ist sehr selten, dass man privat irgendwas tatsächlich fertigmacht. Und private abgebrochene Projekte hab ich schon dutzende wenn nicht hunderte, da kann ich mir das lästige Programmieren auch gleich sparen und mir nur noch Gedanken über die Architektur machen, dabei komm ich viel weiter.
-
Die Bücher über Softwarearchitektur die ich so überflogen habe, gehen doch meist alle "bloß" auf die Theorie ein. Ich würde gerne eins lesen, wo nur die absolut nötigsten Theorien kurz angerissen werden und dann an konkreten Projekten das Design angegangen wird und auf drauf eingegangen wird nicht jeden Fliegenfurz zu generalisieren. So dass Anfänger die C++ so einigermaßen anwenden können und sich nun fragen wie wird nun aus den ganzen Sprachfeatures eine Einheit, in der man sich nicht gleich verwurschtelt und die man Stück für Stück implementieren kann ohne Angst für dem großen Ganzen haben zu müssen.
Keine Ahnung was man da für Beispiele nimmt: Ein kleine Editor mit Plugins, oder ein Minispiel, oder irgendwas mit Eingabemasken und Datenbankabfrage keine Ahnung.
Mit den nie fertigen Privatprojekten magst du recht haben, aber vieles hat auch oft als Hobbyprojekt angefangen. Es können also nicht alle so arbeiten wie wir^^
-
Ich hab damals auch sehr viel geplant, um dann oft festzustellen, dass eh alles anders kommt, als man denkt...
Mittlerweile bin ich bei der iterativen Programmierung angekommen. Ich fertige das Produkt also so, wie ich es mir grob überlegt habe. Wenn ich im nachinein feststelle, dass das so nicht optimal ist, dann werfe ich diesen Teil über Bord und implementiere ihn neu.
Der Faktor Zeit ist hier sicher größer, aber das Endergebnis ist für mich zufriedenstellender.
-
Lichtweite schrieb:
Die Bücher über Softwarearchitektur die ich so überflogen habe, gehen doch meist alle "bloß" auf die Theorie ein. Ich würde gerne eins lesen, wo nur die absolut nötigsten Theorien kurz angerissen werden und dann an konkreten Projekten das Design angegangen wird und auf drauf eingegangen wird nicht jeden Fliegenfurz zu generalisieren. So dass Anfänger die C++ so einigermaßen anwenden können und sich nun fragen wie wird nun aus den ganzen Sprachfeatures eine Einheit, in der man sich nicht gleich verwurschtelt und die man Stück für Stück implementieren kann ohne Angst für dem großen Ganzen haben zu müssen.
Das habe ich mich früher auch gefragt und es hat eine Weile gedauert, bis ich einen besseren Überblick hatte. Da gehört auch einiges an Erfahrung dazu, ich denke nicht, dass man das so ganz auf die Schnelle lernen kann, kann auch gut sein, dass man mit den Büchern auch nicht sofort was anfangen kann, war bei mir auch so.
So theoretisch sind die Bücher nicht, zumindest viele davon. Einige versuchen natürlich, das ganze möglichst abstrakt und trocken zu verpacken, aber man findet auf jeden Fall auch gute Bücher. Zwischen Sprachfeatures und Softwarearchitektur liegen mehrere Stufen, also lass dir ruhig Zeit, das kommt nach und nach. Wenn du aufhörst, in Sprachfeatures zu denken und genügend Probleme selbst gesehen hast, wird es dir dann nicht mehr so theoretisch vorkommen und du wirst deine Denkweise entsprechend anpassen. Dann denkt man primär an das große Ganze und die konkrete Implementierung wird eher nebensächlich aus Architektursicht, da kann dann auch nicht mehr so viel schiefgehen.
-
Na ja, Sprachfeatures beeinflussen Patterns schon signifikant. Java/C#/C++ haben halt relativ ähnliche Features was OOP angeht, weshalb man hier Lösungen "abstrakter" beschreiben kann. Aber Move Semantik, Variadic Templates etc. haben schon großen Einfluss, auch auf das "Gesamtbild".
-
cooky451 schrieb:
Na ja, Sprachfeatures beeinflussen Patterns schon signifikant. Java/C#/C++ haben halt relativ ähnliche Features was OOP angeht, weshalb man hier Lösungen "abstrakter" beschreiben kann. Aber Move Semantik, Variadic Templates etc. haben schon großen Einfluss, auch auf das "Gesamtbild".
Klar, meist legt man sich auf eine Sprache fest, und dann berücksichtigt man auch die Features und Idiome dieser Sprache und das zieht sich dann oft auch bis ganz nach oben durch. Ist aber nicht so entscheiden für die Architektur an sich (zumindest bei dem was ich mir meist so überlege), nur für die "Form" der Architektur.