Comment savoir ce qui doit être fait dans la conception orientée objet?

Tout d'abord un avertissement: je ne sais pas vraiment si cette question correspond à ce site Web, mais je la trouve toujours une question pertinente non seulement pour moi mais pour d'autres personnes qui sont débutants. Si la question peut être améliorée pour s'adapter ici, veuillez indiquer les commentaires int. Si cela ne vous convient pas, faites-le moi savoir et si possible, faites-moi savoir où cela peut être discuté car je n'ai pas trouvé de bons forums pour cela.

J'ai appris à programmer en 2009 lorsque j'ai étudié PHP. Plus tard en 2012, je suis passé à C # et .NET. Quoi qu'il en soit, le codage n'est pas le problème, l'écriture d'algorithmes n'est pas mon problème. Mon problème réel est de savoir ce qui doit être codé pour répondre à une exigence et où il doit être codé.

La plupart des cours disponibles sur le Web abordent le comment - comment écrire du code dans une certaine langue, comment utiliser certains ensembles d'API, etc. Ce n'est pas mon point ici.

Au cours de ces années, j'ai lu beaucoup de choses sur un tas de choses: l'analyse et la conception orientées objet, les modèles de conception, la conception pilotée par domaine, etc. Je comprends par exemple les principes SOLID, certaines des principales idées de DDD comme la nécessité de l'engagement d'experts du domaine, le développement d'un langage omniprésent et ainsi de suite. J'oserais dire que j'ai une formation théorique au moins raisonnable.

Mais quand il s'agit de pratiquer, j'ai l'impression d'être un désastre. Il y a quelque temps, je devais poursuivre le développement d'un système financier déjà développé par quelqu'un d'autre. C'est ce genre d '"ancien système" développé avec C # et WinForms. C'était la première fois que je choisissais un projet avec une réelle complexité de domaine, avec beaucoup de règles métier, etc.

J'avoue que lorsque je reçois les exigences la plupart du temps, je pense "comment diable cela peut-il être fait?" - Je n'ai aucune idée de la façon même de commencer à travailler sur les exigences pour comprendre ce qui doit être fait. Je crois que mes confusions principales sont ce que je dois coder, quelles classes, interfaces et où chaque élément logique va, sur quelle classe chaque chose doit être. Le problème est que je ne sais pas par où commencer.

La plupart du temps, avec beaucoup de réflexion, je me retrouve avec quelques idées, mais je ne sais jamais juger si mon idée est correcte ou non.

Je veux dire que je ne pense pas que ce soit un manque de théorie, comme je l'ai dit, j'ai lu un tas de choses sur l'architecture logicielle et l'orientation des objets, on m'a recommandé mais cela n'a pas beaucoup aidé à identifier ce qui doit être fait dans la pratique .

Alors, comment puis-je apprendre à vraiment faire du design orienté objet? Ce que je veux apprendre, c'est: les exigences données savent comment commencer à travailler sur elles dans un processus qui conduit à découvrir ce qui doit être fait et où chaque morceau de code appartient. Comment puis-je également apprendre à juger si mon idée est correcte ou non?

Je pense qu'il ne serait pas possible d'expliquer pleinement cela comme une réponse ici. Ce que je recherche, cependant, qui peut être selon le style du site, ce sont des réponses donnant simplement un aperçu et pointant quelques références (livres, cours en ligne, etc.) qui peuvent être utilisées pour développer les idées et vraiment apprendre ces choses.

Alors, comment puis-je apprendre à vraiment faire de la conception orientée objet? Ce que je veux apprendre est: les exigences données savent comment commencer à travailler sur elles dans un processus qui conduit à découvrir ce qui doit être fait et où chaque morceau de code appartient. Comment puis-je également apprendre à juger si mon idée est correcte ou non?

Eh bien tout d'abord, arrêtez de penser que la conception orientée objet est correcte. C'est comme penser que l'anglais est correct.

Le paradigme orienté objet n'est pas correct. Il présente certains avantages et inconvénients. C'est un idéal. Ce n'est pas notre seul. C'est mieux que rien mais ce n'est certainement pas tout.

Je code depuis des décennies maintenant. J'étudie ce truc depuis presque aussi longtemps que ses idées existent. J'apprends toujours ce que cela signifie. Les experts apprennent encore ce que cela signifie. Notre domaine entier a moins de 100 ans.

Donc, lorsque vous prenez une pile d'exigences et que vous obtenez du code qui les satisfait tout en ayant l'impression que le code que vous avez écrit est un gâchis tragique, vous n'êtes pas seul. Le code de travail est simplement la première étape vers un bon code. Un code qui fonctionne non seulement mais que les autres peuvent lire et comprendre facilement. Code adaptable rapidement lorsque les besoins changent. Code qui vous donne envie de vous asseoir et de dire "Wow, c'est si simple".

