LOC/Tag
-
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.
