Si vous regardez le code que vous avez écrit plus tard, serez-vous confus ?

De nombreux programmeurs ne savent pas comment organiser le code, comment améliorer l'efficacité, comment améliorer la maintenabilité, la réutilisabilité, l'évolutivité et la flexibilité du code. Le code qu'ils écrivent est un gâchis, mais un tel gâchis de code peut en fait s'exécuter normalement. .

Cette expérience de codage vous semble familière ?

Beaucoup de programmeurs autour de moi vivront une telle expérience Au bout d'un an et demi, quand je regarde le code que j'ai écrit, c'est le cas. très étrange. J'ai été surpris et j'ai pensé : est-ce que j'avais vraiment écrit un si mauvais code auparavant ? Je peux réellement écrire un si mauvais code !

Quant au code qui est toujours maintenu, en ce moment, un un certain type de pensée surgira. Refactorisez l’idée, ou il y aura peut-être une meilleure façon de la mettre en œuvre. À ce stade, votre relation amour-haine avec le code a déjà commencé...

Ce film commence principalement par les six principes de base. En guise d'introduction au modèle de conception, il décrit la relation entre les six principes de base. et le modèle de conception. Le suivi Il présentera les modèles de conception un par un, détaillant les modèles de conception et le développement quotidien.

Spécifications et contraintes de base

Pour les spécifications et contraintes de base, je crois que chaque équipe qualifiée aura son propre ensemble de choses. D'une part, cela unifie les normes et augmente la lisibilité et la maintenabilité. D'un autre côté, cela facilite également l'apparition de bugs après avoir quitté l'entreprise, et les nouveaux arrivants peuvent localiser et résoudre les problèmes plus rapidement.

Le code désordonné implémente une grande fonction Pour que les retardataires le maintiennent, ils salueront sans aucun doute tous les ancêtres. Une bonne habitude de codage appartient à l’auto-culture d’un programmeur qualifié. Elle est bénéfique pour soi-même et pour les autres sans aucun danger.

Pour les spécifications et les contraintes de développement, la première chose à dire est de nommer.

Au cours des cinq dernières années de travail, j'ai coopéré avec toutes sortes de personnes. Le plus dont je me souviens, c'est que j'ai développé et maintenu cinq projets en même temps, j'ai également coopéré avec divers. héros et héros. Apprendre et progresser ensemble, dans ce processus, la chose la plus gênante pour moi est une dénomination irrégulière.

Il existe de nombreux styles non standard avec toutes sortes de noms étranges. J'ai vu une telle liste de noms. Il y a deux fonctions, l'une est appelée détails de colonne et l'autre est appelée messages de colonne. Les noms sont "ZhuanLaiDetalActivity" et "ZhuanLaiLiuYanActivity", ce qui me rend confus.

N'avez-vous pas peur d'un tel nom ? Si vous avez peur d'un tel nom, vous n'avez vraiment jamais vu le monde. Au moins, vous pouvez vous faire une idée approximative. de cela. Avant, j'ai vu quelques abréviations du pinyin chinois, comme le certificat d'inspection des animaux s'appelle djz, et celui-ci semble encore plus déroutant.

En ce qui concerne le nom Pinyin, je ne sais pas si je serai critiqué si je le mentionne ici. J'ai rencontré des amis qui aiment toujours le nom Hanyu. Le Pinyin est une grande initiative de la nation chinoise à promouvoir. Culture chinoise, mais lors de la programmation, utilisez le pinyin, je me sens vraiment déprimé.

Même avec le soutien de la technologie la plus puissante, le code écrit ressemble au travail d'un élève du primaire. Je ne veux pas mépriser ici le pinyin chinois, j'exprime juste quelques réflexions intérieures.

Recommandation : une dénomination en grosse bosse, en petite bosse ou en trait de soulignement est acceptable. S'il n'y a pas de norme unifiée, vous pouvez vous référer au "Manuel de développement Java d'Alibaba". Pour les amis qui viennent d'entrer dans l'industrie, ils devraient commencer. avec le nom. Cela sera d’une grande aide pour la croissance future.

