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