Comment arrêter de perdre du temps à concevoir une architecture
J'ai récemment obtenu mon diplôme universitaire et commencé à travailler comme programmeur. Je ne trouve pas difficile de résoudre des problèmes "techniques" ou de déboguer avec des choses que je dirais avoir 1 solution.
Mais il semble y avoir une classe de problèmes qui ne pas ont une solution évidente - des choses comme l'architecture logicielle. Ces choses m'étouffent et me causent une grande détresse.
Je passe des heures et des heures à essayer de décider comment "architecturer" mes programmes et systèmes. Par exemple - est-ce que je divise cette logique en 1 ou 2 classes, comment puis-je nommer les classes, devrais-je les rendre privées ou publiques, etc. Je veux juste créer le programme - l'architecture soit maudite.
Comment accéder plus rapidement à la phase d'architecture et à la phase de codage et de débogage dont je profite?
Le parfait est l'ennemi du bien.
Cela dit, vous ne devez pas couper les coins ronds. La conception de logiciels aura un impact plus durable et vous fera économiser (ainsi qu'à vos pairs) des tonnes de temps et d'efforts à l'avenir. Il faudra plus de temps pour bien faire les choses. La plupart du temps consacré à la programmation n'est pas martelant sur un clavier, mais par un tableau blanc déterminant comment résoudre un problème.
Mais vous ne devez pas non plus vous soucier de la perfection. Si deux designs se battent vers une impasse, cela signifie qu'ils sont probablement à peu près la même bonté. Allez-y avec un. Ce n'est pas comme si vous ne pouviez pas changer les choses une fois que vous compreniez les défauts de cette conception.
(Et j'espère que cela vous aidera également une fois que vous découvrirez qu'il n'y a pas qu'une seule façon de déboguer/résoudre les problèmes techniques.)
Pour les programmes simples et petits (par exemple avec moins de dix mille lignes de code source), vous pouvez les architecturer lors de l'écriture du code. Si vous adoptez une approche développement itératif et incrémentiel, vous prendrez progressivement des décisions architecturales en cours de route: écrivez donc quelques-unes une douzaine de lignes de code (en ajoutant une seule micro fonctionnalité), améliorez-les jusqu'à ce qu'aucun avertissement ne revienne de votre compilateur, testez cela dans votre débogueur et recommencez.
puis-je diviser cette logique en 1 ou 2 classes, comment puis-je nommer les classes, devrais-je rendre cela privé ou public, etc. Ces types de questions prennent tellement de temps
Ils ne devraient pas. Et cela n'a pas beaucoup d'importance pour un programme petit (car les petits programmes simples sont plus faciles à améliorer, par exemple pour changer les noms, etc ...). Il vous suffit d'être cohérent et de prioriser la lisibilité de votre code source. Vous pouvez trouver de temps en temps le besoin de légèrement refactoriser quelques petites parties de votre programme (et c'est pas une grosse affaire).
Comparez cela à de nombreux projets logiciels libres (même les gros comme le noyau Linux). Les développeurs n'ont pas consacré beaucoup d'efforts à "l'architecture" au début. ML n'est presque jamais utilisé dans les logiciels libres . De plus, vous apprendrez pas mal en étudiant le code source de plusieurs projets de logiciels libres.
En tant que débutant, vous travaillerez soit sur un grand projet logiciel en équipe, où vous pourrez simplement faire confiance au développeur senior (qui prend les décisions architecturales), soit vous travaillerez seul sur de petits projets (généralement, moins de quelques dizaines de milliers lignes de code source). Dans ce dernier cas, vous prendrez des décisions architecturales incrémentielles, refactorisant votre application de temps en temps, après quoi la "conception architecturale" évoluera naturellement.
Comment accéder plus rapidement à la phase d'architecture et à la phase de codage et de débogage que j'apprécie?
Pour les petits projets logiciels, qui prennent moins d'un an de travail, très facilement: ne faites pas d'architecture. Passez peut-être une demi-heure de brainstorming sur l'ensemble conception. Commencez ensuite à écrire du code, avec une approche développement itératif et incrémentiel : écrivez quelques dizaines de lignes, compilez-le (avec tous les avertissements et les informations de débogage activés, par exemple g++ -Wall -Wextra -g avec GCC pour C++) jusqu'à ce que vous n'obteniez aucun avertissement (et passez-le dans un simple analyseur de code source statique, si vous en avez un, par exemple clang-analyzer ), testez ce code avec un débogueur , validez-le dans votre contrôle de version (par exemple git =), rincer et répéter. Cependant, assurez-vous d'éviter dette technique : lorsque quelque chose sent mauvais, travaillez (en refactorisant et en réimplémentant) pour l'améliorer.
D'autre part, dans un environnement d'équipe, le travail d'architecture implique la discussion initiale pour définir la responsabilité de chaque membre de l'équipe. Cette discussion est dirigée par le développeur principal (qui n'est pas un débutant). Lisez à propos de développement de logiciels agiles et Le Mythical Man-Month .
Je veux juste créer le programme, l'architecture doit être damée.
Excellente intuition (au moins pour les petits projets). Réfléchissez donc quelques instants à votre programme et commencez à le coder avec une approche développement itératif et incrémentiel : codez quelques dizaines de lignes et assurez-vous qu'elles fonctionnent bien, puis répétez. Avant cela, étudiez le code source (et observez l'architecture) de projets de logiciels libres similaires et plus généralement faites des travaux bibliographiques et des recherches.
Dans certains cas, pensez à une approche métaprogrammation : il y a des situations où vous voudriez générer un "fichier source" ( des exemples incluent l'utilisation de générateurs d'analyseurs comme bison , de générateurs de code de colle comme SWIG , Google protobuf , et parfois vous voudrez peut-être écrire un script simple -ou utiliser un préprocesseur générique comme GPP - pour émettre une partie de votre C++ ou Java = code pour éviter le codage répétitif).
PS. Je suis ingénieur de recherche, titulaire d'un doctorat en informatique et 40 ans d'expérience, et je n'ai jamais fait d '"architecture" comme le suggère votre question, tout en ayant travaillé avec succès sur plusieurs projets de taille moyenne, et quelques grands (le compilateur GCC lui-même ). Pour moi, "l'architecture" n'est que la phase de planification du travail des prochains jours ou semaines (et je le fais généralement en rêvant ou en dormant et certainement sans ordinateur, et généralement même sans crayon). Aussi, lors de l'écriture subventions de recherche , je suis en quelque sorte et de façon incomplète la conception d'une architecture.
NB: certains projets logiciels nécessitent beaucoup plus d'architecture que d'autres. Par exemple, si vous écrivez le système de contrôle d'un cœur artificiel ou d'un robot de neurochirurgie, vous ne travaillerez pas de la même manière que lors de l'écriture de l'application moyenne d'un téléphone mobile. Voir aussi la page de Norvig Apprenez-vous à programmer en dix ans .
Il y a trois devises que j'aime garder à l'esprit.
"Tout doit être aussi simple que possible, mais pas plus simple"
Pour prendre votre exemple de "une classe ou deux?", Je demanderais, "quelle est la solution la plus simple?"
"Pas de bugs évidents" contre "Evidemment pas de bugs"
Ce dernier est préférable!
Et c'est la raison pour laquelle cela doit être simple, c'est-à-dire pour que vous puissiez en raisonner. Une grande classe peut être (ou devenir) trop grande et trop compliquée pour raisonner, auquel cas vous la divisez en plusieurs classes plus petites, où vous pouvez dire "Chaque classe est petite et fait ce qu'elle dit qu'elle fera - et leurs interfaces sont simples, et ils se combinent de la bonne manière. "
- Le code devrait fonctionner en théorie (c'est-à-dire dans votre tête).
- Ensuite, si cela ne fonctionne pas dans la pratique, vous pouvez le déboguer jusqu'à ce que la pratique corresponde à la théorie.
Un novice ne se soucie pas parfois de l'étape 1, c'est-à-dire de l'exécuter dans votre tête (par exemple parce que c'est trop compliqué) - mais dans ce cas, il ne s'exécute que "par accident" plutôt que "en théorie", peut-être parce que vous n'avez pas " Je l'ai suffisamment testé pour trouver des bogues non évidents.
C'est ce qu'on appelle le "refactor".
En pratique, cela signifie:
- Commencez avec un [ny] système simple qui fonctionne
- Il est maintenant temps d'ajouter une nouvelle fonctionnalité
- Refonte du système existant afin que (c'est-à-dire jusqu'à ce que) la nouvelle fonctionnalité soit facile à ajouter
Ajouter la nouvelle fonctionnalité
... et répétez comme ci-dessus
Cela correspond à des devises comme YAGNI, c'est-à-dire ne pas refactoriser (vous soucier de l'architecture) avant de devoir ... mais créer la bonne architecture juste à temps, c'est-à-dire lorsque vous en avez besoin dans un but spécifique.
Ce que vous pouvez faire, c'est commencer avec le nombre minimal d'abstractions dont vous avez besoin. Par exemple, une classe Person dans un fichier. Maintenant que vous continuez à ajouter du code et des fonctionnalités, vous commencez à voir des choses qui doivent être déplacées vers une abstraction différente. Par exemple, le principe de responsabilité unique (S de SOLID) vous indique de ne pas avoir de méthodes liées à l'analyse d'adresses dans la classe Person. Vous savez donc maintenant que vous avez besoin d'une classe d'adresse.
Mais il est toujours bon de prendre le temps de réfléchir à ce à quoi ressemble le "nombre minimal d'abstractions" pour votre système. Commencez par une architecture suffisamment bonne et améliorez-la au fur et à mesure.
edit: la réponse @Basile donne un exemple sur la façon dont vous pouvez itérer et améliorer votre architecture minimale.
Le temps passé à penser à l'architecture d'un système n'est pas du temps perdu.
Je crois que votre question pourrait être reformulée comme "comment puis-je être plus efficace avec la prise de décisions architecturales?".
Ma réponse courte serait: vous devez découvrir les principes de base qui vous permettront de prendre des décisions de manière fiable et efficace, puis vous devez réellement sortir et façonner un logiciel réel. Ce sera un long voyage de recherche de connaissances, d'essais et d'erreurs et de développement personnel.
-
Et pour une réponse plus longue ...
Je dois d'abord clarifier les concepts: j'utilise Word architecture pour décrire la structure d'un système logiciel complexe lorsque je travaille avec des processus, des services, des API et des bases de données. J'utilise le mot design pour décrire la structure d'une seule pièce d'un système plus complexe, lorsque je travaille avec des classes, des fonctions et des bibliothèques. Ce sont mes définitions, certaines personnes ont des définitions différentes. Mais dans ce contexte, je pense que vous parlez de design.
Je pense qu'il y a 3 choses importantes à garder à l'esprit lors de l'examen de ce sujet:
l'architecture et le design existent sans qu'ils soient explicitement décrits via des diagrammes ou de la documentation, sans être entretenus par une équipe ou une personne (un architecte). Tout système a une architecture intrinsèque et une conception intrinsèque qui peuvent être décrites après coup.
le développement logiciel n'est pas de la programmation, c'est de la programmation dans le temps. Je fais cette distinction parce que je pense que c'est l'un des plus gros angles morts pour les gens qui viennent dans l'industrie (moi y compris, à un moment donné). Cela signifie que, par rapport aux projets universitaires ou aux projets personnels, travailler sur un système logiciel réel est exponentiellement plus complexe, car toute décision architecturale aura un impact important sur le développement du système, avec le temps. Vos décisions reviendront maintenant vous hanter, c'est garanti.
parce que l'architecture et le design existent de manière intrinsèque et parce que la base de code est une chose vivante qui évolue avec le temps, l'architecture et le design doivent également évoluer. Ils évolueront de manière contrôlée par le biais de décisions conscientes prises au moment du corect, ou ils évolueront de manière chaotique, entraînés par le codage. Ceci est crucial à comprendre, car cela signifie que l'approche traditionnelle de "l'architecte d'abord et d'écrire le code ensuite" est défectueuse. Bien sûr, lors du démarrage d'un projet à partir de zéro, certains travaux d'architecture et de conception doivent être effectués à l'avance. Mais à part cela, il y aura encore beaucoup de décisions architecturales et de conception à prendre lors du développement du système.
Pour distiller davantage ce qui précède, il est très important d'être conscient du fait que vous prendrez des décisions de conception tout en écrivant du code, consciemment ou non. Vous devez vous efforcer de prendre autant de décisions consciemment et de manière critique, car toute décision prise à la légère peut avoir un impact important sur les travaux futurs (cet impact se manifeste généralement dans la base de code qui devient très difficile à modifier pour corriger des bogues ou implémenter des fonctionnalités). Robert C. Martin l'illustre magnifiquement, avec des données, dans son livre "Clean Architecture" (que je recommande fortement d'ailleurs).
Alors, maintenant que nous savons pourquoi l'architecture et le design sont importants, quels sont les principes fondamentaux qui peuvent nous donner un cadre approprié pour une bonne prise de décision? J'ai eu cette question plus tôt dans ma carrière, j'avais l'impression qu'il y avait quelque chose manquant dans mon ensemble d'outils mais je ne savais pas quoi, je ne savais pas comment le décrire ou aller le chercher. Je vais partager certains de ces principes que j'ai découverts avec le temps et j'espère qu'ils vous faciliteront un peu la vie:
un ensemble de trucs de codage très simples mais puissants peut être récupéré en lisant le livre de Martin Fowler "Refactoring: Improving the Design of Existing Code". Il y en a trop pour les énumérer ici, mais ce sont des décisions de niveau de codage très bas que vous pouvez prendre pour améliorer considérablement votre structure de code et vous aider à prendre les décisions de conception. Le livre est également un bon argument pour intégrer les tests unitaires dans votre flux de travail personnel et comment écrire du code testable.
spécifiquement pour la POO, vous devriez regarder les principes SOLIDES . Ils sont un peu abstraits et difficiles à comprendre au début, mais très puissants. Je vous suggère de commencer par les 2 premiers pour obtenir le plus d'avantages rapidement:
Principe de responsabilité unique : une classe ne doit avoir qu'une seule responsabilité (c'est-à-dire que seules les modifications apportées à une partie de la spécification du logiciel doivent pouvoir affecter la spécification de la classe).
Principe ouvert/fermé : "les entités logicielles… devraient être ouvertes pour l'extension, mais fermées pour la modification."
- le concept de composition sur héritage
le principe selon lequel les classes devraient obtenir un comportement polymorphe et réutiliser le code par leur composition (en contenant des instances d'autres classes qui implémentent la fonctionnalité souhaitée) plutôt que l'héritage d'une base ou d'une classe parente.
- les concepts de couplage ("le degré d'interdépendance entre les modules logiciels") et cohésion ("le degré auquel les éléments à l'intérieur d'un module appartiennent ensemble.")
- le concept SEC (ne vous répétez pas)
- le concept de séparation commande/requête ("chaque méthode doit être soit une commande qui exécute une action, soit une requête qui renvoie des données à l'appelant, mais pas les deux")
- le concept de système avec état versus système sans état (ma règle de base est: éviter de gérer l'état; construire des systèmes sans état autant que possible).
Bien sûr, ce ne sont que des concepts, pas des règles. La première étape consiste à les comprendre et à en prendre conscience. Vient ensuite réellement leur utilisation dans la pratique et la construction d'une expérience sur le moment où vous devez les suivre et quand vous ne devriez pas. Et puis il y a un processus continu pour affiner votre compréhension de ces concepts, de leurs côtés négatifs et de leurs interactions complexes les uns avec les autres.
Je pense que le conseil le plus précieux que je puisse vous donner est: soyez patient avec vous-même. Vous venez de commencer sur une route longue mais satisfaisante. Continuez à pratiquer et à expérimenter, notez ce qui fonctionne et ce qui ne fonctionne pas et vous ne vous améliorerez qu'avec le temps.
La plupart de ce que vous décrivez n'est pas vraiment une architecture (importante) - une bonne dénomination et une bonne conception de classe devraient être une seconde nature pour vous. Cela s'améliorera simplement à mesure que vous coderez. Le plus utile pour de telles préoccupations est généralement la programmation en binôme - elle aide à clarifier ces problèmes et vous aide à apprendre comment le faire efficacement.
Là où l'architecture est nécessaire, c'est AVANT le projet:
Rassemblez les exigences exactes et les exigences non fonctionnelles (combien de demandes/seconde dois-je prendre en charge?). Toute erreur de correspondance dans cette phase entraînera un enfer de codage - l'intégration des idées manquées après coup est longue, ennuyeuse et parfois impossible. Je sais que ce n'est pas amusant comme codage, mais essayer d'obtenir le code pour faire quelque chose pour lequel il n'a pas été conçu est encore moins amusant.
Si approprié, définissez les contextes délimités de votre système et assurez-vous que votre vocabulaire est clair, par exemple si l'entreprise parle de "Frobbels", assurez-vous de nommer les classes/interfaces, etc. avec "*** Frobbels". Cela semble trivial, mais si vous parlez de workflows, alors que l'entreprise parle d'opérations, la traduction devient très ennuyeuse très rapidement.
Si vous travaillez avec plusieurs personnes/équipes, décrivez vos interfaces tôt et assurez-vous que toutes les hypothèses et les problèmes sont compris par tout le monde - si vous n'avez pas de contexte partagé, l'intégration sera "amusante". Par exemple. vous construisez un générateur d'images banane, mais votre développeur frontend a besoin d'un générateur d'images Apple. Ou vous créez quelque chose qui peut répondre à 100 requêtes/seconde, mais 10000 r/sec sont nécessaires.
Remarque: ceci est fortement influencé par mon travail sur une architecture de microservices. La façon dont les services sont construits en interne, PEUT également être architecturée - mais la plupart du temps, c'est beaucoup moins important que d'avoir une vue d'ensemble correcte.
Je ne vais pas vous lancer un tas de termes et d'abréviations (dont la plupart ne sont guère acceptés par la majorité des codeurs/ingénieurs logiciels). Tenez plutôt compte des éléments suivants:
Vous apprenez - vous ne perdez pas de temps, vous essayez différentes approches et apprenez ce qui fonctionne. Vous pouvez le faire sans beaucoup planifier à l'avance, en plongeant dans un problème avec la première solution qui vous vient à l'esprit et en le modifiant si ou quand cela ne fonctionne pas. Si cela fonctionne bien, tant mieux! Vous avez trouvé une solution simple à un problème. Les solutions simples sont très bien si elles fonctionnent bien, et parfois elles sont assez bonnes.
Tout est un compromis - vous pouvez concevoir le même système de différentes manières, en compromis le temps et l'espace, la complexité et la flexibilité, l'abstraction et la lisibilité, ou l'un des nombreux compromis possibles. Aucune solution n'est parfaite à tous points de vue et aucune règle n'est sans exception en génie logiciel. Celui qui vous dit le contraire est soit naïf, soit vend quelque chose.
En tant que diplômé récent, le codage et le débogage peuvent être très excitants, mais cela s'épuisera avec le temps, et les compétences que vous apprenez maintenant vous seront utiles quand cela se produira.
Je dirais que le logiciel de construction est plus un art/artisanat qu'une ingénierie. Le grand art ne concerne pas seulement le coup de pinceau individuel, mais plutôt les décisions de haut niveau et les compromis pris par l'artiste/artisan.
Je vais essayer de répondre à cette question du point de vue du développement web (c'est-à-dire: venant d'un domaine où les gens agonisent beaucoup sur l'architecture). Je commencerai par expliquer pourquoi les gens se soucient de l'architecture et je décrirai ensuite les moyens de dépasser la partie architecture plus rapidement.
L'architecture fait deux choses pour votre code:
- Cela facilite la compréhension de votre code pour vous et les autres.
- Il aide à structurer votre code d'une manière qui facilite son extension et son intégration.
Un style de code facilite la lecture d'une partie spécifique du code, en vous fournissant des conventions que vous pouvez reconnaître et utiliser pour le parcourir. De même, une bonne architecture vous aide à identifier où vous trouverez réellement le code qui gère une fonctionnalité spécifique. Par exemple, dans la plupart des projets Web, l'architecture est étroitement liée à la façon dont les dossiers et les fichiers sont triés. D'un autre côté, une bonne architecture devrait en fait vous aider à penser moins au code, car elle devrait déjà avoir un endroit intuitif où n'importe quel morceau de code appartient.
De plus, une bonne architecture fournit un raccourci pour éviter de nombreux pièges qui pourraient empêcher votre code d'être utilisé facilement. Encore une fois, si vous prenez une décision d'architecture, cela devrait mettre en place une convention qui vous aide à réfléchir moins sur la façon d'écrire du code.
Maintenant, la partie pour laquelle vous êtes réellement ici:
Que pouvez-vous faire plus rapidement dans la partie architecture:
- Ne fais pas ça
Comme de nombreuses réponses l'ont déjà souligné. Demandez-vous d'abord si vous avez réellement besoin d'une architecture. Si vous n'avez pas beaucoup de code (et vous pouvez être raisonnablement sûr que le projet ne se développera pas dans un avenir proche), vous pouvez simplement ignorer la partie architecture et bricoler quelque chose qui fonctionne simplement. TOUTEFOIS, si vous êtes au début de votre carrière, je profiterais de l'occasion pour pratiquer chaque fois que vous le pouvez. À un moment donné, vous ferez de plus gros projets, et à ce stade, il est probablement trop tard pour apprendre.
Avec cela à l'écart, que pouvez-vous faire pour rendre l'architecture moins douloureuse:
- Faites-le tôt
- Voler
- Apprenez/respectez-le
- N'en faites pas trop
Décider d'une architecture devrait être une partie précoce du processus de planification. Dès que vous avez une idée du type d'application/programme/site Web que vous allez créer, vous devez réfléchir au type d'architecture qui prendrait en charge cela.
À ce stade, il est temps de voler sans vergogne. Il existe de nombreuses publications sur la façon de configurer correctement une architecture de programme, et une quantité incroyable de cas d'utilisation est couverte par ces prototypes d'architecture existants. Vous devriez apprendre un aperçu approximatif du type d'architectures existantes, même si vous ne savez pas comment les implémenter.
Si vous avez opté pour une sorte d'architecture, respectez-la. Pour l'essentiel, la décision d'architecture doit être intuitive et ne prendre que quelques secondes après la configuration initiale. Une grande partie de cela se résume à l'expérience.
Enfin, ne réfléchissez pas trop. Vous donnez l'exemple de savoir si quelque chose doit être public ou privé, et la vérité est que cela n'a probablement pas d'importance si vous rendez tout public. Oui, vous ne devriez pas le faire de cette façon, et pour beaucoup de ces petites erreurs s'accumuleront après un certain temps, mais à la fin de la journée, cela ne tuera probablement pas votre projet non plus. Créez avant tout un logiciel fonctionnel!
(PS: cette dernière phrase n'est pas une excuse pour être paresseux. Donner la priorité aux logiciels de travail ne signifie pas que vous n'aurez pas à apprendre un bon codage un jour.)
La réponse est très simple,
- Créer un prototype (Time boxed)
- Refactoriser (passer autant de temps que vous le souhaitez ou en fonction d'un large éventail de facteurs)
Lorsque vous créez un prototype, l'accent doit être mis sur le produit viable minimal et lorsque vous effectuez une refactorisation, l'accent doit être mis sur la mise à l'échelle de votre projet ou de votre solution.
Comment accéder plus rapidement à la phase d'architecture et à la phase de codage et de débogage que j'apprécie?
En reléguant cette tâche à (ou en demandant de l'aide à) vos collègues plus expérimentés.
Vous n'avez tout simplement pas l'expérience nécessaire pour prendre rapidement de telles décisions. Uni vous a donné une bonne formation théorique, mais cela ne vous amène qu'à une ligne de départ. Il n'y a pas d'autre moyen de juger une architecture donnée dans une situation donnée que de savoir comment des architectures similaires se sont comportées dans des situations similaires dans le passé.
Travailler avec des gens qui sont meilleurs au travail que vous est le moyen le plus rapide d'apprendre des choses. Si vous n'avez personne à qui vous adresser, vous avez besoin d'un meilleur emploi. "Mieux" que dans "mieux répondre à vos besoins". Le besoin de connaissances et d'expérience est votre besoin le plus urgent en ce moment, comme le prouve votre dilemme. Vous aimez la phase de codage et de débogage? Cela ressemble à un parfait junior. Mais un junior a besoin des conseils d'un senior. C'est le point de ces descriptions de travail. Les étrangers sur Internet ne peuvent vous aider que jusqu'à présent, vous avez besoin d'un mentor.
Je vois de sérieux problèmes avec cette question. Commençons.
Comment arrêter de perdre du temps à concevoir des architectures
Cette question est plutôt chargée. De plus, vous n'avez pas design architecture. Vous architecte. L'architecture et le design sont des activités complémentaires et connexes, mais ne sont pas identiques, même si elles peuvent se chevaucher.
De même, de la même manière, il est possible de perdre du temps à faire de l'architecture (en sur-architecturant), vous pouvez également perdre du temps en concevant et en sur-codant (en codant des choses d'une manière beaucoup plus complexe que nécessaire, ou en omettant de code pour les éléments requis.)
Une architecture appropriée vise à éviter ce gaspillage dans le codage. Il le fait en limitant, en restreignant et en documentant les façons possibles de concevoir un système complexe 1) 2) codé et testé, 3) livré, 4) entretenu, 5) récupéré d'une panne et 6) finalement mis hors service.
Mon expérience a été que les gens qui aiment simplement coder, ils ont juste code sans penser au fonctionnement et à la maintenance d'un système à long terme, passant à la suivante hot potato laissant une pauvre âme pour maintenir un golem laid.
Mais je m'égare ...
C'est la chose: Pour les systèmes assez simples, l'architecture est évidente et émane de bonnes pratiques de conception et de mise en œuvre.
Ce n'est que pour les grands systèmes qui impliquent un assez grand nombre de personnes ou des logiciels de niveau système qui font des choses très complexes qui nécessitent une architecture explicite.
J'ai récemment obtenu mon diplôme de l'université et commencé à travailler en tant que programmeur. Je ne trouve pas cela difficile de résoudre des problèmes "techniques" ou de faire du débogage, des choses que je dirais avoir 1 solution.
C'est le minimum requis pour cette profession, et je suis heureux que vous n'ayez aucun problème à les faire (je serais inquiet si vous le faisiez.)
Mais il semble y avoir une classe de problèmes qui n'ont pas de solution unique
Ce sont le pain et le beurre de notre profession, le type de problèmes pour lesquels les employeurs sont prêts à payer nos salaires (généralement) bien supérieurs à la moyenne.
En fait, les problèmes qui méritent d'être résolus sont ceux qui peuvent avoir plus d'une solution. Les problèmes du monde réel, ils sont comme ça. Et le monde a besoin de notre expertise, en tant que développeurs de logiciels, pour trouver des compromis acceptables.
- des choses comme l'architecture logicielle.
L'architecture des choses est une caractéristique inévitable des systèmes complexes, qu'ils soient virtuels/logiciels ou dans le monde concret. Chaque système qui fonctionne, qui prend des entrées et produit des sorties, sera complexe et aura une architecture.
Lorsque nous développons des logiciels pour de tels systèmes (un système bancaire, un système de surveillance de l'alimentation, un système de vente de billets, etc.), nous visons à produire un logiciel qui imite les fonctions et les exigences de tels un système.
Nous ne pouvons tout simplement pas simplement le faire voler et coder le style cowboy. Nous avons besoin d'une sorte d'architecture. Cela est particulièrement vrai si le projet nécessite des dizaines d'ingénieurs, sinon plus.
Ces choses m'étouffent et me causent une grande détresse.
Ça va. Ce n'est pas un sujet facile à apprendre ou à enseigner, non sans beaucoup de pratique.
Je passe des heures et des heures à essayer de décider comment "architecturer" mes programmes et systèmes. Par exemple, est-ce que je divise cette logique en 1 ou 2 classes, comment puis-je nommer les classes, devrais-je rendre cela privé ou public, etc. Ces types de questions prennent tellement de temps et cela me frustre énormément. Je veux juste créer le programme, l'architecture soit maudite.
Malheureusement, ce n'est pas une architecture logicielle.
Ce n'est même pas du design, mais juste du codage. Je fournirai quelques suggestions au bas de cet article.
Comment accéder plus rapidement à la phase d'architecture et à la phase de codage et de débogage, ce que j'aime?
J'ai du mal à trouver un moyen d'y répondre, car c'est plutôt émouvant.
Essayons-nous de faire un travail, ou essayons-nous simplement de profiter de la pratique? C'est génial quand les deux sont une seule et même chose, mais dans la vraie vie, souvent ils ne le sont pas.
C'est formidable de faire des choses qui nous plaisent, mais dans une profession aussi complexe que la nôtre, se concentrer uniquement sur ce que nous aimons, ce n'est pas propice à une carrière fructueuse.
Vous ne progresserez pas, vous ne mûrirez pas ou n'acquerrez pas de nouvelles connaissances.
Il y a ce dicton dans l'armée, "embrasser le sucer."
D'autres phrases ont des conseils similaires. "Si ça ne suce pas, ça n'en vaut pas la peine" et mon préféré, "Si ça craint (et c'est important), fais-le jusqu'à ce qu'il cesse de sucer."
Mes recommandations:
Il me semble que vous avez encore du mal à comprendre les différences entre
codage (comment coder vos classes, modules ou non, conventions de nommage, visibilité d'accès, portée, etc.),
la conception (combien de niveaux, front-end/back-end/db, comment chacun communique, ce qui va où) et les décisions d'architecture implicites qui découlent de la conception de systèmes simples,
architecture (comme dans les systèmes complexes nécessitant des milliers, voire des centaines de milliers d'heures de travail.)
Je vous suggère donc de vous plonger profondément dans le premier sujet (codage) pour le porter au niveau suivant.
Code propre
Robert "Uncle Bob" Martin's "Clean Code" est un bon point de départ.
Cohésion logicielle
De plus, je vous suggère de vous familiariser avec une métrique logicielle orientée objet spécifique appelée LCOM ou plutôt LCOM4.
Cela peut devenir plutôt mathématique et ce n'est pas à l'épreuve des balles, mais votre objectif devrait être de comprendre et de détecter empiriquement (ou le globe oculaire si vous le souhaitez) si une classe est cohésive ou si elle manque de cohésion.
http://www.aivosto.com/project/help/pm-oo-cohesion.html#LCOM4https://www.computing.dcu.ie/~renaat/ca421 /LCOM.html
Principes du logiciel
Cela est étroitement lié au "principe de responsabilité unique" ou SRY que nous devrions tous connaître. SRY est l'un des 5 "SOLID" que nous devons tous connaître si nous voulons devenir compétents en codage.
Au fur et à mesure que nous parcourons les principes SOLID, nous devons également nous familiariser avec les principes "GRASP" , qui régissent ou plutôt guident la façon dont nous codons les classes.
Livres supplémentaires
Enfin, je suggère également ce qui suit:
"Refactoring" par Martin Fowler et Ken Beck serait le prochain livre que j'ai lu dans cette liste.
"Design by Contract, by Example" par Richard Mitchell, Jim McKim et Bertrand Meyer (le dernier de la renommée d'Eiffel.) Ce livre est épuisé, mais vous pouvez trouver des copies d'occasion bon marché en Amazonie.
Avec cela, vous devriez avoir une bonne compréhension de la façon de commencer le codage et la conception, et avec la pratique, pour déplacer et maîtriser (ou du moins saisir) l'architecture logicielle.
Je suis sûr qu'il y aura d'autres professionnels qui ajouteront, soustraireont ou s'opposeront à ces suggestions. Ils proposeront d'autres suggestions, probablement validées par leur propre expérience.
Tout ce que je peux dire, c'est ceci - il n'y a pas de raccourcis.
Bonne chance.
Il y a beaucoup d'informations ici et franchement TL; DR. Il y a une chose principale à laquelle je pense que les gens se trompent lorsqu'ils essaient d'apprendre à concevoir un système: ils essaient d'y penser dans l'ordre où le travail sera fait. Au lieu de cela, vous devez travailler en arrière. Autrement dit, l'objectif principal de la conception/architecture est de déterminer quel devrait être le résultat final.
À titre d'analogie, considérons l'architecture d'une maison. Un architecte ne commence pas par se poser des questions comme: "combien de fenêtres cette maison devrait-elle avoir?", "Où placer la première brique?". Ces détails d'implémentation ne sont pas la conception, ils sont dérivés de la conception. L'architure commence par une vision, peut-être un croquis de ce à quoi pourrait ressembler la maison finie. Est-ce une maison unifamiliale, un duplex? Est-ce une maison de luxe ou facilement abordable? De même, si les variables sont privées et si vous divisez une classe, cela n'a pas grand-chose à voir avec l'architecture.
Commencez par déterminer quels sont les objectifs de votre conception. Par exemple, s'agit-il d'une solution unique? Va-t-il être étendu, révisé et maintenu pendant des décennies? La réponse à cela indiquera des conceptions très différentes et c'est le point de l'architecture. Une fois que vous avez compris ce que vous devez faire, les détails de la conception suivent naturellement. Non pas que ces détails soient évidents ou faciles, mais c'est le plan de haut niveau sur lequel ces choix sont basés.
Comment juger du temps que vous devez consacrer à l'architecture d'un logiciel avant d'obtenir une boucle de test d'écriture-compilation d'une sorte est assez simple: suffisamment d'informations pour tenir dans votre tête, et pas plus que cela. À moins que le projet sur lequel vous travaillez n'impose une méthodologie plus stricte. Dans ce cas, en tant que débutant, vous devriez probablement lire un document d'architecture et non l'écrire.
Quant à nommer les choses, pour moi cela fait partie de "l'écriture" mais c'est sans aucun doute une partie très importante de la programmation: n'hésitez pas à réfléchir sérieusement à la façon dont vous nommez les choses, et à réfléchir plus fort à mesure que le nom est plus large.
Trouver les bons noms, la bonne architecture, la bonne modularité et les bonnes abstractions fait partie de l'expérience que vous gagnerez en faisant des erreurs. Au fil des ans, j'ai écrit un programme faisant la même chose environ cinq fois et le code était très différent à chaque fois parce que chaque itération passée m'a donné des indices sur une meilleure conception.