Adresse de téléchargement du manuel de développement : https://pan.baidu.com/s/1mjZxvSW.

Une autre chose à souligner est l'annotation. Beaucoup de gens peuvent penser que plus il y a de commentaires, mieux c'est. J'ai déjà vu des livres préconisant l'ajout de plus de commentaires, mais je pense le contraire. Parfois, les commentaires nous ajoutent beaucoup de fardeau et d'incompréhension.

Lors de ma dernière révision, j'ai découvert que lorsque certains collègues copiaient une partie de mon code, ils voulaient en fait créer une autre fonction. Ils voulaient juste copier du code et apporter des modifications majeures (je n'aime pas réinventer). la roue, donc pour certaines fonctions similaires, il est préférable de les rendre plus flexibles pour améliorer la réutilisabilité et la flexibilité du code).

En fait, il y a très peu d'endroits qui peuvent être réutilisés. Je ne comprends pas pourquoi je n'écris pas moi-même quelques lignes de code. Ce n'est pas un problème. J'ai également copié mes notes et mon auteur, quand je suis entré dans cette classe, j'ai découvert que l'auteur était moi. Je suis allé sur git pour vérifier les soumissions historiques, et la description fonctionnelle n'avait absolument aucun rapport avec cette classe. ...

Il y a encore une chose à dire à propos des commentaires. La seule chose est que certains commentaires redondants doivent être combinés avec la dénomination. Avec de bonnes normes de dénomination, de nombreux commentaires inutiles peuvent être omis, par exemple. comme connexion et inscription, plus les commentaires de connexion et d'inscription, qui sont totalement inutiles.

Les bonnes habitudes peuvent apporter beaucoup de commodité à notre développement, mais certaines personnes aiment les nommer textview1 et textview2 Même si elles sont commentées, lorsqu'elles seront utilisées ci-dessous, ce seront toujours un groupe d'alpagas en cours d'exécution. .Le genre qui monte et descend.

