L'expérience de croissance de chaque lion de siège est toujours similaire.
Lorsque j'ai commencé à apprendre cette technologie, j'espérais pouvoir fabriquer indépendamment divers produits intelligents.
Avec cette capacité, vous serez plus compétitif et gagnerez plus d'argent, et vous ne serez pas abandonné dans une ère de plus en plus intelligente.
Malheureusement, tout le monde ne peut pas atteindre la ligne d'arrivée.
Beaucoup de gens apprennent à apprendre mais ne peuvent pas apprendre et finissent par abandonner avec regret
Bien que certaines personnes aient fait de nombreux détours, elles ont survécu avec une persévérance étonnante.
Il y a trop de goulots d'étranglement à franchir en cours de route, chacun pouvant déterminer si vous êtes l'élu ou éliminé.
Pour les ingénieurs qui viennent d'entrer dans l'industrie, il y a un goulot d'étranglement qu'il est très difficile de franchir.
C'est ainsi que les programmes que vous écrivez deviennent plus professionnels.
Pendant longtemps, même si je pouvais écrire les fonctions moi-même, j'ai toujours eu l'impression que mes programmes étaient écrits dans le désordre.
L'image ci-dessus est un programme écrit par moi qui vient de participer au développement d'un micro-ordinateur à puce unique pendant un an. Je ne sais pas si vous pouvez voir des problèmes.
Laissez-moi l'analyser pour vous :
1. L'ensemble du programme du projet est écrit dans la fonction main
2. Trop de variables globales
3. Pas de pensée modulaire
C'est la logique du programme de ce projet, et je suis sur le point de m'effondrer quand il sera transféré.
En fait, le produit n'est pas compliqué, il s'agit d'un panneau de commande d'un chauffe-eau solaire.
Cependant, une fois qu'elles sont combinées, les fonctions entreront gravement en conflit les unes avec les autres, ce qui entraînera des changements de problèmes ici et là.
Une fois qu'un problème survient, toutes les fonctions doivent être testées à nouveau.
Si vous n'avez pas rencontré ce genre de problème, vous ne comprendrez pas l'importance de l'architecture du programme.
La qualité de l'architecture du programme affectera tous les aspects de l'ensemble du programme.
Par exemple, les variables globales, j'ai aussi réalisé ce problème plus tard.
C'est-à-dire qu'il y a trop de variables globales, et le programme sera hors de contrôle lorsqu'il est trop volumineux.
La première est d'éviter la duplication des noms de variables globales, et la seconde est que si une variable n'est pas commentée, elle sera propre après un mois.
Surtout lorsque vous définissez ensemble les variables globales de l'ensemble de la fonction projet, c'est un désastre.
Cependant, cela n'est certainement pas possible sans variables globales .
Reste à l'utiliser raisonnablement , cette fois-ci à l'épreuve de l'expérience des ingénieurs.
Comment fait-on ça
Prenons l'exemple du projet de cours de notre passerelle IoT de programmation Wuji MCU.
J'ai adopté la pensée de la programmation modulaire et séparé la couche matérielle et la couche applicative de l'architecture globale.
D'une manière générale, il y a une couche intermédiaire, comme l'analyse de certains protocoles.Le code dans la couche intermédiaire du projet n'est pas grand-chose, ce qui est simplifié par moi.
Les variables globales de chaque module fonction sont définies dans leurs propres fichiers .c.
Par rapport au programme de panneau de commande de chauffe-eau solaire que j'ai créé, bien que le nombre de variables globales n'ait peut-être pas changé, il est évident que la méthode d'écriture modulaire est plus claire.
Bien sûr, ce n'est pas aussi simple que de rendre le code plus propre, mais cela présente également les avantages d'une forte évolutivité fonctionnelle et d'une forte portabilité.
L'évolutivité forte ressemble à un terme technique, et de nombreux novices peuvent ne pas comprendre ce que cela signifie.
Imaginez, le code de fonction du produit est enfin terminé, le test ne pose aucun problème et il est livré au client pour test.
Après le test, le client a dit qu'il voulait changer la fonction, et il l'a changé 7 ou 8 fois dans les deux sens, les avez-vous tous déchirés ?
C'est normal, le client est un novice en matière de technologie, et il ne sait pas combien vous devez payer derrière ses paroles.
Les ingénieurs expérimentés commencent par apprendre à être paresseux, peu importe l'urgence du projet, c'est génial si vous avez encore du temps libre après avoir terminé le projet.
C'est là que l'extensibilité du code compte.
Parlons maintenant de la portabilité.
La portabilité est relative au MCU (plate-forme matérielle).
Par exemple, j'avais l'habitude de faire ce projet sur le micro-ordinateur à puce unique STM32. Maintenant que le prix de la puce a augmenté, le patron a demandé de le remplacer par du GD32.
Cette fois testera la portabilité de votre programme.
Les programmes écrits par des ingénieurs expérimentés n'ont généralement besoin que de modifier les interfaces périphériques de la couche matérielle, et les codes de fonction logique du produit de la couche application n'ont fondamentalement pas besoin d'être modifiés.
Et Caiji devra peut-être réécrire tout le code...
Le problème d'une variable globale semble simple, mais si vous voulez le résoudre, vous devez toujours penser du point de vue de l'ensemble de l'architecture du programme.
Si vous êtes encore loin de cette étape, il existe une méthode plus pratique.
Utilisez simplement la structure .
Utiliser la pensée orientée objet pour définir uniformément des variables du même type que des structures.
Par exemple, le temps est divisé en année, mois, jour, semaine, heure, minute et seconde.
Si vous utilisez la forme d'une variable globale distincte, elle est plus fragmentée et plus difficile à gérer.
Dans ce cas, il est plus approprié d'utiliser une structure, car ce sont tous des paramètres de l'objet "temps".
Il en existe de nombreux similaires. Par exemple, GPIO est également un objet. Les paramètres incluent le numéro de port, le numéro de broche, le mode d'entrée, le mode de sortie, la fréquence, etc.
Vous pouvez consulter la bibliothèque de micrologiciels STM32, qui est une réflexion de programmation orientée objet typique.