Il y a beaucoup de choses à prendre en compte lors de la création d'un système, prenons par exemple un système basé sur le Web où les utilisateurs se connectent et interagissent les uns avec les autres, créant et éditant du contenu. Maintenant, je dois penser à la sécurité, à la validation (je ne pense même pas être sûr à 100% de ce que cela implique), "s'assurer que les utilisateurs ne se marchent pas les uns les autres" (terme pour cela?), Prévenir les erreurs dans de nombreux des cas, en vous assurant que les données de la base de données ne deviennent pas problématiques en cas de ... situations inattendues? Toutes ces choses que je ne sais ni comment ni où apprendre, existe-t-il un livre sur ce genre de choses? Comme je l'ai dit, il semble y avoir une énorme différence entre écrire du code et réellement écrire le bon code, vous voyez ce que je veux dire? J'ai l'impression que mon travail de programmation actuel manque beaucoup de ce que j'ai décrit et je peux voir les problèmes qu'il provoque plus tard, puis les problèmes sont beaucoup plus difficiles à résoudre car les données existent et les gens les utilisent. Alors, quelqu'un peut-il me diriger vers des livres ou des ressources ou le sous-ensemble approprié de programmation (?) Pour ce type d'apprentissage?
PS: n'hésitez pas à corriger mes tags, je ne sais pas de quoi je parle.
Edit: Je suppose que certains des exemples que j'ai écrits s'appliquent également à d'autres types de systèmes, je ne connais tout simplement pas d'autres bons exemples parce que j'ai été principalement impliqué dans le travail sur le Web.
la source
En ce qui concerne les applications Web, il y a plus de bonnes informations compilées dans cette réponse que tout autre endroit que j'ai jamais vu.
Mais la réalité est qu'il y a beaucoup à savoir pour bien assembler un système complet. Il y a des études pour soutenir 10 000 heures comme quantité de pratique nécessaire pour atteindre un niveau de maîtrise, et le développement de systèmes d'information ne fait pas exception à cela.
la source
J'aime beaucoup la réponse de William Pietri (+1), mais je pense qu'elle doit être complétée. Même en supposant que ce que vous entendez par systèmes comprend uniquement des logiciels.
Mais avant d'entrer dans le vif du sujet, je ne connais pas de livre pour vous aider. Tout ce qui suit, j'ai appris par expérience (c'est-à-dire les trois points que William a soulevés).
Ce dont vous parlez s'étend sur au moins quatre grands rôles. Parfois, une personne peut remplir tous ces rôles, pour des projets de petite à moyenne taille, mais lorsque vous commencez sur de grands projets, vous devez au moins quelque peu séparer ces rôles. Il est difficile pour quiconque d'être expert dans tous les domaines de manière significative.
Analyste d'affaires
C'est la personne qui parle au client et traduit ses besoins en quelque chose qu'un architecte peut comprendre. Fondamentalement, une liste d'exigences correctement formulées. Cela comprend les exigences fonctionnelles évidentes (que doit fournir ce système?), Mais également les exigences non fonctionnelles (quelles sont les caractéristiques générales que le système doit remplir? Cela peut inclure la sécurité, la fiabilité, la disponibilité, la résilience, la capacité, les performances, la robustesse et d'autres exigences du point de vue de l'utilisateur).
C'est la première étape de ce que le système doit faire, le tout début d'une réflexion sérieuse.
Architecte système
Cette personne produit le cadre technique de haut niveau dans lequel travailler. Ils donnent le plan de match. Les outils généraux, techniques, constructions. Ils décomposent l'ensemble du système en composants plus petits, comment ils s'intègrent les uns aux autres, comment ils s'adaptent au monde extérieur ...
Cela aide à bien des égards à affiner ce qui doit être pensé. Très souvent, des problèmes seront découverts à ce stade concernant les exigences telles que rédigées par l'analyste commercial. Retour à eux pour quelques itérations pour améliorer leur compréhension de ce qu'ils veulent et leur expression.
Concepteur de système
Ce rôle consiste à faire en sorte que tout fonctionne. Cela pourrait être plus un travail d'équipe qu'un one-man show. Mais il y a probablement un concepteur principal pour superviser la conception globale du système. Cette personne doit creuser dans les détails et s'assurer que la vue de l'architecte peut réellement être construite.
Attendez-vous à un raffinement supplémentaire de l'architecture du système, et donc potentiellement de l'analyse commerciale.
Responsable des tests
Ce rôle est très souvent oublié. Mais au bout du compte, si vous ne pouvez pas le tester, comment pouvez-vous prouver que vous pouvez le construire? Il doit y avoir un examen des résultats de toutes les étapes: analyse commerciale, architecture et conception par une personne compétente en test qui sera en mesure de mettre en évidence les lacunes et donc de permettre des corrections précoces, bien avant qu'un code ne soit écrit.
Voilà un bref résumé.
Ces gars / filles ne sont que la direction générale des gens de l'usine dans la chaîne pour réfléchir à ce qui doit être pensé.
Pour les projets complexes tels que les grandes applications bancaires ou spatiales, pour ne prendre que deux exemples (pensez à plusieurs centaines à plusieurs milliers de jours-homme), il existe de nombreux experts en la matière que nous appelons pour examiner et soutenir les projets à chaque étape. Ces rôles comprennent l'analyse de la sécurité, le dimensionnement du système, la capacité, les performances, les bases de données, le clustering et de nombreux autres domaines d'expertise étroits, y compris des domaines d'activité précis. La variété des rôles dépend de la taille et de la complexité des systèmes.
Tout cela pour dire que vous ne devriez pas essayer de tout savoir, vous ne le ferez pas. Vous pouvez cependant avoir une idée globale et sur de petits projets, vous pouvez approfondir beaucoup plus que sur de grands projets, tout simplement parce que le niveau de complexité vous permet d'être plus complet.
Si vous voulez savoir comment concevoir des systèmes, vous devez commencer à poser des questions en sortant des sentiers battus. Mettez-vous suffisamment à la place du client et essayez de penser à ce qui pourrait mal tourner, à ce qui doit être testé. Rassemblez-vous ensuite avec un vrai client et incitez-le à expliquer l'étendue et les limites du système dont il envisage avoir besoin. De plus, chaque fois que je dis «client», vous devez comprendre que cela englobe plusieurs personnes très différentes. Il y a la personne qui utilise le système jour après jour pour ce qu'il a été conçu. Il y a l'opérateur, le support technique, le gestionnaire qui a besoin d'un rapport ou d'un autre, l'auditeur, l'équipe d'infrastructure, la partie prenante qui l'a payé, le responsable qualité qui a besoin de moyens pour tester votre système ... Demandez à tous (et si ils sont une seule personne, demandez-leur de mettre tous ces chapeaux un par un), alors demandez-leur tous ce dont ils ont besoin et vous aurez un bon début pour savoir quelles sont vos exigences système. De là, vous pouvez dériver l'architecture, et de là la conception.
Pour les systèmes complexes (logiciels uniquement ou à intégrer au matériel dans le sens le plus générique), non seulement une personne ne suffit pas pour chacun des quatre rôles énumérés ci-dessus, mais vous devez gérer le projet, même la définition de ce que le système doit faire, sans parler des autres phases.
HPH, asm.
la source
Pas "un livre". Beaucoup de livres.
Il n'y a pas de route royale
Droite.
Vous parlez "d'architecture", de programmation dans son ensemble.
Étape 1. Lisez beaucoup de code. Beaucoup. Pensez aux choses que vous aimeriez faire. Trouvez des projets open source associés. Lisez le code. Tout.
Étape 2. Lisez plus de code. Beaucoup plus.
Étape 3. Lisez des livres sur l'architecture.
la source
Pour amplifier beaucoup de livres lus ....
Maintenant que vous savez que vous avez un problème, il est utile de vous dire de lire ces livres. (Avant d'avoir fait du vrai travail, il est inutile de discuter de ces livres)
Design Patterns by Gamma, Helm, Johnson and Vlissides Pattern Patterns of Program Design 1,2,3 and 4.
Mais n'essayez pas d'appliquer chaque motif partout où vous voyez qu'il pourrait être utilisé
c'est aussi une mauvaise chose.
J'espère que cela t'aides.
la source
La meilleure façon d'apprendre à faire quoi que ce soit est de le faire. Si vous voulez apprendre à parler français, vous devez parler français, lire le français et écrire le français et lire le français et aller en France et parler aux français en français. Si vous voulez savoir comment jouer du piano, vous devez réellement jouer du piano. Vous devez jouer des chansons simples et apprendre la structure du piano et la structure de la musique. Vous devez apprendre à lire la musique et à exprimer la musique au piano avec vos doigts. Vous devez apprendre à quoi ressemble la musique et quels types de sons un piano peut produire par rapport à ce qu'une guitare, une flûte ou un saxophone peut faire.
La programmation est exactement la même. Si vous savez comment concevoir une base de données, vous devez concevoir des bases de données. Si vous voulez comprendre la cryptographie, implémentez des algorithmes cryptographiques et des protocoles cryptographiques. Si vous souhaitez écrire un logiciel pouvant servir simultanément plusieurs utilisateurs, vous devez comprendre le fonctionnement des E / S disque, des E / S réseau et des threads. Pour comprendre comment cela fonctionne, vous devez écrire du code qui lit et écrit à partir de fichiers, transmet des données sur un réseau et synchronise l'accès aux ressources. Tout cela nécessite de la pratique.
Un «système» n'est, en général, qu'une collection de choses. Des pièces qui se coordonnent pour former un tout. Pour construire quelque chose de grand, vous devez construire un tas de petites pièces. Donc, si vous voulez apprendre à construire des systèmes, commencez simplement à construire des systèmes. Prenez un problème, décomposez-le et implémentez chaque pièce une par une. Finalement, vous aurez un "système" intégré. Vous échouerez probablement plusieurs fois en cours de route, mais ça va. Si vous n'échouez pas, cela signifie généralement que vous n'essayez pas assez fort.
Aussi, je recommanderais d'aller à l'école pour étudier l'informatique. Cela n'aidera pas trop avec la partie "pratique". Vous devrez le faire vous-même, mais cela vous aidera avec la partie exposition. Vous en apprendrez beaucoup sur à peu près tout ce qui concerne le fonctionnement des ordinateurs et des systèmes informatiques, ce qui est difficile à apprendre par vous-même.
la source