Je suis récemment diplômé de l'université et a commencé à travailler en tant que programmeur. Je ne trouve pas difficile de résoudre des problèmes «techniques» ou de procéder à un débogage avec des solutions pour lesquelles je dirais avoir une solution.

Mais il semble y avoir une classe de problèmes qui n’ont pas de solution évidente - des choses comme l’architecture logicielle. Ces choses me troublent et me causent une grande détresse.

Je passe des heures et des heures à essayer de décider comment "architecter" 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? Je veux juste créer le programme - l'architecture soit maudite.

Comment passer plus rapidement de la phase d’architecture à la phase de codage et de débogage que j’apprécie?

Parfait est l'ennemi du bien.

Cela dit, vous ne devriez pas couper les coins ronds. La conception de logiciels aura un impact plus durable et vous fera économiser beaucoup de temps et d’efforts dans le futur. Il faudra plus de temps pour bien faire les choses. La plupart du temps passé à programmer ne consiste pas à marteler un clavier, mais à un tableau blanc pour savoir comment résoudre un problème.

Mais vous ne devriez pas non plus vous soucier de la perfection. Si deux modèles se trouvent dans une impasse, cela signifie qu'ils auront probablement le même bien. Il suffit d'y aller avec un. Ce n'est pas comme si vous ne pouviez pas changer les choses une fois que vous avez découvert les défauts de cette conception.

(Et j'espère que cela vous aidera aussi une fois que vous découvrirez qu'il n'y a pas qu'un seul moyen 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 pendant l'écriture du code. Si vous adoptez une approche de développement itérative et incrémentale , vous prendrez progressivement des décisions architecturales: écrivez quelques dizaines de lignes de code (en ajoutant une simple fonctionnalité micro), améliorez-les jusqu'à ce que votre compilateur ne renvoie plus d'avertissements, testez-le. votre débogueur, et répétez.

est-ce que je divise cette logique en 1 ou 2 classes, comment puis-je nommer les classes, dois-je rendre cela privé ou public, etc. Ce genre de question occupe tellement de mon temps

Ils ne devraient pas. Et ils ne comptent pas beaucoup pour un petit programme (parce que les petits programmes simples sont plus faciles à améliorer, par exemple pour changer de nom, etc.). Vous devez juste être cohérent et donner la priorité à la lisibilité de votre code source. Vous constaterez peut-être qu'il est parfois nécessaire de modifier légèrement certaines petites parties de votre programme (et ce n'est pas grave).

Comparez cela à de nombreux projets de logiciels libres (même les plus gros comme le noyau Linux). Les développeurs n’ont pas déployé d’efforts significatifs en matière d’architecture à ses débuts. UML n'est presque jamais utilisé dans les logiciels libres . De plus, vous en apprendrez beaucoup en étudiant le code source de plusieurs projets de logiciels libres.

En tant que novice, vous travaillerez en équipe sur un projet logiciel volumineux où vous pourrez simplement faire confiance au développeur senior (qui prend les décisions architecturales), ou 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, refacturant votre application de temps en temps, après quoi la "conception architecturale" évoluera naturellement.

Comment puis-je passer plus rapidement de la phase d'architecture et de la phase de codage et de débogage que j'apprécie?

