Was ist der Unterschied zwischen einem Prototyp und einer Lösung auf Produktionsebene?

Diese Frage dient lediglich dem Lernen und der Verbesserung meines technischen Verständnisses. Ich weiß, dass es keine perfekte Lösung gibt und diese Frage eine unendliche Lösungsliste hat, aber ich denke, es ist sehr wichtig, dass jeder Architekt den Unterschied zwischen Demo und einem Live-Projekt versteht.

Ich habe in der Vergangenheit viele Demolösungen in .Net erstellt. Ich wurde nun beauftragt, eine Weblösung auf Produktionsebene zu entwerfen und zu implementieren, und wollte daher auf sehr hoher Ebene fragen, was erforderlich ist, um eine Demo in eine Lösung auf Produktionsebene umzuwandeln. Nach meinem Verständnis erfordert dies (abgesehen von der funktionalen Umsetzung der Kundenanforderungen):

1. Unit-Test jeder Methode
2. Sicherstellen, dass eine Codeabdeckung von ~ 100% erreicht wird
3. Protokollierung aller Ausnahmen und möglichen Punktschnitte - möglich mit AOP
4. Verwenden des Schnittstellenentwurfsmusters, Abhängigkeitsinjektion, möglicherweise mithilfe eines Frameworks, z. B. spring.net
5. Verwenden von Leistungsindikatoren und Profilern zur Instrumentierung
6. Anwenden der entsprechenden Sicherheit - dh Windows-Authentifizierung (wenn dies vom Client verlangt wird).
7. Transaktionsmanagement für jede einzelne Methode
8. Sichern Sie die Webanwendungsdateien vor der neuen Bereitstellung der Lösung

Was sonst?

Meine Frage bezieht sich eher auf die technische Seite als auf die Funktion / Dokumentation, da wir sonst einen anderen Weg einschlagen werden :-)

Vielen Dank.

Ich denke, der wichtigste Unterschied besteht darin, dass das Ziel eines Prototyps Folgendes ist:
1. zu beweisen, dass ein Problem auf eine bestimmte Weise gelöst werden kann ODER
2. dem Kunden / Management ein Gefühl dafür zu geben, wie das Produkt aussehen und sich anfühlen würde

Das Ziel eines Live-Systems ist:
1. Ein bestimmtes Problem zu lösen / ein Problem anzugehen.

Beachten Sie, dass die Ziele der beiden völlig unterschiedlich sind .
Daher sollte meiner Meinung nach ein Prototyp weggeworfen werden, bevor ein Live-System entwickelt wird .

Dies liegt auch daran, dass ein Prototyp normalerweise ein "schnelles und schmutziges" Projekt ist, das ohne die Überlegungen zusammengeführt wird, auf die Sie in Ihrer Frage zu Recht hingewiesen haben (wie Tests, Leistung, Sicherheit und vieles mehr).
Sie sind also besser dran, ein neues, richtiges Projekt zu starten, als zu versuchen, ein schlechtes Projekt besser zu machen.

Abhängig von Ihren Anforderungen sind nicht alle diese Dinge erforderlich, oder es ist möglicherweise viel mehr erforderlich. Wenn Sie wissen, was ich meine;) Unit-Tests und Codeabdeckung sind gute Dinge, aber je nachdem, wie Sie andere Teile des Prozesses ausführen, sind sie möglicherweise nicht erforderlich. Einige würden sagen, dass gut dokumentierter Code oder ein Schulungshandbuch wichtiger als Leistungsprofile sind. Es variiert!

Mir ist klar, dass Sie sich mit der technischen Seite befassen, aber hoffentlich werden Sie meinen Standpunkt verstehen. Er hängt von der nichttechnischen Seite ab. Zumindest sollte es so sein.

Die Verwendung von Leistungsindikatoren und Profilern für die Instrumentierung ist möglicherweise geeignet, aber möglicherweise massiv übertrieben. Könnte nicht erforderlich sein.

Was Sie hier vermissen, ist, dass Sie den Kontext, den Umfang und die Geschäftsanforderungen des Projekts nicht berücksichtigen.

Mit Kontext und Umfang meine ich - schaffen Sie etwas, das von einem Unternehmen intern verwendet werden kann? Kundenkontakt? Von Endbenutzern verwendet? Ist es tatsächlich eine jazzige Version von Notepad oder ein neues RDBMS von Grund auf neu? Was enthalten sein sollte, hängt massiv (massiv!) Von dem Projekt ab, das Sie sich ansehen.

Mit Geschäftsanforderungen meine ich nicht die Anwendungsfälle für die Software, sondern die Anforderungen des Projektmanagements / Produktionsprozesses. Wenn Sie darauf bestehen, dass Sie all diese Dinge für ein Produktionsprojekt benötigen, werden die Kosten entsprechend reflektiert (sehr hoch). Das könnte entweder bedeuten, dass das Budget zu spät ist oder nicht einmal grünes Licht für den Beginn der Entwicklung gegeben wird.

Es könnte sein, dass es wichtiger ist als ein fester Kriteriensatz, einfach einen guten Produktions- / Entwicklungsrahmen, eine hohe Sichtbarkeit und regelmäßige Veröffentlichungen zu haben, damit die Qualität auf diese Weise bewertet werden kann. Es könnte sein, dass niemand, der daran beteiligt ist, einen Mist über die Codeabdeckung macht.

