Je m'inscris à l'architecture moderne

Question

Je n'ai pas de qualifications formelles en informatique, mais je me suis enseigné l'ASP classique à l'époque du boom des dotcom et j'ai réussi à obtenir un emploi et ma carrière s'est développée à partir de là. J'étais un confiant et, je pense, assez bon programmeur en ASP 3, mais comme d'autres l'ont remarqué, l'un des problèmes avec ASP classique était qu'il faisait un très bon travail en cachant le nitty-gritty de http pour que vous deveniez assez compétent un programmeur sur la base d'une compréhension relativement pauvre de la technologie avec laquelle vous travailliez. Quand je suis passé à .NET au début, je l'ai traité comme ASP classique, en développant des applications autonomes en tant que sites individuels simplement parce que je ne savais pas mieux à ce moment-là. J'ai déménagé des emplois à ce stade et passé les quelques années suivantes à travailler sur un seul site dont l'architecture reposait fortement sur des objets personnalisés: en d'autres termes j'ai acquis beaucoup d'expérience en travaillant avec .NET comme outil de développement moyen. approche de la conception OO à la manière de l'exemple de la classe «voiture» classique qui est si souvent utilisé pour enseigner OO. Décomposer des programmes en blocs de fonctionnalités et baser vos classes et méthodes autour de cela. Bien que nous ayons travaillé sous une approche Agile pour gérer le travail, l'ensemble de l'installation était classique. Cela me convenait et je me suis progressivement familiarisé avec .NET et j'ai commencé à l'utiliser beaucoup plus comme il se doit, et j'ai commencé à voir le pouvoir inhérent à la technologie et précisément pourquoi il était tellement mieux que le bon ASP 3

Dans mon dernier emploi, je me suis retrouvé soudainement dans la partie profonde avec deux programmeurs assez jeunes, compétents et très à la fine pointe. Ils ont construit une architecture de site qui modélise beaucoup de choses qui sont nouvelles pour moi et que, en vérité, j'ai beaucoup de mal à comprendre. L'application est construite sur un modèle de cloud computing avec multi-tenancy et l'architecture est lâchement couplée en utilisant un grand nombre d'interfaces, d'usines et autres. Ils utilisent beaucoup nHibernate aussi. Peu de temps après mon arrivée, ces deux types sont partis et je suis maintenant supposé être le développeur principal d'un système dont la technologie et l'architecture ne sont pas vraiment comprises et je n'ai personne à qui poser des questions. Sauf vous, l'Internet. Franchement, j'ai l'impression d'avoir été installé dans la partie profonde et je suis en train de couler. Je ne sais pas si c'est parce que je n'ai pas la formation nécessaire pour comprendre ce genre de choses, si je ne suis pas suffisamment mathématique pour l'informatique moderne (mes maths n'ont jamais été géniales - mon approche du design consiste souvent à déboguer jusqu'à ce que ça fonctionne , puis refactoriser jusqu'à ce qu'il semble soigné), ou si j'ai simplement été présenté trop trop d'une nature trop radicale à la fois. Mais la seule façon de savoir ce que c'est est d'essayer et de l'apprendre.

Donc, quelqu'un peut-il suggérer quelques bons endroits pour commencer? De bons livres, des tutoriels ou des blogs? J'ai trouvé beaucoup de matériel sur Internet suppose simplement un niveau de compréhension que je n'ai tout simplement pas.

Votre conseil est très apprécié. Aidez un homme d'âge moyen, coincé dans le développeur de la boue à redevenir enthousiaste!

S'il vous plaît!

Answer 1

Assis sur la plage - Préparation

Marque une liste de tout ce que vous ne comprenez pas. Au stade final, cette liste sera votre liste de vérification. Ayez l'esprit en paix - oubliez tous les détails confus que vous connaissez déjà sur votre architecture. Déterrez tous les documents créés par les architectes d'origine. Obtenez les documentations pour chaque technologie utilisée dans votre projet. Faire du café.

flottant - Gérer la complexité

flotter, vous devez gérer la complexité. Si vous ne traitez pas la complexité correctement, vous plongerez dans les détails quand il n'y en a absolument pas besoin, et vous ne saurez pas comment et où arrêter, s'enfoncer dans le fond et se noyer.

