LOC/Tag
-
Wie machst du einen Prototypen, wenn du keinen Code schreibst?
-
Was? Sicher nicht! Du wirst wohl kaum deine Ideen gleich in Code umsetzen? Sowas kommt zuerst auf Papier, dann in eine Spezifikation, dann erst mal in einen Prototypen. Gut, muss nicht ganz so übertrieben schlimm sein, aber am Anfang eines Projektes schreibe ich oft gar keine Zeile Code. Zuerst muss zumindest eine grobe Architektur her. Ideen werden gesammelt und aufeinander abgestimmt.
Das kann man vielleicht machen wenn man hobbymäßig programmiert, aber nicht wenn man in einer Firma arbeitet. Das wird viel zu teuer was du da alles vorher machen willst.
-
LOC haben so gut wie keine Aussage.
Und wenn man 700 Zeilen am Tag schafft, muss das ziemlich triviales Zeug sein. Ich glaub im Mittel komm ich so auf 50 Zeilen am Tag.
-
Als ich neulich in 10 Jahre altem Code etwas gesucht habe, landete ich in einer cpp-Datei, in der sich nix bei mir auf dem Bildschirm verändert hat, obwohl ich weiter auf F3 rumgedrückt habe. Irgendwann habe ich gemerkt, dass sich die Zeilennummern links am Rand aber doch ständig verändert haben. Dann musste ich fast weinen.
-
hustbaer schrieb:
Wie machst du einen Prototypen, wenn du keinen Code schreibst?
Das war etwas schlecht formuliert
Aber es ist möglich Prototypen zu erstellen ohne Code zu schreiben. Habe ich letztens im Bereich von Usability gesehen. Die haben die ersten Prototypen auf Papier entwickelt. Das sah äusserst seltsam aus. Die sind mit A4 und A3 Papier zum Kunden gegangen und haben das UI durchgespielt. Der Kunde hat auf das Blatt "gedrückt" und der Entwickler hat ein anderes Blatt Papier hingelegt. Bei einem komplexen GUI, wo es vielleicht auch noch Probleme in der Kommunikation mit dem Kunden gibt, könnte dies vielleicht noch hilfreich sein, um erstes Feedback zu erhalten. Allerdings muss ich sagen, dass ich dort schon etwas gestutzt hatte
prot schrieb:
Das kann man vielleicht machen wenn man hobbymäßig programmiert, aber nicht wenn man in einer Firma arbeitet. Das wird viel zu teuer was du da alles vorher machen willst.
Die Standardausrede: Wir müssen schreiben! Wir müssen schreiben! Das Produkt muss fertig werden! Wir können uns doch keine Gedanken zur Architektur machen! Wo denken sie nur hin?
Das die Entwicklung dann einfach länger dauert und deutlich mehr Fehler am Ende im Code sind ... das sehen gewisse Leute einfach nicht. Gibt inzwischen schon genügend Forschungsergebnisse, welche klar aufgezeigt haben, dass eine gute Planung (kannst gerne RUP nehmen, aber womöglich wäre eine agile Planung besser :D) zu deutlich besseren und schnelleren (damit im Endeffekt günstigeren) Ergebnissen führt als ein wildes drauf los programmieren. Das bedeutet aber meistens, dass am Anfang noch nicht programmiert wird. Ideen schreibt man auf, bis man dazu übergeht Prototypen zu schreiben. Unter Umständen setzt man die Ideen aber noch nicht mal dort um und schreibt weiter neue Ideen nur auf. Erst über die Zeit womöglich mit einem evolutionären Prototypen fängt man dann an, die Ideen in den Programmcode zu schreiben. Gewisse Dinge wird man aber auch dann zuerst mal noch zurückstellen müssen.Umso weniger Planung du hast, desto mehr Code wirst du löschen, umschreiben, Fehler suchen, debuggen, usw. Oder anders gesagt: Unnötige Arbeit verrichten und damit Geld aus dem Fenster werfen.
Grüssli
-
Dravere schrieb:
Aber es ist möglich Prototypen zu erstellen ohne Code zu schreiben. Habe ich letztens im Bereich von Usability gesehen. Die haben die ersten Prototypen auf Papier entwickelt. Das sah äusserst seltsam aus. Die sind mit A4 und A3 Papier zum Kunden gegangen und haben das UI durchgespielt. Der Kunde hat auf das Blatt "gedrückt" und der Entwickler hat ein anderes Blatt Papier hingelegt. Bei einem komplexen GUI, wo es vielleicht auch noch Probleme in der Kommunikation mit dem Kunden gibt, könnte dies vielleicht noch hilfreich sein, um erstes Feedback zu erhalten. Allerdings muss ich sagen, dass ich dort schon etwas gestutzt hatte
Bei Web Anwendungen ist es ähnlich. Du lieferst zuerst das Design und dann meckert der Kunde an der Farbzusammenstellung und verschiebt ein paar Elemente und dann setzt du dich an den Code ran.
Geht tw natürlich auch parallel weil im Backend vieles ja schon feststeht - aber prinzipiell geht man zuerst mit einer Grafik zum Kunden. Und Sachen die der Kunde nicht versteht wird dann als Klick-Dummy implementiert, also zB eine Animation oder gewisse Überblendungen oder sowas. Aber halt auch ohne "Code", eben nur in HTML und vielleicht ein bisschen JS wenn nötig. Aber ohne Backend.
-
Dravere schrieb:
...
Bei uns ist es genauso. Robert C. Martin kann von dem was du sagst nen Lied singen, oder besser noch schreiben
- http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
-
Dravere schrieb:
Ich habe eher das Gefühl, dass ich mehr Code schreibe, desto weiter ich im Projekt voranschreite.
Dann hat die Planung funktioniert. Solche Projekte machen Spaß.
-
KasF schrieb:
Dravere schrieb:
...
Bei uns ist es genauso. Robert C. Martin kann von dem was du sagst nen Lied singen, oder besser noch schreiben
- http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882Dein Nachfolgebuch kann ich auch jedem empfehlen: http://www.amazon.com/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073/ref=sr_1_1?s=books&ie=UTF8&qid=1318246298&sr=1-1
-
also 2666 hab ich leider noch nie geschafft... aber paar hundert gehen schon
btw. ich denke tausend sind die schallmauer
-
Dravere schrieb:
Planen
Das mag durchaus sinnvoll sein. Aber du musst bedenken, dass ich als Hobbyprogrammierer viele Projekte habe, bei denen ich anfangs kaum eine Idee von der konkreten Umsetzung habe. Ich starte diese Projekte ja eben, um zu lernen. Natürlich führt das dazu, dass ich alle zwei Wochen das halbe Design auf den Kopf stellen muss, aber anders geht es halt nicht. Vernünftig planen kann man leider erst, wenn man schon eine gute Vorstellung von dem hat, was man machen möchte.
-
cooky451 schrieb:
Dravere schrieb:
Planen
Das mag durchaus sinnvoll sein. Aber du musst bedenken, dass ich als Hobbyprogrammierer viele Projekte habe, bei denen ich anfangs kaum eine Idee von der konkreten Umsetzung habe. Ich starte diese Projekte ja eben, um zu lernen. Natürlich führt das dazu, dass ich alle zwei Wochen das halbe Design auf den Kopf stellen muss, aber anders geht es halt nicht.
Das ist auch eine Art von Planen. Wenn es dann dreimal über den Haufen geworfen wurde, wird der Entwurf sich langsam stabilisieren und Tag für Tag kann man mehr Code passend hinzufügen, bald aus dem Ärmel schütteln.
-
Jemand hats mal schön auf den Punkt gebracht:
Bill Gates schrieb:
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
Softwaredesign löst man imo am besten iterativ. Erfahrung hilft einem bei der Wahl guter Startwerte
(das hat auch schonmal jemand irgendwie so ähnlich gesagt iirc)
-
Das kann man vielleicht machen wenn man hobbymäßig programmiert, aber nicht wenn man in einer Firma arbeitet. Das wird viel zu teuer was du da alles vorher machen willst.
Und Dein Vorgehen wird noch teurer im Test (ach ja auch zu teuer) und in der Produktion (Fehlersuche).
Diese Programmierweise ist eher hobbymäßig.
-
6. Verwende aus Effizienz-Gründen "cut/paste/clone/modify". Dies ist wesentlich effizienter, als dafür kleine, wiederverwendbare Methoden zu schreiben. Außerdem erhöht es die LOCs (Lines of Code), und damit Deine Produktivität.
Quelle: http://www.javatux.de/J4L/AntiRules.html
-
David W schrieb:
KasF schrieb:
Dravere schrieb:
...
Bei uns ist es genauso. Robert C. Martin kann von dem was du sagst nen Lied singen, oder besser noch schreiben
- http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882Dein Nachfolgebuch kann ich auch jedem empfehlen: http://www.amazon.com/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073/ref=sr_1_1?s=books&ie=UTF8&qid=1318246298&sr=1-1
Ist das zweite Buch eine Art Neuauflage des ersten oder sind beide Bücher unabhängig voneinander, sodass man beide lesen sollte/könnte?
-
Ne, keine Neuauflage, die Bücher sind unabhängig voneinander.
Beim ersten Buch "Clean Code" geht es um den Code an sich, wie man sauberen Code schreibt, was sauberen Code aus macht usw.
Bei dem Buch "Clean Coder" geht es um den Programmierer als Person, wie man Professionalität erlangt, sich durchsetzt usw.Die beiden Bücher ergänzen sich sehr gut
-
Danke!
Klingt interessant, werde ich mir mal näher anschauen.
