Je suis développeur junior (~ 3 ans d'expérience) et mon travail consiste à concevoir un nouveau système. Mon développeur principal sera l'architecte principal, mais il m'a mis au défi d'essayer de concevoir le système moi-même (en parallèle).
Au fil de quelques itérations d'idées de brainstorming et proposant ce que je considérais comme des suggestions d'architecture, mon responsable m'a indiqué que la plupart de ce que je faisais était "conçu" et non "architecturé".
Il a décrit la différence en tant qu'architecture indépendante de la mise en œuvre, alors qu'une conception est la description d'une implémentation. Il a dit que je devais enlever mon chapeau de designer et mettre mon chapeau d'architecte. Il m'a donné quelques conseils sur la façon de procéder, mais j'aimerais également vous poser la question suivante:
Comment sortir du mode concepteur de logiciel et commencer à penser davantage comme un architecte?
Voici quelques exemples de "designs" que j'ai créés et qui n'étaient pas considérés comme pertinents par l'architecture pour l'architecture:
- Je suis arrivé avec un algorithme pour charger et décharger des ressources de notre système et mon responsable a dit que les algorithmes ne sont catégoriquement pas architecturaux.
- Je suis venu avec un ensemble d'événements que le système devrait être en train de dresser et dans quel ordre il devrait les élever, mais cela aussi n'a pas semblé le couper en tant qu'architecture.
Il me semble que je suis pris dans les détails et que je ne recule pas suffisamment. Je trouve que même lorsque je trouve quelque chose qui se situe au niveau de l'architecture, j'y arrive souvent en essayant diverses implémentations et en bricolant dans les détails, puis en généralisant et en faisant abstraction. Quand j'ai décrit cela à mon tour, il a dit que je prenais la mauvaise approche: je devais penser «de haut en bas» et non de «bas en haut».
Voici quelques détails plus spécifiques sur le projet :
- Le projet que nous architectons est une application Web.
- Je compte entre 10 000 et 100 000 lignes de code.
- Nous sommes une start-up. Notre équipe d'ingénieurs est composée de 3 à 5 personnes.
- La chose la plus proche à laquelle nous pourrions comparer notre application est un CMS léger. Il présente une complexité similaire et traite en grande partie du chargement et du déchargement des composants, de la gestion de la structure et des modules de style de plug-in.
- L'application est ajax-y. L'utilisateur télécharge le client une fois, puis demande les données requises par le serveur.
- Nous utiliserons le modèle MVC.
- L'application aura une authentification.
- Nous ne sommes pas très préoccupés par la prise en charge des anciens navigateurs (ouf!), Nous cherchons donc à tirer parti des informations les plus récentes et les plus performantes qui soient. (HTML5, CSS3, WebGL?, Extensions de source multimédia et plus encore!)
Voici quelques objectifs du projet :
- L'application doit évoluer. À court terme, nos utilisateurs atteindront des centaines, voire des milliers, mais nous prévoyons des dizaines de milliers, voire des millions.
- Nous espérons que l'application sera là pour toujours. Ce n'est pas une solution temporaire. (En fait, nous avons déjà une solution temporaire, et ce que nous concevons est le remplacement à long terme de ce que nous avons).
- L'application doit être sécurisée, car elle peut entrer en contact avec des informations personnelles sensibles.
- L'application doit être stable. (Idéalement, il serait stable par rapport au niveau de gmail, mais il n'aurait pas besoin d'être à la limite d'un rover sur Mars.)
la source
Réponses:
Tout d'abord, je dirais que la différence entre architecture et design réside principalement dans la sémantique. Certaines équipes ont des points de contrôle entre les deux. Votre responsable technique définit l’architecture comme avant la conception et l’architecture comme indépendante de la mise en œuvre. À partir de là, je suppose que nous parlons de conception comme dans le modèle en cascade et non de conception industrielle, ce qui vous aiderait à concevoir le produit en vue des utilisateurs avant d’arriver à l’architecture logicielle. Je pense que l'architecture se glisse souvent dans la conception et que ce n'est pas nécessairement une mauvaise chose. Il est souvent très utile pour l'architecte de connaître en profondeur ce qui est possible dans le système actuel.
Cela dit, vous avez besoin de conseils pour la situation dans laquelle vous vous trouvez. Il existe tout un monde d’architecture logicielle, de documents, de livres, de conférences, mais vous recherchez généralement des modèles et des abstractions. Sans plus de détails sur le projet, je ne peux que donner un exemple général. Par exemple, si vous travailliez en intégration, il existe une architecture orientée service ( SOA).) modèle dans lequel vous divisez des parties du système en «services» afin de pouvoir utiliser chaque partie de manière définie. Dans un programme Web, cela est souvent ensuite implémenté en tant que services Web (bien que cela ne devrait pas être aussi limité que cela) et plus récemment la montée en puissance d'API RESTful avec JSON, encore une fois, je dirais qu'il s'agit d'un design issu de l'architecture SOA. Je dirais que Modèle, Vue, Contrôleur (MVC) est un autre exemple de modèle d'architecture couramment utilisé, qui répartit la responsabilité des composants d'un système pour permettre aux pièces d'être échangées, de contenir des erreurs et de tester.
À partir de 10000 pieds, si vous pouvez dessiner sur un tableau blanc et l'expliquer à un programmeur compétent qui ne travaille pas dans votre domaine et ne connaît pas votre langage de programmation ni les détails de sa mise en œuvre, alors c'est probablement de l'architecture. Si vous pouvez écrire un livre à ce sujet qui intéresserait tout le monde en dehors de votre entreprise, alors c'est probablement de l'architecture. Si vous trouvez votre propre explication et ne pouvez pas le généraliser à d'autres bases de code / sociétés / industries, alors c'est probablement la conception.
Je conviens que les deux exemples que vous donnez sont la conception de code et non l’architecture. La première parce que je pense que lorsque vous dites que vous avez proposé un «algorithme» pour le chargement des ressources, vous voulez dire que vous avez conçu un ensemble d'instructions pour accomplir cette tâche, et non que vous avez conçu un nouvel algorithme qui sera enseigné en 1ère année COMSC l'année prochaine. Dans le deuxième exemple, encore une fois, je conviens que c'est du design. Si vous me montriez l'une ou l'autre de ces idées, je ne pourrais pas les utiliser dans mon projet de logiciel aléatoire. Vous devez accéder à un "niveau supérieur", orienté objet (OO) en Java plutôt que de vouloir que la classe client soit une sous-classe de la classe de personnes. Même parler d’Exceptions en général pourrait être considéré comme un niveau trop bas (trop proche de la mise en œuvre).
Pour essayer de répondre aux spécificités que vous avez énumérées, je pense que vous devriez réfléchir à la façon de concevoir un CMS basé sur le Web. Wordpress a un codex sur l’architecture de site où ils parlent beaucoup des détails d’implémentation de la conception, mais il est clair dans le post que leur architecture principale est centrée sur la possibilité de rendre Wordpress extensible avec des thèmes. Concevoir une interface claire pour un thème tel qu'il puisse être écrit par quelqu'un de l'extérieur de la société était clairement une décision d'architecture. C’est le genre de choses qu’il est bon de mettre sur le papier lors de l’architecture de votre solution «à long terme» (et non temporaire) afin que toutes les décisions de conception et d’implémentation prises au cours du développement (par tous les développeurs, pas seulement l’architecte). sont en ligne avec cette idée.
Autres exemples d'architecture pour votre situation:
Essayez peut-être de dessiner tout le système sur un tableau blanc. Essayez-le à différents niveaux de détail, le premier tableau pourrait être GUI-> dispatcher-> backend-> DB ou quelque chose du genre, puis explorez jusqu'à ce que vous commenciez à utiliser des pronoms.
la source
La distinction entre ces deux idées est vraiment importante là où je travaille.
Ce que vous appelez "architecture", nous l'appelons "programmation en anglais". Ceci est en partie important parce que si vous ne pouvez pas le décrire à un non-programmeur, alors quelque chose ne va pas. Il se peut que vous ne compreniez pas assez bien le problème OU que vous résolviez un problème "fantôme" (non traité ici).
Les termes utilisés pour ces deux aspects différents de la conception sont souvent différents, mais les principes sont facilement reconnus partout. Un aspect (dans votre cas, l'architecte, dans mon cas, le concepteur) programme en anglais, tandis que l'autre (dans votre cas, "designer", dans mon cas, "développeur") programme dans une langue particulière. Ils sont également assez communément distingués comme "conception" et "implémentation". "Design" est ce qu'il est censé accomplir et "implémentation" est le code qui le rend possible.
Quelques exemples de ce sur quoi j'ai travaillé:
L’architecture d’un programme est la suivante: nous avons besoin d’un gestionnaire centralisé ou d’un hub auquel nous pouvons facilement ajouter des modules. Ce gestionnaire distribuerait des événements à tous les modules enregistrés. Un module peut s'inscrire lui-même auprès du gestionnaire d'événements et publier ainsi des événements sur le reste du système, et recevoir des événements qui le concernent. Chaque module a une "boîte aux lettres" qu'il peut vérifier et vider à sa guise. Cela nous permettrait d’adapter de nouveaux modules dont nous ne savons pas encore le besoin.
Aucun code là-bas. Pourrait être écrit dans n'importe quelle langue. L'implémentation n'est pas dictée par cette description.
L’architecture d’un autre projet est la suivante: nous avons besoin d’un moyen de démarrer et d’arrêter de manière fiable d’autres programmes sans les attendre. Nous pourrions avoir un gestionnaire responsable d'un programme particulier. Nous pouvons simplement lui dire de démarrer ou d'arrêter son programme et le responsable s'en charge. Si on demande à cet autre programme de s’arrêter et ne le fait pas dans un laps de temps donné, le responsable sait comment le forcer à s’arrêter et nettoyer le désordre. Le programme n'est pas démarré ou arrêté par quoi que ce soit d'autre, et on peut demander au responsable si son programme est en cours d'exécution, arrêté ou en attente d'arrêt. Cela nous permet de continuer avec les autres tâches que nous devons faire, tout en continuant à démarrer et à arrêter correctement ces autres programmes.
Encore une fois, rien n’impose ici la mise en œuvre, bien que certaines mises en œuvre soient clairement plus utiles que d’autres.
La différence entre la conception (ce que nous appelons des modèles ou l'implémentation) et l'architecture (ce que nous appelons la conception) est que l'un d'eux résout un problème de codage / implémentation et l'autre, un problème réel.
la source
Peut-être que ça va aider. J’ai toujours considéré l’ancienneté d’un ingénieur comme une question de l’ampleur du problème qu’ils pouvaient résoudre eux-mêmes.
En gros, pour transmettre l'idée:
Vous pouvez donner à quelqu'un de novice en programmation de petites tâches contenues avec de nombreuses instructions explicites sur la manière dont la tâche doit s'intégrer à d'autres éléments.
Un développeur de niveau intermédiaire est une personne qui peut décrire une partie d’une application et la faire fonctionner dans le contexte de cette application.
Un développeur senior peut créer une application de taille moyenne à partir de zéro, dans le respect des contraintes techniques d'un magasin.
Un développeur plus expérimenté peut le faire et faire des choix technologiques en cours de route sur les technologies à utiliser pour que cela fonctionne bien.
... mais ce ne sont pas des règles strictes. Et certaines personnes sortent de la porte avec un IMHO "senior", même si elles doivent passer du temps avec un titre différent.
Ce que l’architecte demande, c’est de voir le problème encore plus généralement. Si vous deviez créer plusieurs applications pour faire fonctionner le système:
Donc, dans un sens, l’architecture technique est comme une architecture de bâtiment. C'est la mise en page, ou le plan. Cela montre ce qui est nécessaire pour les différentes parties, comment elles se tiennent ensemble et pourquoi .
(BTW, les architectes m’ont expliqué la même courbe de croissance, allant de l’architecture d’une famille d’applications associées ou d’un ensemble de fonctionnalités très complexes à la définition d’une direction technique pour un groupe à la prise de décisions techniques stratégiques pour l’ensemble d’une organisation. .)
Cela dit, je pense que la plupart des ingénieurs, à tous les niveaux, doivent également faire de l’architecture. Ce n'est pas une ligne brillante. Il semble que si vous vous concentrez d'abord sur la grande image sans vous attarder sur les détails de la mise en œuvre, vous serez plus en phase avec ce qu'il recherche. BTW, la capacité de voir la grande image ainsi que les petits détails est un atout considérable dans cette industrie, donc cela semble être une grande opportunité.
... Voici une analogie. Disons que vous êtes invité à créer une boîte noire magique. En tant qu’ingénieur, vous devez être obsédé par le fonctionnement interne de la Magic Black Box. Mais en tant qu'architecte, votre objectif est différent. Vous pouvez jeter un coup d'œil dans la boîte par curiosité, mais vous devez être obsédé par tout ce qui entoure les Magic Black Box.
Semblable à cette analogie, vous pourriez penser que le rôle de l’architecture consiste à considérer l’ ensemble du système comme une boîte magique. Donc, si vous prenez une Gigantic Glass Box et que vous placez les clients, les applications clientes, le pare-feu, le niveau de service, la base de données et même les développeurs de Devops à l'intérieur, alors en tant qu'architecte, vous êtes obsédé par la fabrication de cette énorme boîte système. fonctionne bien .
la source
La différence exacte entre "design" et "architecture" est un peu subjective et il y a un certain chevauchement. Cependant, voici la différence si je comprends bien:
L'architecture prend en compte les concepts de haut niveau. Qui sont les acteurs du système? Quels sont les principaux objets et lesquels sont responsables de quoi? Quand je pense à l'architecture, je pense à Visio, pas au code.
Par exemple, un système d'événements peut avoir un gestionnaire d'événements qui accepte les événements entrants et les distribue aux gestionnaires d'événements. L'idée des threads, asynchrone vs synchrone, et d'autres concepts de niveau inférieur n'entre pas en jeu ici. MVC est un autre exemple: les détails spécifiques ne sont pas spécifiés au niveau élevé de la manière dont les trois éléments interagissent, mais seulement qu'il existe trois problèmes distincts traités par des packages de code distincts.
La conception implique le prototypage, l’esquisse des interfaces de code, des squelettes de code, etc. Elle se situe entre l’architecture abstraite et le travail de bas niveau "code singe".
Dans un cadre d'événements, la conception peut indiquer "un événement utilise cette interface" et "il existe un pool de threads que le gestionnaire d'événements utilise pour distribuer des événements aux travailleurs". Une conception pour MVC pourrait être "utiliser Hibernate pour le modèle, Spring pour le contrôleur et GWT pour la vue".
Lorsque je dessine, j'ai des croquis d'interfaces et de squelettes de code, puis je transmets les résultats aux programmeurs. Parfois, je suis ce programmeur. Mais ce sont deux phases distinctes, et les deux existent plus vers le concret que l’architecture.
Mettre le chapeau sur l’architecture signifie libérer votre esprit du code et penser des objets sur un tableau blanc. Pensez aux objets, aux packages, aux frameworks et à la circulation des messages entre eux. Si vous songez à une seule ligne de code, vous vous trompez. Ne vous embourbez pas dans des mots tels que "oh, ce message pourrait être une chaîne, ou utiliser SOAP, ou autre chose." A ce niveau, le fait qu'il y ait communication est suffisant. Les détails ne sont pas pertinents.
la source
Ne pensez pas comment vous allez écrire le code pour accomplir quelque chose, mais réfléchissez à la meilleure méthode pour le faire. Votre description de ce que vous devez faire doit être indépendante de la langue . Vous allez donc parler de modèles de conception (qui sont un "langage" commun entre utilisateurs de différents langages de programmation) afin de discuter de la marche à suivre.
Pour votre cas d'utilisation spécifique, d'autres questions architecturales, à mon avis, iraient dans le sens de:
En gros, ne parlez pas du tout de code. Même si vous ne savez pas comment faire quelque chose, quand il y a une volonté, il y a un moyen . Réfléchissez davantage à la manière dont les pièces du puzzle s'agenceront le mieux avant de vous inquiéter de les assembler.
la source
Pensez à toutes les opérations (par exemple, les cas d'utilisation) que votre système peut effectuer. Pour chaque opération, documentez ce qui se passe en termes de domaine métier pour chaque opération. Vous ne devriez parler qu'en termes de domaine du problème et ne pas décrire les détails de la mise en œuvre. Dessinez un gros bloc et appelez-le Système. La combinaison de ce "gros bloc" et des descriptions d'opération est l'architecture système de plus haut niveau.
Bien que cette architecture de haut niveau constitue un bon point de départ, elle n’a vraiment pas beaucoup de valeur lors de la construction d’un système réel. Vous devez en prendre un niveau de détail pour en faire une architecture utile.
Vous suivez donc la même idée générale que l'approche "gros bloc", à la différence que vous commencez à ajouter les "sous-blocs" nécessaires à l'exécution de chaque opération. Ces "sous-blocs" sont fréquemment appelés classes ou modules de domaine. Celles-ci sont facilement identifiables à l'aide de vos descriptions d'opération (de la méthode des gros blocs) et de schémas de séquence. Elles sont appelées classes de domaine car elles ne sont pas destinées à être de "vraies" classes, mais elles sont destinées à décrire votre système en termes de domaine problématique de votre système.
Le résultat final de la création de tout le diagramme de séquence et de l'identification de tous les "sous-blocs" est que vous disposez maintenant d'une liste de classes de domaine et de leurs listes d'opérations. Cela aboutit généralement à une architecture logicielle relativement utilisable, dans laquelle chacun des "sous-blocs" / modules pourrait être fragmenté pour être conçu et mis en oeuvre par différents développeurs.
Bien sûr, si vous le laissez tel quel, vos concepteurs auront beaucoup d'interactions les uns avec les autres pour définir les interfaces entre les modules. Ainsi, l’architecte peut également décider des mécanismes d’interface et des types de données spécifiques à utiliser entre les modules.
En outre, certains "sous-blocs" seront toujours très compliqués sous le capot. Ainsi, une autre itération de l'approche "sous-bloc" peut être nécessaire, mais uniquement cette fois sur l'un des modules nouvellement identifiés.
Enfin, il peut exister des schémas / limitations spécifiques entre les interfaces auxquelles l'architecte souhaite que le système adhère (par exemple, les rappels d'événements par opposition aux appels de méthode directs). Il est donc nécessaire de prendre en compte ces décisions dans la conception architecturale. De plus, il peut y avoir des modules "communs" que l'architecte veut que tout le monde utilise.
la source
En tant que développeur, vous êtes probablement habitué à fournir des solutions. C’est une très bonne façon de penser, mais cela peut vous empêcher de penser à l’architecture.
Je trouve que cela aide à décrire le problème que vous essayez de résoudre en premier. Quelles sont les exigences? Quelles sont les contraintes? Pouvez-vous parler aux parties prenantes pour connaître ces exigences?
Cela pourrait être utile si vous pouviez également décrire vos propres objectifs de conception. Votre solution doit-elle évoluer ou une conception pour un utilisateur unique est-elle suffisante? Combien de temps votre solution doit-elle rester valide? Est-ce une solution ponctuelle ou une solution d'infrastructure à long terme? Peut-être aussi important: quelles sont les limites acceptées de votre architecture?
Et puisqu'il s'agit d'une expérience d'apprentissage, n'ayez pas peur de poser des questions, même si elles sont ridicules.
la source