« Mon approche de la conception est souvent déboguer simplement jusqu'à ce qu'il fonctionne, puis refactor jusqu'à ce qu'il a l'air soigné »

Je pense que je l'habitude d'être comme vous. J'ai développé des solutions en partant de zéro et en ajoutant une pièce à la fois, contenant éventuellement une structure complexe dans ma tête. Je n'ai pas planifié l'architecture, je n'ai pas séparé la conception et la mise en œuvre, j'ai juste codé, débogué, refactorisé. Cela a marché: la complexité augmentant lentement, je n'ai eu aucun mal à comprendre l'architecture qui a émergé.

Cette approche n'est tout simplement pas suffisante pour "hériter" d'une architecture complexe planifiée par d'autres; vous ne pouvez pas avaler toute la structure en même temps - car il y a trop de détails, et vous ne pouvez pas en avaler au hasard - parce que vous ne comprendrez pas comment ils se relient les uns aux autres et vous n'aurez jamais la vue d'ensemble.

Le logiciel est un puzzle de gestion de la complexité. Il y a de très grandes pièces, parfois appelées «sous-systèmes», qui composent la grande image. Chacun d'eux est composé de plus petites pièces, qui à leur tour sont également composées de plus petites pièces. Quand vous regardez le code, tout ce que vous voyez est les plus petites pièces. Donc, oubliez le code lui-même pour l'instant, au moins jusqu'à ce que vous voyiez toutes les grandes pièces.

Natation - Cartographie de l'architecture

La première étape vers flottante est de voir les gros morceaux. Pour ce faire, vous avez besoin de cartes. La carte pour les plus grandes pièces est l'architecture de plus haut niveau. Si les architectes d'origine vous ont laissé sans carte, vous devrez le créer vous-même. Tout comme il est impossible de mapper une région depuis l'intérieur d'une vallée, vous ne pouvez pas mapper votre architecture à partir de détails de bas niveau. Vous devez vous tenir au sommet d'une montagne pour avoir une vue à 360 degrés de toutes les vallées, collines et sentiers. Vous devez mapper votre architecture par le haut. Après avoir cette carte de niveau supérieur, vous devriez obtenir des cartes pour les parties qui la composent - tout comme vous créez une carte non détaillée d'une région entière, puis créez des cartes détaillées séparées des sous-régions. Une carte devrait décrire les différents sous-systèmes. À tout le moins, il devrait décrire les responsabilités de chaque sous-système, son interface externe et la façon dont il interagit avec les autres sous-systèmes.

plongée sous-marine - Gestion de la Détails

Il y a ce principe dans la plongée qui dit que vous ne devriez pas vous déplacer entre les profondeurs trop vite, en raison des changements de pression. Ce principe est valable. Lorsque vous passez d'un sous-système à un de ses sous-systèmes internes, assurez-vous de plonger seulement dans le niveau suivant de complexité/abstraction. Laissez votre esprit gérer un niveau à la fois.

Séparez les concepts, les modèles, les interfaces et les implémentations. nHibernate est une solution Object-Relational Mapping (ORM). Ainsi, avant de traiter les détails de nHibernate lui-même, vous devez vous assurer de comprendre le concept général des ORM et leur place dans le monde. L'usine est un modèle de conception, donc avant de traiter avec Factory, vous devez comprendre ce que sont les motifs de conception et quel est leur rôle.

Les technologies montent et descendent, mais les concepts restent. Une fois que vous avez les concepts, cela n'a pas beaucoup d'importance - au niveau architectural - comment ces concepts se manifestent. Le fait que votre architecture soit faiblement couplée est en fait une bonne chose, car cela signifie que vous pouvez comprendre le rôle d'un sous-système sans avoir besoin d'en savoir beaucoup sur les autres sous-systèmes. Le fait que votre architecture utilise des interfaces est également bon - cela signifie que vous pouvez apprendre comment les éléments interagissent les uns avec les autres sans apprendre comment ils fonctionnent en interne.

Waterskiing - L'acquisition de connaissances Distilled

Il y a un livre que je pense est un "must-read": Code complet par Steve McConnell. Cela a changé ma vie professionnelle. J'espère que cet article a réussi à vous aider d'une certaine façon et n'est pas une perte de temps totale.

