Cette question est purement pour l'apprentissage et pour améliorer ma compréhension technique. Je sais qu'il n'y a pas de solution parfaite et cette question a une liste de solutions sans fin possible, mais je pense qu'il est très important pour chaque architecte de comprendre la différence entre une démo et un projet en direct.
J'ai créé de nombreuses solutions de démonstration dans .Net dans le passé. J'ai maintenant été affecté à l'architecte et à la mise en œuvre d'une solution Web au niveau de la production, je voulais donc demander - à un niveau très élevé, ce qui est nécessaire pour convertir une démo en une solution au niveau de la production. D'après ma compréhension, cela nécessitera (autre que la mise en œuvre fonctionnelle des exigences des clients):
- Test unitaire de chaque méthode
- Garantie d'une couverture de code de ~ 100%
- Journalisation de toutes les exceptions et coupes de points possibles - possible avec AOP
- Utilisation d'un modèle de conception d'interface, injection de dépendances, éventuellement en utilisant un framework, par exemple spring.net
- Utilisation de compteurs de performances et de profileurs pour l'instrumentation
- Appliquer la sécurité appropriée - c'est-à-dire l'authentification Windows (si c'est ce qui est requis par le client).
- Gestion des transactions sur chaque méthode
- Sauvegarde des fichiers d'application Web avant le nouveau déploiement de la solution
Quoi d'autre?
Ma question est plus liée au côté technique qu'à la fonction / documentation car sinon nous irons dans un autre chemin :-)
Je vous remercie.
Réponses:
Je pense que la différence la plus importante est que l'objectif d'un prototype est:
1. De prouver qu'un problème peut être résolu d'une certaine manière OU
2. Donner au client / à la direction une idée de l'apparence et de la sensation du produit
alors que l'objectif d'un système en direct est de:
1. Résoudre un certain problème / résoudre un problème.
Notez que les objectifs des deux sont complètement différents .
Par conséquent, à mon avis, un prototype doit être jeté avant de développer un système en direct .
Cela est également dû au fait qu'un prototype est généralement un projet `` rapide et sale '', assemblé sans aucune des considérations que vous avez correctement signalées dans votre question (comme les tests, les performances, la sécurité et bien plus encore).
Il serait donc préférable de commencer un nouveau projet approprié que d'améliorer un mauvais projet.
la source
Tout cela n'est pas requis, selon vos besoins, ou il pourrait y en avoir beaucoup plus. Si vous savez ce que je veux dire;) Les tests unitaires et la couverture du code sont de bonnes choses, mais selon la façon dont vous abordez les autres parties du processus, cela peut ne pas être nécessaire. Certains diraient que le code bien documenté ou un manuel de formation est plus important que le profilage des performances. Cela varie!
Je me rends compte que vous regardez du côté technique, mais j'espère que vous comprendrez mon point, cela varie en fonction du côté non technique. Ou du moins, ça devrait.
L'utilisation de compteurs de performances et de profileurs pour l'instrumentation .. peut être appropriée, mais peut être extrêmement excessive. Peut ne pas être nécessaire.
Ce qui vous manque ici, c'est de ne pas tenir compte du contexte, de la portée et des exigences commerciales du projet.
Par contexte et portée, je veux dire - créez-vous quelque chose à utiliser en interne par une entreprise? Face à la clientèle? Utilisé par les utilisateurs finaux? Est-ce en fait une version jazzy du Bloc-notes ou un nouveau SGBDR à partir de zéro? Ce qui devrait être inclus variera massivement (massivement!) Selon le projet que vous regardez.
Par exigences métier, je ne parle pas des cas d'utilisation du logiciel, mais des exigences du processus de gestion / production de projet. Si vous insistez pour avoir besoin de toutes ces choses pour un projet de production, le coût sera reflété en conséquence (très élevé). Cela pourrait signifier que le budget est dépassé, en retard ou même pas donné le feu vert pour commencer le développement.
Il pourrait être plus important que d'avoir un ensemble fixe de critères maintenant d'avoir simplement un bon cadre de production / développement, une grande visibilité et des versions régulières afin que la qualité puisse être évaluée de cette façon. Il se pourrait que personne impliqué ne se moque de la couverture du code.
la source
Fait intéressant, je pense que les points 1, 2, 4 et 7 devraient déjà être effectués lors de la conception de votre prototype, sauf que je ne pense pas que vous devriez tester chaque méthode dans chaque classe. Testez le code critique, pas si les méthodes get / set se comportent correctement.
Selon le but de votre application, où la sécurité est un gros problème, le point 6 peut être suffisamment critique pour que vous en ayez besoin dans le prototype. Selon le but de votre application, où la performance est la clé, le point 5 peut être critique ... Vous voyez ce que je veux dire. Mon avis est que les points 3, 5 et 6 peuvent être nécessaires dans le prototype s'ils sont considérés comme critiques (le point 8 est vraiment valable pour les applications de production)
Edit: il semble que mon avis soit complètement différent de sJhonny car j'implique que je considère le prototype comme la base / shell / squelette de vos futurs développements, donc pour moi le prototype n'est pas à jeter.
la source
En plus de ce qui a déjà été mentionné, dans un projet de production, vous avez besoin entre autres:
0-Choisissez une méthodologie de mise en œuvre
1-Finaliser et publier les principales exigences (y compris les cas d'utilisation, etc.)
2-Obtenez la bonne architecture
3-Sélectionnez les bons outils
Base de données 4-Design pour les performances
5-Produisez votre conception de classe et votre conception de workflow
6-Déterminer et mettre en œuvre une stratégie d'intégration des bases de données / sources de données / flux sauvegardés
7-Définir et implémenter les exigences de sécurité
8-Organiser l'implémentation physique (serveurs, connectivité, licences, etc.)
9-Planifier les besoins de stockage et déterminer les mesures de performance
10-Produisez tous les artefacts et installez-les dans l'environnement de production
11-Test
12-Fournir la solution finale et mettre en œuvre les commentaires
la source
La caractéristique la plus importante des solutions de qualité de production est - à mon avis - la robustesse .
Peu importe ce qui se passe, la solution gère la situation de manière sensible, informe ceux qui ont besoin de savoir et continue (si l'erreur est récupérable).
la source
Il existe deux types de prototypes:
Des applications de «preuve de concept» rapides et sales qui sont «nettoyées» et deviennent un code de production. L'étape de «nettoyage» a tendance à être soit un cauchemar, soit c'est vraiment une étape «balayer les problèmes sous le tapis», entraînant une dette technique massive.
Prototypes "maquettes" ou "wireframes". Il peut s'agir d'esquisses d'interface utilisateur papier et crayon, ou même de maquettes interactives réalisées dans un langage où vous pouvez rapidement regrouper ce genre de choses sans trop réfléchir à la façon dont elles s'emboîtent. Il doit utiliser de fausses données, pas de véritable architecture, etc. Le fait est qu'elles donnent aux parties prenantes une idée de ce à quoi ressemblera le système, afin que vous puissiez affiner vos besoins, mais elles NE PEUVENT PAS être utilisées dans le cadre de votre solution finale .
Je préfère le deuxième type. Ils sont expulsés, car il n'y a pas vraiment de choix.
la source
Je dis le construire comme un projet sans démo, mais maintenant vous pouvez inclure ce que vous avez appris de la démo dans votre conception. Le codage initial peut être mauvais même une fois que vous démarrez la production. Vous devrez refactoriser une grande partie de toute façon.
Le vrai problème à résoudre est votre contrainte de temps. Lorsque les décideurs veulent que vous continuiez à travailler sur la démo, ils ont l'impression qu'une grande partie de l'application est prête, donc cela ne prendra pas aussi longtemps. J'ai entendu d'autres personnes utiliser cette logique pour expliquer pourquoi ils préfèrent montrer des croquis aux clients plutôt que des maquettes trop réalistes. Faites attention au code de démonstration, car il a peut-être découvert des problèmes auxquels vous n'avez jamais pensé et que vous n'avez probablement pas documentés dans ce processus. Vous devez maintenant les prendre en compte (Trop simplifié, mais oui, la base de données peut ne pas être accessible par exemple.).
Tous les prototypes et démos ne sont pas créés égaux. Le code entier pourrait être sans valeur ou certaines parties pourraient avoir été très bien faites. Peu importe s'il s'agit d'une démo, vous devez faire la différence. Vous ne jeteriez pas simplement une application legacay et recommenceriez-vous? Oublie j'ai demandé.
la source