1.for (int i = 0; i

2. // TODO

3. Beaucoup de gens peuvent penser que ce genre de code est normal, et certains peuvent blâmer le professeur Tan Haoqiang. Oui, il y a effectivement beaucoup de problèmes dans le livre de Tan Haoqiang, mais ce n'est pas la raison pour laquelle il faut écrire ce genre de code.

Dans le développement quotidien, tout en maintenant le code des autres, vous déboguez toujours l'instruction for. Ne pensez-vous pas qu'un tel code est terrible et un peu déroutant ? Même si vous ajoutez des commentaires, c'est toujours un gâchis.

Parce que chaque équipe a ses propres normes et contraintes. Les grandes entreprises auront leur propre ensemble de normes qui sont unifiées pour chaque équipe. Différentes langues ont également des contraintes différentes. Si j'ai le temps dans le futur, je le ferai. en écrira un spécial. Un article de blog avec des contraintes et des spécifications détaillées est présenté.

Il y a tellement de choses que je veux écrire sur ce domaine, comme l'utilisation aveugle des cas, 1, 2 et 3 sont toujours déroutants, comme les variables de substitution constantes nécessaires, telles que les pools de threads remplaçant les threads , comme Utiliser des singletons si nécessaire. Il y a tellement de choses que je n'entrerai pas dans les détails. Aujourd'hui, je vais expliquer deux points clés, la dénomination et l'annotation.

Recommandation : utilisez les commentaires de manière rationnelle. Pour les novices, lors de l'apprentissage d'un code peu familier et d'une logique peu claire, utilisez autant de commentaires que possible pour faciliter la compréhension. Pour les vétérans, utilisez une dénomination aussi standardisée que possible.

L'effet des commentaires est obtenu grâce à la dénomination, mais lorsque la logique est complexe ou qu'il y a trop d'états de fonctionnement, les commentaires nécessaires sont toujours très importants pour réduire les coûts de maintenance.

Quelques idées de programmation que vous devriez connaître

Le temps qu'un programmeur passe à écrire des programmes représente probablement 10 à 20 % de son temps de travail. La plupart des programmeurs peuvent écrire environ 10 à 12 lignes de code. cela en fera le produit final, aussi technique soit-il.

Les bons programmeurs passent 90 % de leur temps à réfléchir, rechercher et expérimenter pour trouver la solution optimale. Les mauvais programmeurs passent 90 % de leur temps à déboguer des programmes problématiques et à modifier aveuglément des programmes dans l’espoir qu’une certaine manière d’écrire fonctionnera.

Pour un bon programmeur, la logique est ce qui compte le plus. Il est prêt à passer plus de temps à réfléchir. Ce faisant, moins de bugs apparaîtront et le taux de bugs peut même être réduit à un niveau très bas.

Je ne suis pas un très bon développeur, mais j'ai toujours cette habitude au fil des années. Pour des fonctions complexes ou diverses, je clarifie toujours mes idées en premier et liste les opérations et les bugs. champs de mines. Je dis souvent à mes coéquipiers qu’une image vaut mille mots. Si vous clarifiez vos pensées avant de commencer, vous obtiendrez le double du résultat avec la moitié de l’effort.

Peu importe si la logique métier est complexe ou non, allez-y et faites-le. Si vous trouvez quelque chose qui ne va pas, vous le modifierez. Si vous trouvez quelque chose qui manque, vous l'ajouterez. le code est toujours empilé là. Après plusieurs fois, les modifications ont changé de manière méconnaissable, et c'est encore plus misérable pour les personnes chargées de la maintenance.

Ici, l'auteur suggère également aux lecteurs, autant essayer de dessiner d'abord, continuer à démonter un module en interfaces, et implémenter le module en implémentant l'interface, afin d'obtenir une programmation orientée interface, donc La maintenabilité sera considérablement améliorée...

Pour la communication entre les modules, il ne doit pas s'agir de l'association entre les classes, mais pour réaliser une interaction par l'abstraction, l'abstraction ne doit pas s'appuyer sur des détails. Elle doit s'appuyer sur l'abstraction. C'est un peu compliqué, pour parler franchement, il s'agit d'une programmation orientée interface plutôt que d'une programmation orientée implémentation.

L'avantage de ceci est que lorsque vous souhaitez remplacer la classe appelée par une autre classe d'implémentation à l'avenir, vous n'avez pas besoin de changer les classes qui l'ont appelée une par une, car elles s'ajustent. interface. L'interface n'a pas changé. Si vous remplacez la classe d'implémentation de l'interface par une nouvelle classe dans la configuration, tout sera remplacé.

Plus le couplage entre les classes est faible, plus il est propice à la réutilisation. Si une classe faiblement couplée est modifiée, cela n'affectera pas les classes associées.

Suggestion : Videz votre esprit avant de commencer à obtenir deux fois le résultat avec la moitié de l'effort. Pendant le processus de développement, vous pourriez aussi bien définir d'abord l'interface et terminer le développement du module en implémentant l'interface pour réduire autant que possible le taux de bugs et écrire un meilleur code.

L'amélioration des capacités techniques se reflète principalement dans le code « haute cohésion et faible couplage », car ces idées ont dérivé de nombreux modèles de développement, tels que les désormais populaires MVC, MVP, MVVM, etc.

Itération et reconstruction des versions

Lorsque nous construisons un système, nous ne devons pas nous attendre à ce que les exigences du système soient déterminées au début et ne changeront plus jamais. C'est irréaliste et non scientifique. est que puisque les exigences sont vouées à changer, comment le logiciel de conception peut-il être relativement facile à modifier lorsqu'il est confronté à des changements dans les exigences, de sorte que lorsque de nouvelles exigences surviennent, le programme entier doit être renversé et redémarré.

Je crois que de nombreux amis l'ont rencontré. Ce qui était à l'origine une exigence très courante est devenu une fonction énorme après N itérations et modifications. Avec l'itération continue des versions, le coût de maintenance a également augmenté au fur et à mesure. De plus en plus grand, cela crée un cercle vicieux, et le code de refactorisation est sur le point d'entrer dans la phase de l'histoire.

Il est indéniable que du point de vue du coût de maintenance, la reconstruction est en effet une très bonne solution. Le coût de la reconstruction est inférieur au coût de la maintenance de base d'origine, et elle est également plus pratique pour la maintenance future. Certaines entreprises poussent même directement l'ensemble du projet vers la reconstruction après plusieurs itérations de versions. Ce genre de chose ne se produit pas seulement dans les petites entreprises, mais se produit également plusieurs fois dans certaines grandes entreprises.

Techniquement parlant, il y a trois choses à faire lors de la refactorisation d'un code complexe : comprendre l'ancien code, décomposer l'ancien code et créer un nouveau code.

L'ancien code qui doit être refactorisé est souvent difficile à comprendre, en particulier dans les modules qui comportent plusieurs itérations et sont manipulés par de nombreuses personnes ; un couplage excessif entre les modules conduit à un seul mouvement affectant l'ensemble du corps, ce qui le rend difficile à contrôler. la portée de l'influence ; l'ancien code n'est pas facile à tester. Il n'y a aucune garantie que le nouveau code sera correct, surtout si la documentation du produit est incomplète.

C'est un morceau de code que j'ai trouvé lors de la dernière révision. Sans parler de l'utilisation irrégulière des constantes. C'est le résultat d'itérations du produit, mais ce n'est pas un. excuse. , après avoir construit la roue tant de fois, cela ne devrait vraiment pas l'être. En tant que matériel pédagogique négatif pour la réutilisabilité du code, cela se reflète clairement ici. S'il y a plus d'états, cela sera inévitablement répété plusieurs fois...

Suggestion : la refactorisation n'est pas omnipotente, la refactorisation après la modification du code. dans plusieurs versions ultérieures, le code est devenu désordonné et désorganisé, et le désordre du code était toujours répété.

Comme nous ne pouvons pas être sûrs que les exigences seront modifiées à l'avenir, nous ne pouvons y faire face qu'en améliorant la qualité du code, en nous adaptant aux changements de la même manière, en concevant les interfaces de manière raisonnable et en réfléchissant davantage à chaque fois. lorsque les exigences sont modifiées, le code est encapsulé et extrait, et la logique existante est modifiée le moins possible.

L'importance des modèles de conception

Ceux qui savent concevoir sont des ingénieurs en construction, et ceux qui ne savent pas concevoir sont ceux qui déplacent les briques.

J'ai déjà dit beaucoup de choses, parlons maintenant directement de l'importance des modèles de conception. Lorsqu'il s'agit de modèles de conception, nous devons mentionner les six principes de base et la conception architecturale. importance des modèles de conception Vous pouvez l'imaginer.

Tout d'abord, les six principes de base sont encore un peu controversés. Dans les livres que j'ai lus auparavant, il s'agit généralement du principe de responsabilité unique, de la loi de Déméter, du principe de substitution de Richter, du principe d'ouverture et de fermeture, de l'inversion de dépendance. Principe et principe d'isolation de l'interface.

Mais j'ai vu récemment sur certains posts qu'il y a un dicton selon lequel il n'y a pas de principe d'isolation d'interface, mais le principe de réutilisation par synthèse/agrégation Afin de ne pas affecter les préparations précédentes, le principe de réutilisation par synthèse/agrégation sera utilisé. être pris séparément. Sortez et dites-le.

Six principes de base, qui sont l'âme de toute la conception architecturale et une idéologie directrice de la conception architecturale, tandis que les modèles de conception sont une technique de conception spécifique de la conception architecturale. la pratique spécifique de la conception architecturale.

Commençons par la conception architecturale. La conception architecturale se reflète principalement dans les capacités d'abstraction. Les capacités d'abstraction dépendent de l'expérience de codage, de la compréhension et du démontage fonctionnels de l'architecte, ainsi que de la rigueur logique.

Lorsque vous faites de la conception architecturale, vous devez considérer le problème de la manière la plus complète possible et rendre le code aussi inclusif que possible. La tolérance mène à la grandeur. C'est la condition de base que les concepteurs d'architecture devraient avoir.

Plus les problématiques considérées sont globales et inclusives, plus le travail sera difficile et plus d'obstacles se créeront. Résumez raisonnablement ces problèmes détaillés et proposez des solutions. Plus le niveau d'abstraction est élevé, plus la solution est raisonnable. C'est la valeur de l'architecte.

Des exigences spécifiques à la mise en œuvre du code, en passant par des produits spécifiques. Le but de la conception architecturale n'est rien d'autre que la réutilisabilité, l'évolutivité et la stabilité du système. Les éléments spécifiques ne peuvent pas bien refléter ces caractéristiques. Seules les choses abstraites peuvent les refléter au mieux.

Dans le processus de conception de l'architecture, le principe de responsabilité unique nous dit que nous devrions mieux refléter une cohésion élevée et un faible couplage. Cette classe est utilisée pour les demandes de données, alors ne mettez pas de méthodes pour analyser json. this La classe est utilisée pour le chargement de l'image. Veuillez isoler les annotations de la vue afin qu'une classe ne soit responsable que d'une seule responsabilité et n'ait qu'une seule raison de changement.

Si une classe assume plus de responsabilités, cela signifie regrouper ces responsabilités, ce qui entraînera des coûts de maintenance inutiles. D'un point de vue plus large, les modèles MVP et MVC sont tous deux des incarnations du principe de responsabilité unique. Le modèle, la vue et le contrôle sont isolés et chacun remplit ses propres tâches.

La loi de Déméter nous guide selon laquelle si deux classes n'ont pas besoin de communiquer directement entre elles, alors les deux classes ne doivent pas interagir directement. Si une classe doit appeler une méthode d’une autre classe, l’appel peut être transmis via un tiers.

Plus le couplage entre les classes est faible, plus il est facile de le réutiliser. Si une classe faiblement couplée est modifiée, cela n'affectera pas les classes associées. L’accent est mis principalement sur le couplage lâche entre les classes.

Quant au principe de substitution de Liskov, beaucoup de gens n'ont peut-être pas entendu parler de ce terme, mais il est utilisé tout le temps dans le processus de développement actuel. En fait, il est très simple. leurs types de parents.

Prenons un exemple simple, "List list = new ArrayList();". L'avantage de cela est en fait très simple. Par exemple, un jour, ArrayList ne peut pas répondre à la demande et vous. vous devez utiliser LinkedList à la place. Il vous suffit de remplacer ArrayList par LinkedList au lieu de modifier l'objet de liste globale, ce qui améliore la maintenabilité.

Le principe d'ouverture et de fermeture est au cœur du principe orienté objet. Il se compose de deux parties, ouverte à l'extension et fermée à la modification. Les exigences logicielles changeront toujours. Pour les concepteurs de logiciels, il est nécessaire de parvenir à une extension flexible du système sans modifier le système d'origine.

Être ouvert à l'extension signifie une programmation abstraite, pas une programmation concrète, car l'abstraction est relativement stable via des interfaces ou des classes abstraites, et les limites sont définies pour les extensions qui n'existent pas dans les interfaces ou les classes abstraites. autorisé à apparaître.

Laissez la classe dépendre d'une abstraction fixe, elle est donc fermée à la modification. Ceci est basé sur l'héritage et le polymorphisme, qui peuvent implémenter l'héritage de classes abstraites et étendre les méthodes en remplaçant leurs méthodes.

Le principe de l'inversion des dépendances fait référence au fait de s'appuyer sur l'abstraction plutôt que sur une implémentation spécifique. Cela a été mentionné ci-dessus. En fait, il s'agit d'une programmation orientée interface plutôt que d'une programmation orientée implémentation. pour résoudre le couplage.

En général, la probabilité de changement d'abstraction est très faible, ce qui rend les programmes utilisateur dépendants de l'abstraction, et les détails d'implémentation dépendent également de l'abstraction. Même si les détails d'implémentation continuent de changer, tant que l'abstraction reste inchangée, le programme client n'a pas besoin de changer. Cela réduit considérablement le couplage des programmes clients aux détails de mise en œuvre.

Le principe d'isolation des interfaces stipule qu'"il est préférable d'utiliser plusieurs interfaces spécialisées plutôt qu'une seule".

Un module doit s'appuyer sur les interfaces dont il a besoin, fournir toutes les interfaces dont il a besoin et éliminer les interfaces inutiles. En même temps, il doit également suivre le principe de responsabilité unique, afin d'éviter la pollution causée par les ballonnements. Les interfaces non pertinentes sont fusionnées pour former une grande interface gonflée, ce qui est une sorte de pollution de l'interface.

La granularité de l'interface ne peut pas être trop petite. Si elle est trop petite, le nombre d'interfaces augmentera fortement, ce qui n'est pas convivial pour les développeurs ; si la granularité de l'interface est trop grande, la flexibilité sera réduite ; des services réduits et personnalisés ne peuvent pas être fournis, ce qui entraînera des problèmes pour l'ensemble du projet. Les risques imprévisibles et la conception raisonnable de l'interface sont également un art.

Il doit y avoir beaucoup de controverses à propos de cette image, car de nombreux modèles de conception utilisent plusieurs principes de base. L'image ci-dessus n'est qu'un résumé approximatif des modèles de conception.

Souligne l'incarnation spécifique des six principes de base (y compris le principe de synthèse/agrégation et de réutilisation) dans le modèle de conception. Il explique également que les six principes de base et les 23 modèles de conception sont complémentaires les uns des autres. Les six principes de base servent de pierre angulaire et de modèle aux modèles de conception. Les modèles de conception sont une manifestation flexible de l'application de six principes de base.

Le principe de synthèse/agrégation et de réutilisation est quelque peu controversé. À l'heure actuelle, certains livres conservent encore le principe de réutilisation de composition/agrégation et suppriment le principe d'isolation d'interface. Le principe de réutilisation de composition/agrégation fait référence à la mise en œuvre d'une utilisation moindre de l'héritage et d'une utilisation accrue des relations de composition.

La composition et l'agrégation sont deux types de relations de modélisation d'objets. L'agrégation représente une relation de propriété faible. Le tout est composé de parties, et la partie peut exister en tant qu'individu indépendant sans être séparée du tout. Type de relation d'association. Une relation de propriété forte reflète la relation stricte entre la partie et le tout. Le cycle de vie de la partie et du tout est cohérent et la partie ne peut pas être séparée du tout.

Résumé : Les six principes de base sont l'incarnation de la pensée orientée objet. Le principe de responsabilité unique et le principe d'isolation de l'interface incarnent l'idée d'encapsulation. Le principe de fermeture incarne l'encapsulation et l'encapsulation des objets, et le principe de substitution de Liskov est la norme pour l'héritage des objets.

Quant au principe d'inversion de dépendance, il est l'incarnation du polymorphisme et des idées abstraites. Sur la base d'une compréhension complète de l'orientation objet, de la maîtrise des principes de conception de base et de notre capacité à les utiliser de manière flexible dans la conception de projets, nous pouvons améliorer la qualité de notre code et notre conception structurelle.

Surtout pour garantir la réutilisabilité, la maintenabilité, l'évolutivité et la flexibilité, qui sont également des connaissances nécessaires pour comprendre et maîtriser les modèles de conception.

Supplément

Concernant les six principes de base, notre développement doit les garder à l'esprit et les utiliser de manière flexible. Concernant l'application des modèles de conception dans le développement quotidien, une chose doit être soulignée. ce qui te convient est le meilleur.

Si un module est très léger à ce stade et utilise des modèles de conception juste pour le plaisir d'utiliser des modèles de conception, cela semblera sans aucun doute indescriptible, rendra le projet gonflé et entraînera également des coûts de maintenance inutiles (bien que la maintenance. les coûts sont faibles).

J'ai récemment commencé à organiser l'information et à me préparer à écrire un sujet spécial sur les modèles de conception, se concentrant principalement sur les pièges du MVP et la loi de Dimit, le cadre et les principes d'ouverture et de fermeture, les singletons et les pièges, le skinning et le mode observateur, le chargement. les listes et le modèle de méthode de modèle, la comparaison entre les constructeurs et les constructeurs, les connexions tierces multiples et les modèles de commande continueront d'être améliorés à l'avenir, alors restez à l'écoute.