Pour les petits projets logiciels, qui prennent moins d’une année de travail, très facilement: ne faites pas d’architecture. Passez peut-être une demi-heure à réfléchir à la conception globale. Commencez ensuite à écrire du code, avec une approche de développement itérative et incrémentale : écrivez quelques dizaines de lignes, compilez-le (avec tous les avertissements et informations de débogage activés, par exemple g++ -Wall -Wextra -gavec GCC pour C ++) jusqu'à ce que vous n'ayez plus d'avertissements (et transmettez-le dans une source statique simple). analyseur de code, si vous en avez un, par exemple analyseur-clang ), testez ce code avec un débogueur , validez-le dans votre contrôle de version (par exemple git), rincez et répétez. Veillez toutefois à éviter les dettes techniques: quand quelque chose sent mauvais, faites-le pour l'améliorer (en le refacturant et en le réimplémentant).

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 menée par le développeur principal (qui n'est pas un débutant). Lisez à propos du développement logiciel agile et du mois mythique .

Je veux juste créer le programme, l'architecture doit être barrée.

Excellente intuition (au moins pour les petits projets). Réfléchissez donc quelques minutes à votre programme et commencez à le coder selon une approche de développement itérative et incrémentale : codez quelques dizaines de lignes et assurez-vous qu'elles fonctionnent bien, puis répétez l'opération. Avant cela, étudiez le code source (et observez l’architecture) de projets logiciels libres similaires et effectuez plus généralement des travaux bibliographiques et de recherche.

Dans certains cas, pensez à une approche de métaprogrammation : il existe des situations dans lesquelles vous souhaitez générer un "fichier source" (par exemple, utilisez des générateurs d’analyseur tels que Bison , des générateurs de code collé tels que SWIG , Google protobuf , et parfois, vous souhaiterez peut-être écrire un fichier. un script simple - ou utilisez un préprocesseur générique tel que GPP - pour émettre une partie de votre code C ++ ou Java afin d'éviter un codage répétitif).

PS Je suis ingénieur de recherche, titulaire d’un doctorat en informatique et de 40 années d’expérience. Je n’ai jamais fait d’architecture, comme le suggère votre question, alors que j’avais travaillé avec succès sur plusieurs projets de taille moyenne et quelques grands projets (le compilateur GCC lui-même) ) Pour moi, "architecture" n’est que la phase de planification du travail des prochains jours ou semaines (et c’est ce que je fais habituellement en rêvant ou en dormant et certainement sans ordinateur, et même sans crayon). De plus, lors de la rédaction de subventions de recherche , je suis en train de concevoir une architecture incomplète.

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 d'une application de téléphone portable moyenne. Voir aussi la page de Norvig Apprends-toi à programmer dans dix ans .

Je tiens à garder à l’esprit trois devises.

• "Tout doit être rendu 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 il faut que ce soit simple, c’est-à-dire que vous puissiez raisonner à ce sujet. Une grande classe peut être (ou devenir) trop grande et trop compliquée pour être raisonnée, 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 combinent de la bonne façon ".

  1. Le code devrait fonctionner en théorie (c'est-à-dire dans votre tête).
  2. 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 parfois pas de l’étape 1, c’est-à-dire que vous devez l’avoir dans la tête (par exemple parce que c’est trop compliqué). t assez testé pour trouver des bugs non évidents.

• Loi de Gall

  C'est aka "refactor".

  En pratique, cela signifie:

  1. Commencez avec un système [ny] simple qui fonctionne
  2. Il est maintenant temps d'ajouter une nouvelle fonctionnalité
  3. Refactoriser le système existant afin que (c.-à-d. Jusqu'à ce que la nouvelle fonctionnalité soit facile à ajouter)

  4. Ajouter la nouvelle fonctionnalité

  5. ... et répéter comme ci-dessus

  Cela correspond à des devises telles que YAGNI, c.-à-d. Ne refactorez pas (inquiétez-vous au sujet de l'architecture) avant d'avoir besoin de… mais créez la bonne architecture juste à temps, c.-à-d. Lorsque vous en avez besoin pour un objectif 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 autre abstraction. Par exemple, le principe de responsabilité unique (S de SOLID) vous indique que les méthodes d'analyse des adresses ne sont pas associées à la classe Person. Donc, vous savez maintenant que vous avez besoin d'une classe d'adresse.

Mais il est toujours bon de prendre le temps de réfléchir au "nombre minimal d’abstractions" pour votre système. Commencez par une architecture assez bonne et améliorez-la au fur et à mesure.

edit: @Basile answer 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 pense que votre question pourrait être reformulée comme suit: "Comment puis-je être plus efficace dans la prise de décision architecturale?".

Ma réponse brève à cette question serait la suivante: vous devez découvrir les principes fondamentaux qui vous permettront de prendre des décisions de manière fiable et efficace, puis vous devez réellement créer un logiciel réel. Ce sera un long chemin de recherche de connaissances, d'essais et d'erreurs et de développement personnel.

-

Et pour une réponse plus longue ...

Je devrais d’abord clarifier les concepts: j’utilise le mot architecture pour décrire la structure d’un 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'un seul élément 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 lorsque vous discutez de ce sujet:

• L’architecture et le design existent sans qu’ils soient explicitement décrits via des schémas ou de la documentation, pas plus qu’ils soient gérés par une équipe ou une personne (un architecte ). Tout système a une architecture intrinsèque et une conception intrinsèque qui peut être décrite après coup.

• le développement logiciel n'est pas une programmation, c'est une programmation dans le temps. Je fais cette distinction parce que je pense que c'est l'un des plus grands angles morts pour les personnes qui viennent dans l'industrie (moi-même, à un moment donné). Cela signifie que, par rapport aux projets universitaires ou personnels, le travail 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 maintenant vont revenir vous hanter, c'est garanti.

• parce que l'architecture et le design existent intrinsèquement et que la base de code est une chose vivante qui évolue avec le temps, l'architecture et le design doivent également évoluer. Ils évolueront soit de manière contrôlée à travers des décisions conscientes prises au moment opportun, soit de manière chaotique, en fonction du codage. Cela est crucial pour comprendre, car cela signifie que l'approche traditionnelle consistant à "architecte d'abord et écrire le code ensuite" est imparfaite. Bien entendu, lorsque vous démarrez un projet à partir de zéro, certains travaux d'architecture et de conception doivent être effectués dès le départ. Mais à part cela, de nombreuses décisions d’architecture et de conception resteront à prendre lors du développement du système.

Pour approfondir ce qui précède, il est très important de savoir que vous prendrez des décisions de conception tout en écrivant du code, que ce soit consciemment ou non. Vous devez vous efforcer de prendre autant de décisions de manière consciente et 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 par le fait qu'il devient très difficile de modifier la base de code pour corriger des bogues ou implémenter des fonctionnalités). Robert C. Martin illustre cela à merveille, avec des données, dans son livre "Clean Architecture" (que je recommande vivement en passant).

Alors, maintenant que nous savons pourquoi l'architecture et le design sont importants, quels sont les principes fondamentaux qui peuvent nous fournir un cadre approprié pour une bonne prise de décision? J'avais cette question plus tôt dans ma carrière, j'avais l'impression qu'il manquait quelque chose dans mes outils mais je ne savais pas quoi, je ne savais pas comment la décrire ni aller la chercher. Je partagerai certains de ces principes que j'ai découverts avec le temps et j'espère qu'ils vous faciliteront un peu la vie:

• Vous pouvez découvrir un ensemble d’astuces de codage très simples mais puissantes en lisant le livre de Martin Fowler "Refactoring: Améliorer la conception du code existant". Il y en a trop à énumérer ici, mais vous pouvez prendre des décisions de niveau de codage très simples pour améliorer considérablement la structure de votre code et vous aider à prendre les décisions de conception. Le livre plaide également en faveur de l'intégration du test unitaire dans votre flux de travail personnel et de la rédaction de code testable.

• spécifiquement pour la POO, vous devriez regarder les principes SOLID . Ils sont un peu abstraits et difficiles à comprendre, mais ils sont 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 devrait avoir qu'une seule responsabilité (autrement dit, seuls les changements apportés à une partie de la spécification du logiciel devraient avoir une incidence sur la spécification de la classe).

Principe d'ouverture / fermeture : "les entités logicielles… devraient être ouvertes à l'extension, mais fermées à la modification".

• le concept de composition sur héritage

  le principe selon lequel les classes doivent obtenir un comportement polymorphe et une réutilisation du code en raison de leur composition (en contenant des instances d'autres classes qui implémentent la fonctionnalité souhaitée) plutôt qu'en héritage d'une classe de base ou d'une classe mère.

• les concepts de couplage ("le degré d'interdépendance entre les modules de logiciel") et de cohésion ("le degré de corrélation entre les éléments d'un module".)
• le concept DRY (Don't Repeat Yourself)
• le concept de séparation commande / requête ("chaque méthode doit être soit une commande qui effectue une action, soit une requête qui renvoie des données à l'appelant, mais pas les deux")
• le concept de système avec état contre état sans état (ma règle empirique est la suivante: évitez de manipuler l’état; construisez autant que possible des systèmes sans état).

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 l’utilisation concrète de ces outils et la création d’expérience pour savoir quand il faut les suivre et quand il ne faut 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: ayez de la patience avec vous-même. Vous venez de commencer une route longue mais enrichissante. Continuez à pratiquer et à expérimenter, notez ce qui fonctionne et ce qui ne fonctionne pas et vous ne pourrez que vous améliorer 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 sont des choses qui devraient être une seconde nature pour vous. Cela va simplement s'améliorer plus vous codez. La programmation en binôme est généralement la solution la plus utile. Elle vous aide à clarifier ces problèmes et vous aide à apprendre à le faire efficacement.

AVANT le projet où l'architecture est nécessaire:

1. Rassemblez les exigences exactes et les exigences non fonctionnelles (combien de demandes / seconde dois-je prendre en charge?). Toute confusion dans cette phase conduira à un codage infernal - intégrer les idées manquées après le fait prend beaucoup de temps, est agaçant et parfois impossible. Je sais que ce n'est pas amusant en tant que codage, mais essayer d'obtenir le code pour faire quelque chose pour lequel il n'a pas été conçu est encore moins amusant.

2. Si approprié, définissez les contextes délimités de votre système et assurez-vous de bien maîtriser votre vocabulaire. Par exemple, si le professionnel parle de "Frobbels", assurez-vous de nommer les classes / interfaces, etc., avec "*** Frobbels". Cela semble banal, mais si vous parlez de workflows, alors que votre entreprise parle d’opérations, la traduction devient très pénible.

3. Si vous travaillez avec plusieurs personnes / équipes, décrivez vos interfaces à un stade précoce et assurez-vous que toutes les hypothèses et tous les problèmes sont compris de tous. Si vous n'avez pas de contexte partagé, l'intégration sera "amusante". Par exemple, vous construisez un générateur d'image de banane, mais votre développeur frontend a besoin d'un générateur d'image de pomme. Ou vous construisez quelque chose qui peut répondre à 100 demandes / seconde, mais 10000 tr / s sont nécessaires.

Remarque: ceci est fortement influencé par mes travaux sur une architecture de microservice. La façon dont les services sont construits à l’intérieur du système, peut être conçue aussi, mais la plupart du temps, c’est beaucoup moins important que d’avoir une vision globale.

Je ne vais pas vous lancer une série de termes et d'abréviations (dont la plupart ne sont guère acceptés par la majorité des codeurs / ingénieurs en logiciel). Au lieu de cela, considérez ce qui suit:

1. Vous apprenez - vous ne perdez pas de temps, vous essayez différentes approches et découvrez ce qui fonctionne. Vous pouvez le faire sans planifier beaucoup à l'avance, en vous plongeant dans un problème avec la première solution qui vous vient à l'esprit et en le modifiant si ou quand cela ne fonctionnerait pas. Si cela fonctionne bien, c'est parfait! Vous avez trouvé une solution simple à un problème. Des solutions simples sont acceptables si elles fonctionnent bien, et parfois elles sont assez bonnes .

2. Tout est un compromis - vous pouvez concevoir le même système de différentes manières: réduction du temps et de l’espace, complexité et flexibilité, abstraction et 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. Quiconque vous dit le contraire est naïf ou vend quelque chose.

3. En tant que diplômé récent, coder et déboguer peut être très excitant, mais cela s’efface avec le temps et les compétences que vous apprenez maintenant vous seront très utiles.

4. Je dirais que le logiciel de construction est plus un art / métier que l’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 / l'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 souffrent beaucoup de l’architecture). Je vais commencer par expliquer pourquoi les gens s’intéressent à l’architecture, puis je décrirai les moyens de surmonter plus rapidement la partie architecture.

L'architecture fait deux choses pour votre code:

1. Cela facilite la compréhension de votre code pour vous et les autres.
2. Cela aide à structurer votre code de manière à faciliter 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 allez réellement trouver le code qui gère une fonctionnalité spécifique. Par exemple, dans la plupart des projets Web, l’architecture est étroitement liée à la manière dont les dossiers et les fichiers sont triés. D'un autre côté, une bonne architecture devrait en réalité vous aider à penser moins au code, car elle devrait déjà avoir un emplacement intuitif où tout élément de code appartient.

De plus, une bonne architecture fournit un raccourci pour éviter bon nombre des pièges qui pourraient empêcher votre code d’être utilisé facilement. Encore une fois, si vous prenez une décision d'architecture, il convient de définir une convention qui vous aide à penser moins à la manière d'écrire du code.

Maintenant, la partie pour laquelle vous êtes réellement ici:

Que pouvez-vous faire à travers la partie architecture plus rapidement:

1. Ne le fais pas

Comme beaucoup de réponses l’ont déjà fait remarquer. Tout d'abord, demandez-vous si vous avez réellement besoin d'une architecture. Si vous ne disposez pas de beaucoup de code (et que vous pouvez être raisonnablement certain 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. CEPENDANT, si vous êtes au début de votre carrière, je profiterai de l'occasion pour pratiquer chaque fois que vous le pourrez. À un moment donné, vous ferez de plus gros projets et à ce moment-là, il est probablement trop tard pour apprendre.

En dehors de cela, que pouvez-vous faire pour que l'architecture soit moins pénible:

1. Fais-le tôt
2. Voler
3. Apprendre / S'y tenir
4. N'en faites pas trop

Le choix d’une architecture devrait faire partie des premières étapes du processus de planification. Dès que vous avez une idée du type d'application, de programme ou de site Web que vous allez créer, réfléchissez au type d'architecture qui prendrait en charge cette fonctionnalité.

À ce stade, il est temps de voler sans vergogne. Il existe de nombreux ouvrages sur la manière de configurer correctement une architecture de programme, et une quantité étonnante de cas d'utilisation est couverte par ces prototypes d'architecture existants. Vous devriez apprendre un aperçu général du type d'architectures existantes, même si vous ne savez pas comment les mettre en œuvre.

Si vous avez opté pour une sorte d'architecture, alors respectez-la. Dans la plupart des cas, la décision d'architecture doit être intuitive et ne prendre que quelques secondes après la configuration initiale. Beaucoup de cela revient à l'expérience.

Enfin, ne réfléchissez pas trop. Vous donnez l'exemple de la question de savoir si quelque chose devrait être public ou privé, et la vérité est que cela n'a pas d'importance si vous rendez tout public. Oui, vous ne devriez pas le faire de cette façon, et bon nombre de ces petites erreurs vont s'accumuler après un certain temps, mais au final, cela ne tuera probablement pas votre projet non plus. D'abord et avant tout, créer un logiciel fonctionnel!

(PS: Cette dernière phrase n’est pas une excuse pour être paresseuse. Donner la priorité à un logiciel qui fonctionne ne signifie pas que vous n’aurez pas à apprendre un bon code un jour.)

La réponse est très simple,

• Créer un prototype (Time boxed)
• Refactor (passez autant de temps que vous le souhaitez ou en fonction d'un large éventail de facteurs)

Lors de la création d'un prototype, l'accent doit être mis sur le produit minimal viable, et lors de la refactorisation, l'accent doit être mis sur la possibilité de rendre votre projet ou votre solution évolutif.

Comment puis-je passer plus rapidement de la phase d'architecture et de 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 les plus expérimentés.

Il vous manque simplement l'expérience nécessaire pour prendre rapidement de telles décisions. Uni vous a donné un bon bagage théorique, mais cela ne vous conduit 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 personnes plus compétentes que vous constitue le moyen le plus rapide d'apprendre des choses. Si vous n'avez personne à qui vous adresser, vous avez besoin d'un meilleur travail. "Mieux" comme dans "mieux répondre à vos besoins". Le besoin de connaissances et d'expérience est votre besoin le plus criant en ce moment, comme le prouve votre dilemme. Vous appréciez la phase de codage et de débogage? Cela ressemble à un junior parfait. Mais un junior a besoin des conseils d'un senior. C'est le but de ces descriptions de travail. Les étrangers sur Internet ne peuvent que vous aider jusqu'à présent, vous avez besoin d'un mentor.

Je vois quelques problèmes sérieux avec cette question. Commençons.

Comment arrêter de perdre du temps à concevoir architechture

Cette question est plutôt chargée. En outre, vous ne concevez pas d' architecture. Vous architecte . L'architecture et la conception 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 en architecture (en sur-architecture), mais aussi en sur-conception et en sur-codage (en codant des éléments de manière beaucoup plus complexe que nécessaire, ou en omettant code pour les choses qui sont nécessaires.)

Une architecture appropriée vise à éviter ce gaspillage dans le codage Il le fait en limitant, en limitant et en documentant les différentes manières dont un système complexe doit être 1) conçu, 2) codé et testé, 3) livré, 4) maintenu, 5) se remettre de l’échec et 6) finalement mis hors service.

Mon expérience a été que les gens qui aiment juste coder, codent sans penser à la façon dont un système doit fonctionner et être maintenu sur le long terme, passant à la prochaine pomme de terre chaude laissant une pauvre âme pour maintenir un golem laid.

Mais je m'égare ...

C'est la chose la plus simple : pour les systèmes assez simples, l'architecture est évidente et provient de pratiques de conception et de mise en œuvre saines.

Ce n'est que pour les grands systèmes qui impliquent un assez grand nombre de personnes ou un logiciel au niveau du système qui effectue des tâches très complexes qui nécessitent une architecture explicite.

Je suis récemment diplômé de l'université et j'ai commencé à travailler en tant que programmeur. Je ne trouve pas difficile de résoudre des problèmes "techniques" ou de procéder à un débogage, ce que je dirais a une solution.

C’est le minimum requis pour cette profession, et je suis heureux que vous n’ayez aucun problème à les exercer (je serais inquiet si vous le faisiez.)

Mais il semble y avoir une classe de problèmes qui n'ont pas une solution

C’est le pain quotidien de notre profession, le type de problèmes pour lesquels les employeurs sont disposés à 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éveloppeur de logiciels, pour proposer 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 la consommation, un système de vente de billets, etc.), nous visons à produire un logiciel qui imite les fonctions et les exigences d'un tel système.

Nous ne pouvons simplement pas simplement nous en servir et coder le style cow-boy. Nous avons besoin d'une sorte d'architecture. Cela est particulièrement vrai si le projet nécessite des dizaines d'ingénieurs, voire davantage.

Ces choses me troublent et me causent une grande détresse.

C'est ok. Ce n'est pas une matière facile à apprendre ou à enseigner, non sans beaucoup de pratique.

Je passe des heures et des heures à essayer de décider comment "architecter" 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? Je veux juste créer le programme, l'architecture soit maudite.

Malheureusement, ce n'est pas l'architecture logicielle.

Ce n'est même pas la conception, mais juste le codage. Je ferai quelques suggestions au bas de cet article.

Comment puis-je passer plus rapidement de la phase d'architecture et de la phase de codage et de débogage que j'apprécie ?

J'ai du mal à trouver un moyen de répondre à cette question, car c'est plutôt émotionnel.

Essayons-nous de faire un travail ou essayons-nous simplement de profiter de la pratique? C'est formidable quand les deux ne font qu'un, mais dans la vie réelle, ils ne le sont souvent pas.

C'est formidable de faire des choses qui nous plaisent, mais dans un métier aussi complexe que le nôtre, se concentrer uniquement sur ce qui nous passionne ne nous incite pas à mener 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, "embrasse le sucer."

D'autres phrases ont le même conseil. "Si ça ne craint pas, ça n'en vaut pas la peine" et mon préféré: "Si ça craint (et c'est important), continuez jusqu'à ce que ça arrête de sucer."

Mes recommandations:

Il me semble que vous avez encore du mal à comprendre les différences entre

1. le codage (comment coder vos classes, modules ou non, conventions de nommage, visibilité d'accès, champ d'application, etc.),

2. la conception (combien de niveaux, front-end / back-end / db, comment chacun communique, ce qui se passe où) et les décisions d'architecture implicites découlant de la conception de systèmes simples,

3. 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 prochain niveau.

Code propre

"Clean Code" de Robert "Oncle Bob" Martin est un bon point de départ.

Cohésion du logiciel

De plus, je vous suggérerais de vous familiariser avec une métrique logicielle spécifique orientée objet appelée LCOM ou plutôt LCOM4.

Cela peut devenir assez mathématique et ce n’est pas une solution à toute épreuve, mais votre objectif devrait être de comprendre et de détecter de façon empirique (ou si vous le voulez bien) si une classe est cohérente ou si elle manque de cohésion.

http://www.aivosto.com/project/help/pm-oo-cohesion.html#LCOM4 https://www.computing.dcu.ie/~renaat/ca421/LCOM.html

Principes logiciels

Cela va de pair avec le "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.

À mesure que nous progressons dans les principes SOLID, nous devons également nous familiariser avec les principes "GRASP" , qui régissent ou plutôt guident la manière dont nous codons les classes.

Livres supplémentaires

Enfin, je suggérerais également ce qui suit:

• "Refactoring" de Martin Fowler et Ken Beck serait le prochain livre que je lirais dans cette liste.

• "Conception par contrat, par exemple" de Richard Mitchell, Jim McKim et Bertrand Meyer (le dernier de la renommée d'Eiffel.) Ce livre est épuisé, mais vous pouvez en trouver des exemplaires bon marché sur Amazon.

Avec cela, vous devriez avoir une bonne idée de la façon de commencer à coder et à concevoir, et avec de la pratique, de déplacer et de maîtriser (ou au moins de 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 raccourci.

Bonne chance.

Il y a beaucoup d'informations ici et franchement TL; DR. Il y a une chose principale qui, selon moi, amène les gens à se tromper lorsqu'ils essaient d'apprendre à concevoir un système: ils essaient d'y penser dans l'ordre dans lequel le travail sera effectué. Au lieu de cela, vous devez travailler en arrière. En d’autres termes, l’objectif principal de la conception / de l’architecture est de déterminer le résultat final.

Par analogie, considérons l'architecture d'une maison. Un architecte ne commence pas par se poser des questions telles que: "combien de fenêtres cette maison devrait-elle avoir?", "Où placer la première brique?". Ces détails de mise en œuvre ne sont pas la conception, ils sont dérivés de la conception. L'architure commence par une vision, peut-être une esquisse de ce à quoi la maison finie pourrait ressembler. 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 n'a que très peu à voir avec l'architecture.

Commencez d'abord par déterminer quels sont les objectifs de votre conception. Par exemple, est-ce une solution unique? Est-ce que cela va être développé, révisé et maintenu sur 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 déterminé ce que vous devez faire, les détails de la conception suivent naturellement. Ce n'est pas que ces détails soient évidents ou faciles, mais c'est le plan de haut niveau sur lequel sont basés ces choix.

Comment juger du temps que vous devriez consacrer à l’architecture d’un logiciel avant d’obtenir une boucle d’écriture-compilation-test est assez simple: assez d’informations pour tenir dans votre tête, et rien de plus. À moins que le projet sur lequel vous travaillez exige une méthodologie plus stricte. Dans ce cas, en tant que débutant, vous devriez probablement lire un document d'architecture et non pas l'écrire.

Pour ce qui est de nommer des choses, 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 à la manière dont vous nommez les choses, et à réfléchir plus fort à la portée du nom.

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, car chaque itération passée me laissait entrevoir un meilleur design.