Interessanterweise denke ich, dass die Punkte 1, 2, 4 und 7 bereits bei der Konzeption Ihres Prototyps ausgeführt werden sollten, außer dass Sie nicht jede Methode in jeder Klasse testen sollten . Testen Sie den kritischen Code und nicht, ob sich get / set-Methoden korrekt verhalten.

Abhängig vom Zweck Ihrer Anwendung, bei dem die Sicherheit ein großes Problem darstellt, kann Punkt 6 so kritisch sein, dass Sie ihn im Prototyp erreichen müssen. Abhängig vom Zweck Ihrer Anwendung, bei dem die Leistung der Schlüssel ist, kann Punkt 5 kritisch sein ... Sie wissen, was ich meine. Meiner Meinung nach können die Punkte 3, 5 und 6 im Prototyp erforderlich sein, wenn sie als kritisch angesehen werden (Punkt 8 gilt wirklich für Produktionsanwendungen).

Bearbeiten: Es scheint, dass meine Meinung völlig von der von sJhonny abweicht, weil ich impliziere, dass ich den Prototyp als Grundlage / Hülle / Skelett Ihrer zukünftigen Entwicklungen betrachte, sodass der Prototyp für mich nicht weggeworfen werden darf.

Zusätzlich zu dem, was bereits erwähnt wurde, benötigen Sie in einem Produktionsprojekt (unter anderem) Folgendes:

0-Wählen Sie eine Implementierungsmethode

1-Finalisieren und veröffentlichen Sie wichtige Anforderungen (einschließlich Anwendungsfälle usw.).

2-Machen Sie die Architektur richtig

3-Wählen Sie die richtigen Werkzeuge

4-Design-Datenbank für Leistung

5-Erstellen Sie Ihr Klassendesign und Workflow-Design

6-Bestimmen und implementieren Sie eine Strategie zur Integration von unterstützten Datenbanken / Datenquellen / Feeds

7-Sicherheitsanforderungen definieren und implementieren

8-Sorgen Sie für die physische Implementierung (Server, Konnektivität, Lizenzen usw.)

9-Planen Sie die Speicheranforderungen und legen Sie die Leistungsmessungen fest

10-Produzieren Sie alle Artefakte und installieren Sie sie in der Produktionsumgebung

11-Test

12-Liefern Sie die endgültige Lösung und implementieren Sie Feedback

Das wichtigste Merkmal von Produktionsqualitätslösungen ist meiner Meinung nach die Robustheit .

Unabhängig davon, was passiert, geht die Lösung vernünftig mit der Situation um, benachrichtigt die Wissensbedürftigen und macht weiter (wenn der Fehler behoben werden kann).

Es gibt zwei Arten von Prototypen:

• Schnelle und schmutzige "Proof-of-Concept" -Anwendungen, die "bereinigt" werden und zum Produktionscode werden. Die Phase "Aufräumen" ist entweder ein Albtraum oder eine Phase, in der die Probleme unter den Teppich gekehrt werden, was zu massiven technischen Schulden führt.

• "Mockup" -Prototypen oder "Wireframes". Dies können UI-Skizzen mit Papier und Bleistift oder sogar interaktive Modelle sein, die in einer Sprache erstellt wurden, in der Sie solche Dinge schnell zusammenfügen können, ohne viel darüber nachzudenken, wie sie zusammenpassen. Es sollten gefälschte Daten, keine echte Architektur usw. verwendet werden. Der Punkt ist, dass sie den Stakeholdern eine Vorstellung davon geben, wie das System aussehen wird, damit Sie Ihre Anforderungen verfeinern können, sie jedoch NICHT als Teil Ihrer endgültigen Lösung verwendet werden können .

Ich bevorzuge die zweite Art. Sie werden rausgeworfen, weil es nicht wirklich eine Wahl gibt.

Ich sage, bauen Sie es wie ein Projekt ohne Demo, aber jetzt können Sie das, was Sie aus der Demo gelernt haben, in Ihr Design aufnehmen. Die anfängliche Codierung kann schlecht sein, selbst wenn Sie mit der Produktion beginnen. Sie werden sowieso viel davon umgestalten müssen.

Das eigentliche Problem ist Ihre Zeitbeschränkung. Wenn die Entscheidungsträger möchten, dass Sie weiter an der Demo arbeiten, haben sie den Eindruck, dass ein Großteil der Anwendung fertig ist, sodass es nicht so lange dauert. Ich habe gehört, dass andere diese Logik verwenden, um Kunden lieber Skizzen zu zeigen, als zu realistische Modelle. Achten Sie auf den Demo-Code, da er möglicherweise Probleme entdeckt hat, an die Sie nie gedacht haben und die Sie in diesem Prozess wahrscheinlich nicht dokumentiert haben. Sie müssen sie jetzt berücksichtigen (zu stark vereinfacht, aber ja, auf die Datenbank kann beispielsweise nicht zugegriffen werden.).

Nicht alle Prototypen und Demos sind gleich. Der gesamte Code könnte wertlos sein oder bestimmte Teile könnten sehr gut gemacht worden sein. Es spielt keine Rolle, ob es sich um eine Demo handelt, Sie müssen den Unterschied kennen. Sie würden nicht einfach eine Legacay-App rauswerfen und von vorne anfangen, oder? Vergiss, fragte ich.