Le problème est que nous ne sommes pas payés pour faire tout cela. Nous faisons tout cela parce que nous sommes des professionnels. Nous devons faire tout cela quand le patron ne regarde pas parce qu'il y a toujours un délai. Mais nous voulons revenir dans 5 ans et dire aux débutants: "Oh ouais, j'ai écrit ça. Ça marche toujours hein? Cool."

Comment y arrivez-vous? Entraine toi. N'acceptez AUCUNE idée de conception sur la foi. Quelqu'un ne se taire pas sur la façon dont la conception événementielle simplifiera cette conception? Vous ne savez pas s'ils ont raison? Construisez votre propre projet de jouet à la maison en utilisant le modèle d'observateur. Joue avec ça. Essayez de trouver des choses avec lesquelles cela N'AIDE PAS.

Lis. Question. Tester. Répéter.

Lorsque vous arrivez au point que vous le faites depuis 80% de votre vie, vous serez aussi confus que moi.

J'avoue que lorsque je reçois les exigences la plupart du temps, je pense "comment diable cela peut-il être fait?" - Je n'ai aucune idée de la façon même de commencer à travailler sur les exigences pour comprendre ce qui doit être fait. Je crois que mes confusions principales sont ce que je dois coder, quelles classes, interfaces et où chaque élément logique va, sur quelle classe chaque chose doit être. Le problème est que je ne sais pas par où commencer.

J'avais l'habitude de ressentir la même chose. Puis j'ai découvert la joie du refactoring. Soyez prêt à adapter les conceptions au fur et à mesure que vous codez. Essayer de tout régler sur papier à l'avance est la manière la plus difficile de le faire. Écrivez du code qui peut être prouvé faux, prouvez-le faux et corrigez-le.

Le développement de logiciels se résume à la livraison de logiciels fonctionnels, dans les délais et dans le respect du budget tout en répondant à tous vos critères d'acceptation. En supposant que vous ayez réussi à le faire, la qualité perçue du code ou de sa structure est une préoccupation secondaire.

Le problème est bien sûr que l'écriture de nouveau code greenfield a tendance à être beaucoup moins cher et plus facile que la maintenance du code hérité, donc plutôt que d'être trop accroché à la qualité ou à l'architecture du code, n'oubliez pas que votre véritable problème est la maintenabilité.

En règle générale, le code est considéré comme maintenable lorsque les coûts, le temps et les risques associés à la modification de ce code sont proportionnellement suffisamment bas pour que la correction de bogues ou la mise en œuvre de modifications des exigences soit toujours rentable, et qu'en mettant en œuvre ces modifications, vous ne perpétuez pas une «spirale de la mort» "de code-entropie.

À l'inverse, le code est considéré comme non maintenable lorsque vous ne pouvez pas changer ou refactoriser en toute confiance sans risque sérieux de casser quelque chose ou de dépenser trop de temps / d'argent pour vous assurer que rien n'est cassé - c'est-à-dire lorsque le temps, les coûts et les risques liés à l'utilisation de ce code sont disproportionnellement élevé par rapport aux avantages de faire des changements (c.-à-d. que votre employeur ou client ne perd pas d'argent en ajoutant de nouvelles fonctionnalités, en corrigeant des bogues, etc.)

Rappelez-vous que même le désordre de spaghetti le plus diabolique peut être potentiellement maintenable si vous avez suffisamment de provisions autour du désordre pour vous protéger contre les changements de rupture (bien que de tels cas soient rares). Le problème avec un désordre de spaghetti est que le protéger contre les changements de rupture a tendance à être assez cher et inefficace - surtout si vous le faites rétrospectivement.

Le moyen le plus fiable pour vous assurer que vous avez écrit du code maintenable est peut-être d'écrire (lorsque cela est raisonnablement possible) une suite adéquate de tests automatisés en même temps (tout en tirant pleinement parti de tout autre outil d'analyse statique qui pourrait être disponible).

Vous n'avez pas particulièrement besoin de suivre une méthodologie de développement stricte telle que TDD / BDD afin de vous retrouver avec suffisamment de tests automatisés pour vous permettre de refactoriser; vous en avez juste besoin pour protéger le code contre les modifications accidentelles à l'avenir.

Si votre code est couvert par des tests automatisés, vous pouvez vous détendre sur sa conception et sa structure en sachant que vous êtes couvert par ces tests; vous pouvez refactoriser agressivement à une date ultérieure, ou même le jeter et recommencer.

Cela soulève la question de savoir comment écrire du code facilement testable; c'est généralement l'argument principal pour suivre les principes SOLID; en fait, la caractéristique du code qui adhère aux principes SOLID est qu'il est facile et rentable d'économiser des tests unitaires.

Bien sûr, vous n'avez parfois pas non plus le temps d'écrire des tests unitaires; cependant, si vous avez écrit tout votre code tout en gardant à l'esprit la question "Comment écrire des tests automatisés pour cela?" (même si vous n'avez pas réellement implémenté ces tests), vous avez probablement également réussi à trouver une conception raisonnablement maintenable.