Answer 2

Patterns of Enterprise Application Architecture est un excellent livre, Martin est une légende.

Answer 3

S'il s'agit d'architecture, je regarde toujours Pattern & Practices s'il s'agit de la pile de développement Microsoft.

Ils ont beaucoup de bons livres blancs/livres sur l'architecture pour toutes sortes de types d'applications.

Answer 4

En plus des nombreuses ressources déjà listées dans les réponses et probablement pour être listées, un conseil légèrement différent - utilisez StackOverflow.

Vous semblez être capable d'écrire très bien pensé, lisible et ose je le dis de bonnes questions. Donc, chaque fois qu'un certain choix architectural ou un code d'architecture n'a aucun sens, n'hésitez pas à le transformer en une question SO (idéalement, idéalement après avoir cherché un peu vous-même).

En outre, en ce qui concerne votre point re: math:

En ce qui concerne le logiciel ingénierie est concerné, le seul calcul que vous avez vraiment besoin la plupart du temps sont:

• "math discret" - ensembles, graphes, arbres etc ... et leurs applications pratiques aux structures de données et algorithmes

• Une compétence en algèbre limitée impliquée dans l'analyse de la complexité O (n) pour cette dernièreIdéalement, une compréhension intuitive de la statistique/probabilité - en tant qu'ingénieur logiciel générique, vous ne devez pas toujours être en mesure de faire des calculs avancés, mais une idée de "ceci est plus susceptible d'influer sur ma situation en fonction de son probabilité de se produire fois sa taille d'impact "est souvent un bon guide dans les choix de conception.

Cependant, une chose qui est précieux dans un bon ingénieur logiciel qui est souvent ce qui distingue « bon en maths » personne de « pas bon en maths » - sans parler strictement mathématiques liés - est la capacité de voir les modèles .

Si la raison pour laquelle vous n'êtes «pas bon en maths» est que vous ne possédez pas cette capacité d'observance, alors vous serez très désavantagé. C'est une compétence/capacité que vous devez former vous-même au-dessus de tous les autres pour réussir dans l'architecture des systèmes, à mon humble avis.

Answer 5

Voici quelques suggestions, qui ne sont en aucun cas une réponse complète ou une réponse tout-en-un;

• Prenez le temps dans votre journée de travail pour en savoir plus sur les nouveautés. Prenez cette période dans votre journée de travail parce que cela fait partie de votre travail. Ce n'est pas quelque chose que vous devriez faire seulement le soir ou le week-end. Si vous voulez passer un peu de votre temps à l'apprendre, allez-y, mais ne manquez pas de reconnaître que l'apprentissage fait partie de votre travail et n'allez pas dans l'état d'esprit que vous avez pour cacher votre ignorance à la maison ou ne pas savoir que tout est fatal à votre carrière. C'est à vous d'équilibrer le temps d'apprentissage et le temps de travail. Obtenez de grandes feuilles de papier et une boîte de crayons de couleur (ou MS Visio si vous préférez). Commencez à dessiner deux types de diagrammes:

  • Mind maps, pour illustrer votre compréhension des nouvelles technologies. Si vous ne savez pas ce que sont les cartes mentales, cliquez sur Wikipédia pour commencer.
  • Schémas architecturaux du système dont vous êtes responsable. Que vous utilisiez UML ou un autre format largement utilisé ou que vous en ayez vous-même conçu, c'est à vous de décider.

Answer 6

J'ai vu des cas comme le vôtre dans le passé aussi bien.Mais avec une lecture quotidienne et parctise dédiée, ils semblent faire aussi bien que tous les autres "jeunes et soi-disant bons programmeurs". Si j'étais à votre place, voici ce que je ferais:

• Décomposer les zones problématiques en plus petits morceaux.
• Recherche des livres/articles disponibles sur les sujets de la liste susmentionnée.
• Je vais coder les échantillons moi-même et expérimenter avec eux afin d'acquérir une meilleure compréhension.

