Je suis intéressé à apprendre à concevoir / planifier le développement d'applications Web, dans un scénario d'équipe de développeur multiple.
Assumer le rôle de "gestionnaire de projet / plomb":
Si vous avez des recommandations de livres / sites Web utiles, veuillez partager.
Suivi (ajouté 11/18/09):
Que utilisent les codeurs / développeurs comme guide pendant le codage, c'est-à-dire la création de classes, ainsi que leurs méthodes et leurs propriétés respectives?
S'il n'y a pas une liste complète (encore mutable) de classes avec leurs méthodes et ses propriétés, cette ambiguïté ne peut-elle pas être intensifiée sur chaque connaissances / expérience des codeurs, ce qui entraîne des écarts de qualité de code / utilisation de la qualité / la maintenabilité?
5 Réponses :
Kaleb, merci pour les liens; ils étaient perspicaces. Lorsque vous avez écrit "mais dans la plupart de mes expériences, les exigences et les cas de test ..." Voulez-vous dire les cas d'utilisation à la place?
dépend du type et de la taille de l'application Web. Si vous faites un petit site Web de commerce électronique avec un panier d'achat, vous passerez probablement plus d'efforts sur le côté conçu des choses et moins sur la fonctionnalité «App». Inversement, si vous construisez un grand site interne interne avec de nombreux écrans de saisie de données, la plupart de votre temps seront consacrés à la logique et aux règles de données de l'entreprise.
Personnellement, je ne suis pas un croyant dans des formats ou des processus spécifiques rigides. Je vous personnaliserai pour convenir au projet et au client en vue de communiquer clairement.
En supposant que les exigences soient déjà documentées, deux types de documents que je cherche toujours à produire au minimum pour les applications Web intensives de données basées sur le workflow sont les suivantes:
Diagrammes de flux de travail de haut niveau indiquant le flux d'écran, les modifications de statut et les actions majeures. Je trouve cela très utile comme une première étape pour éliminer les mouvements majeurs de l'application. Les flux de travail sont généralement corrélés aux différents étuis d'utilisation.
Spécifications d'écran Pour chaque écran d'entrée détaillant le format et le comportement de chaque champ. Typiquement, y compris le type de champ, la valeur par défaut, les valeurs de liste, les validations de données, les règles de visibilité et les actions qui peuvent être déclenchées, etc. Fondamentalement une petite table en s'assurant que les développeurs savent comment construire les écrans.
J'ai aussi utilisé Maquettes Balsamiq dans le projet récent pour fouetter des écrans d'application Web et Les maquettes d'écran ont formé une partie essentielle des spécifications de projet - très rapidement à produire et transmettent de nombreuses informations sur la manière dont les écrans devraient fonctionner assez difficiles à transmettre dans un document texte.
Enfin, Joel's La série sur les spécifications fonctionnelles est une lecture utile.
Tous les cas Si vous développez des interactions entre différents serveurs qui sonderont / poussent des messages à des moments différents, vous aurez besoin de Diagrammes de séquence à coup sûr.
Évitez de surdrédéfinir, dans Les diagrammes de classe Les classes inutiles ont tendance aux champignons, coupez-les, utilisez plus de méthodes, gardez une trace de l'environnement chaque classe finira vraiment à fonctionner (certains seront exécutés du côté serveur, Quelque côté client - JavaScript - Certains seront des travaux planifiés et exécutés sur le serveur réel, certains guidifient CGI (ou module) encapsulés par Web WebServer et exécutent à la demande, certains seront interfaces avec la base de données.
Définissez les limites, faites-les claire. Le côté du serveur / côté client / de la base de données est des bêtes différentes et peut prendre différents temps et personnes.
Gardez-le aussi simple que possible.
Un document spécifiant les exigences de fonctionnalité principale est la première étape.
Personnellement parlant, lorsque les applications Web sont presque toujours basées sur la base de données, je commencez à modéliser la base de données basée sur les exigences de fonctionnalité. Les entités de la carte de diagramme ERM généralement 1-1 avec des classes dans le diagramme UML et présentent déjà les relations de base.
En supposant une architecture MVC et un code bien documenté, les classes de modèle seront auto-documentant, car elles évoluent (par exemple, Oxygen phpdocumenter).
Je trouve quelque chose de simple comme un wiki fonctionne mieux pour écrire des documents plutôt que des documents formels pouvant prendre plus de temps à écrire que le code respectif, en particulier dans un environnement agile.
où je travaille, nous avons tendance à travailler par paires pour créer des objets de domaine et leurs membres, méthodes et propriétés. Les classes sont créées selon les besoins pour des histoires ou si nous nettoyons ou refactons un ensemble de classes.
Il n'y a pas de liste complète de classes, mais il existe des modèles de conception utilisés comme MVP et la foi que, étant donné qu'une paire crée quelque chose, le code s'intégrera dans le style et les directives actuelles. À mesure que les exigences évoluent, il y aura des modifications aux classes assez régulièrement, mais cela semble être un moyen naturel de faire des choses pour moi.
Contexte de l'environnement où je suis juste au cas où quelqu'un voudrait savoir:
Où je travaille, nous avons 5 développeurs, une dirigeante QA, un analyste d'entreprise, une équipe d'équipe, un architecte et un chef de projet comme principales personnes du projet pour le moment. Nous utilisons Scrum, Paire de programmation et certaines idées TDD dans notre travail.
Nous utilisons Visual Studio 2008, Subversion, HP Quality Center, ASP.NET 3.5, SITECORE 6.0 et MS-SQL Server 2005.
JB, vous avez écrit que vous avez un "arriéré", que je suppose que vous obtiendrez buêle dans les sprints; Chaque sprint étant composé de «fonctionnalités» prioritaires (cas d'utilisation). Chacune de ces "fonctionnalités" représente une ou plusieurs classes. Dans votre expérience, avez-vous rencontré une situation où travailler avec un développeur junior / moins expérimenté conduit à des problèmes dans la création des classes des «fonctionnalités»? Par exemple, si vous et votre partenaire reçoivent une fonctionnalité au code, y avait-elle une situation où il / elle n'a pas eu de classes à créer ou où certaines logiques étaient la plus appropriées?
Avec presque tout le monde, j'ai travaillé, il y a eu ces cas encore et encore. Le fait qu'il y ait de nombreuses façons de faire quelque chose a tendance à conduire naturellement à des différences d'opinion sur la façon de faire quelque chose. Discuter des différences et venir à un concensus fait partie du processus global. Peut-être que j'ai de la chance où je travaille en termes de personnes en train d'être des professionnels humbles qui s'entendent la plupart du temps. Dans une sprint donnée, il peut y avoir plusieurs fois de fois que quelqu'un ne sait pas où mettre du code ou qu'il peut y avoir des idées différentes quant à la façon de faire quelque chose.
JB, merci d'avoir partagé vos expériences. Je ne veux pas accomplir le point, mais avez-vous trouvé que les cas susmentionnés, en raison de la différence d'opinion ou de manque de connaissances, ont conduit à des problèmes de qualité de la qualité et / ou de difficulté à rencontrer des dates de brûlage de sprint?