Bewährte Praktiken beim Prototyping?

Question

Inwieweit werfen Sie beim Prototyping bewährte Verfahren zugunsten von Code-and-Fix-Hacking über Bord? Zugegeben, der Code ist nicht dazu gedacht, in der Produktion eingesetzt zu werden.

Hinzufügen: Ich arbeite an einem ziemlich großen semi-working-Prototyp in Python, um herauszufinden, die UI für eine eingebettete Anwendung gemacht. Ich weiß, dass der Code nicht für die Produktion gedacht ist, aber es ärgert mich trotzdem, dass die Qualität der Codebasis mit der Anzahl der Änderungen stetig abnimmt.

Answer 1

Leider habe ich schon zu viele Prototypen aus Zeitgründen zum Basisprodukt werden lassen. Im Idealfall befolgen Sie also bewährte Verfahren. Realistischerweise tun Sie, was nötig ist, um die Arbeit zu erledigen und die angestrebte Frist einzuhalten. Erwarten Sie nicht, dass Sie die Möglichkeit haben, den Text komplett umzuschreiben. Das, was Sie vorlegen, wird häufig die Grundlage sein, vor allem, wenn die Entwicklung mehr als ein paar Tage gedauert hat. Der beste Rat ist, zu lernen, die besten Praktiken mit der Geschwindigkeit eines Hackers anzuwenden.

Answer 2

Das hängt davon ab, was Ihr Prototyp beweisen soll. Erstellen Sie einen Prototyp der Benutzeroberfläche für die Benutzerfreundlichkeit und zur Demonstration für Kunden oder erstellen Sie einen Prototyp der Architektur?

Wenn ich einen Prototyp für eine Benutzeroberfläche erstelle, werfe ich alles weg, sobald sich das Konzept durch Iterationen bewährt hat.

Wenn ich einen Prototyp für eine Architektur erstelle, dann wird der endgültige Code den besten Praktiken entsprechen und brauchbar sein.

Abgesehen davon ist es erstaunlich, wie viele Prototypen aus Zeit- oder Budgetgründen in der Produktion landen. Wenn der Code nicht in die Produktion einfließen soll (z. B. ein UI-Prototyp), kann es sinnvoll sein, Screenshots zu erstellen, anstatt sie zu programmieren.

Answer 3

Ich verwerfe "saubere" Methoden und Kommentare (d.h. Utility-Klassen, die "Dinge geschehen lassen"), aber keine "Geschäftsobjekte", wenn Sie so wollen.

Wenn ich zum Beispiel die Wahl habe, eine Klasse "Car" zu definieren, um die Stringwerteigenschaften "WheelCount" und "DoorCount" zu definieren, oder nur eine schnelle Hashtable zu erstellen, werde ich in der Regel etwas mehr Zeit in die Erstellung der Klasse Car investieren.

Der Grund dafür ist, dass es sinnvoller ist, die echten Klassennamen zu betrachten, wenn ich später zurückkehre, um sie neu zu programmieren (und manchmal sind diese kleinen Klassen auf die "echte" Version übertragbar).

Die größte Gefahr beim Prototyping besteht darin, dass man denkt: "Ich bringe das später in Ordnung" und es dann nicht tut... Wenn Sie also zu irgendeinem Zeitpunkt denken: "Ich habe eine ziemlich gute Vorstellung davon, wie ich diese Klasse machen muss", dann nehmen Sie sich ein paar Minuten mehr Zeit für diese Klasse und machen Sie es richtig, damit Sie sie wiederverwenden können.

Answer 4

Ich betrachte Prototypen (die hier als "Spikes" bezeichnet werden) fast immer als Wegwerfcode. Der Sinn eines Prototyps ist es Verständnis für ein Problem gewinnen und nicht um sie zu lösen. Dieses Verständnis ist weitaus wichtiger als irgendwelche Code-Artefakte, und die korrekte Implementierung der Lösung sollte trivial sein (falls nicht, würde ich argumentieren, dass der Umfang des Spikes zu groß ist).

Sie könnten den Prototyp in einen geeigneten Zustand umwandeln, aber meiner Erfahrung nach ist es schneller, ihn von Grund auf neu zu schreiben, da er in ein größeres System integriert werden muss.

Answer 5

Bei einem Prototyp ist nur das Äußere wirklich wichtig. Wenn Sie mutig genug sind, den Code anschließend wegzuwerfen, können Sie jeden schmutzigen Trick anwenden, solange er gut aussieht.

Denken Sie daran, dass ein Prototyp nur ein Werkzeug ist, um eine Kundenreaktion zu erhalten. (Ja, das gefällt mir, oder: Warum haben Sie diese Option eingebaut?)