Cela dit, ne vous inquiétez pas de ne pas avoir un esprit mathématique. Je suis un étudiant en mathématiques moi-même et honnêtement, il y a beaucoup d'occasions où je dois utiliser ces compétences. La plupart des applications d'entreprise n'exigent pas ce genre de compétences en mathématiques. De plus, les jours modernes sont si avancés et faciles à utiliser que vous n'auriez jamais à vous soucier d'écrire un algo de tri efficace ou quoi que ce soit de ce genre.

Essayez de lire autant que possible sur les modèles de conception. "Head first design patterns" est un excellent livre pour commencer mais les exemples de code sont en Java (ce qui ne devrait pas avoir d'importance). "UML Distilled" est un autre bon livre. Il y en a beaucoup d'autres disponibles, juste google :). Parcourez également votre système existant de manière approfondie.

le meilleur ..

Answer 7

Franchement, je sens que j'ai planté à la fin profonde et je me enfonce. Je ne suis pas sûr que ce soit parce que je manque l'arrière-plan éducatif pour comprendre ce genre de choses, si je suis tout simplement pas assez mathématiquement pour l'esprit informatique moderne (mes mathématiques n'a jamais été grand - mon approche de conception est souvent pour simplement déboguer jusqu'à ce que cela fonctionne, puis refactor jusqu'à ce qu'il semble soigné), ou si j'ai simplement été présenté avec trop de nature trop radical à la fois. Mais la seule façon de savoir ce que c'est est d'essayer et de l'apprendre.

Pour moi, c'est à cause de votre manque d'éducation. Les personnes qui apprennent elles-mêmes ou au travail n'ont souvent pas l'expérience nécessaire pour vraiment comprendre ce qui se cache derrière la scène d'un cadre. Certains concepts sont communs à tous les systèmes informatiques et nous les apprennent à l'école, donc nous pouvons comprendre comment ces concept fonctionne dans toutes les langues ... Vous semblez plus comme un programmeur pragmatique (et efficace?), Mais vous allez faire des erreurs est vous Je n'ai pas ce contexte général (mais vous devriez savoir que vous n'êtes pas seul dans ce cas ... particulièrement dev dev php je n'ai pas ce fond). Comment comprendre la relation de code avec DB, ORM comme Hibernate, si vous ne savez pas exactement ce qu'est une transaction (je suppose que vous savez comment l'utiliser ... (pragmatique je l'ai dit!) Mais vous ne prolly jamais entendu parler de concepts comme ACID: http://en.wikipedia.org/wiki/ACID, je suppose que vous ne savez pas beaucoup sur l'isolation des transactions).

Comment utiliser l'architecture soa avec webservices, rpc, rmi, CORBA ... efficacement et être en mesure d'avoir des données cohérentes dans votre base de données si vous ne connaissez pas certains concepts comme les 2 Phaze engagent http://en.wikipedia.org/wiki/Two-phase_commit_protocol

Comment écrire du bon code si vous ne connaissez pas beaucoup de modèles de design, de bonnes pratiques, et vous ne savez pas quand les utiliser?

On pourrait dire beaucoup de choses.

Le fait est que vous manquez une partie de la connaissance générale de l'informatique que tous les étudiants en génie ont (normalement?). Lorsque nous commençons à travailler après une école d'ingénieur, nous ne sommes pas experts en la matière, mais la seule différence avec vous est que nous savons qu'il existe un concept très important et quand il devrait être utilisé. Il nous suffit donc de lire à ce sujet et d'appliquer ce que nous apprenons du web ou de notre équipe (parce qu'à l'école, nous voyons à peine les bases, mais sur beaucoup de technologies). Je pense vraiment que rien n'est impossible pour vous, vous devriez juste beaucoup de choses sur les concepts généraux que vous ne connaissez pas et vous avez entendu beaucoup de choses. Sans cette connaissance, vous aurez simplement tendance à réinventer la roue et avec votre pragmatisme trouver des solutions alternatives qui fonctionnent mais qui sont juste un peu sales ... Par exemple, votre dev pourrait fonctionner mais quand vous introduisez une charge élevée sur votre système, vous pouvez avoir des problèmes de concurrence, des problèmes de performances. Ce manque de connaissances est pas une question quand you'r sur un contexte simple mais qui est vraiment nécessaire quand vous avez beaucoup de responsabilités sur un système complexe ...