Un bon programmeur doit être capable de combiner ses compétences avec le bon sens. Tout est question de pragmatisme et de compétence pour choisir la meilleure solution à votre problème. Lorsque vous êtes confronté à un problème de développement logiciel, vous pouvez utiliser des principes de base pour vous aider à choisir la bonne approche.
Ce texte fournit un ensemble de principes que tout développeur doit connaître et qui doivent être régulièrement actualisés. Considérez-les comme votre arme de programmation secrète.
L'application cohérente de ces principes facilitera votre transition de niveau intermédiaire à senior. Vous constaterez peut-être que certains (probablement) que vous utilisez intuitivement.
Il existe de nombreux principes. Nous nous concentrerons sur les sept plus importants. Les utiliser vous aidera à grandir et à devenir un meilleur programmeur.
1. YAGNI
Vous n'en aurez pas besoin.Ce principe est simple et évident, mais tout le monde ne le suit pas. Si vous écrivez du code, assurez-vous que vous en aurez besoin. N'écrivez pas de code si vous pensez qu'il vous sera utile plus tard.
Ce principe s'applique au refactoring. Si vous refactorisez une méthode, une classe ou un fichier, n'ayez pas peur de supprimer les méthodes inutiles. Même s'ils étaient utiles auparavant, ils ne le sont plus maintenant.
Le jour viendra peut-être où ils seront à nouveau nécessaires - alors vous pouvez utiliser le référentiel git pour les ressusciter d'entre les morts.
2. SEC
Don't Repeat YourselfCe concept a été articulé pour la première fois dans le livre d'Andy Hunt et Dave Thomas, The Pragmatic Programmer: The Journey from Apprentice to Master.
L'idée tourne autour d'une source unique de vérité (SSOT). Qu'est-ce que c'est de toute façon?
Dans la conception et la théorie des systèmes d'information, la source unique de vérité (SSOT) est la pratique de structurer des modèles d'information et des schémas de données, ce qui implique que toutes les données sont traitées (ou éditées) en un seul endroit ... données pertinentes et utilisables.
- Wikipédia
L'utilisation de SSOT créera une base de code plus robuste et compréhensible.
La duplication de code est une perte de temps et de ressources. Vous devrez maintenir la même logique et tester le code à deux endroits à la fois, et si vous changez le code à un endroit, vous devrez le changer à un autre.
Dans la plupart des cas, la duplication de code se produit en raison de l'ignorance du système. Avant d'écrire quoi que ce soit, soyez pragmatique: regardez autour de vous. Peut-être que cette fonction est implémentée quelque part. Cette logique métier existe peut-être ailleurs. La réutilisation du code est toujours une décision intelligente.
3. BAISER
Keep It Simple, StupidCe principe a été développé par l'US Navy en 1960. Ce principe stipule que les systèmes simples fonctionneront mieux et de manière plus fiable.
Ce principe a beaucoup en commun avec la réinvention de la roue, qui a été faite dans les années 1970. Ensuite, cela ressemblait à une métaphore commerciale et publicitaire.
En ce qui concerne le développement de logiciels, cela signifie ce qui suit - ne pas proposer une solution plus complexe au problème qu'il n'en a besoin.
Parfois, la décision la plus intelligente s'avère être la plus simple. Ecrire du code efficace, efficace et simple est génial.
L'une des erreurs les plus courantes de notre temps consiste à utiliser de nouveaux outils uniquement parce qu'ils brillent. Les développeurs doivent être motivés à utiliser les dernières technologies, non pas parce qu'elles sont nouvelles, mais parce qu'elles conviennent au travail.
4. Grand design à l'avant
Global Design FirstCette approche du développement logiciel est très importante et souvent négligée. Assurez-vous que tout est bien pensé avant de passer à la mise en œuvre.
… . , . , . , BDUF, , . , .
—
De nombreux développeurs pensent que s'ils n'écrivent pas de code, ils ne progressent pas. C'est la mauvaise approche. En faisant un plan, vous vous évitez la peine de recommencer à zéro encore et encore.
Parfois, d'autres personnes doivent être impliquées dans les failles et les processus de développement de l'architecture. Plus tôt vous discuterez de tout cela, mieux ce sera pour tout le monde.
Un contre-argument très courant est que le coût de la résolution des problèmes est souvent inférieur au coût du temps de planification. Moins l'utilisateur rencontre d'erreurs, meilleure sera l'expérience. Vous n'aurez peut-être pas une autre chance de traiter ces erreurs.
5. SOLIDE
C'est le principe le plus connu du développement logiciel. Solid est l'abréviation de:
S) Principe de responsabilité unique
Son importance ne saurait être surestimée. Chaque objet, classe et méthode ne devrait être responsable que d'une seule chose. Si votre objet / classe / méthode en fait trop, vous vous retrouvez avec du code spaghetti. Voici un exemple:
const saveTodo = async () => {
try {
response = await saveTodoApi();
showSuccessPop('Success');
window.location.href = '/successPage';
} catch (error) {
showErrorPopup(`Error: ${error} `);
}
}
Cette méthode semble inoffensive, mais elle en fait trop:
- Enregistre l'objet
- Gère la notification dans l'interface utilisateur
- Effectue la navigation
Un autre effet secondaire de ce code est les problèmes de test. Les fonctionnalités compliquées sont difficiles à tester.
O) Principe ouvert - fermé Les
objets programme doivent être ouverts pour extension, mais fermés pour modification. Le fait est que vous ne pouvez pas remplacer les méthodes ou les classes, en ajoutant simplement des fonctions supplémentaires si nécessaire.
Un bon moyen de résoudre ce problème consiste à utiliser l'héritage. JavaScript résout ce problème de composition.
Une règle de base simple: si vous modifiez une entité pour la rendre extensible, vous enfreignez ce principe pour la première fois.
L) Principe de substitution de Liskov
Ce principe stipule que les objets de classes supérieures doivent être remplaçables par des objets de sous-classes et que l'application doit fonctionner comme prévu lorsque de tels remplacements sont effectués.
I) Principe de ségrégation des interfaces
Ce principe a été formulé par Robert Martin lorsqu'il consultait Xerox, et il est évident.
Les objets ne doivent pas dépendre des interfaces qu'ils n'utilisent pas
Le logiciel doit être divisé en parties indépendantes. Les effets secondaires doivent être minimisés pour garantir l'indépendance.
Assurez-vous de ne pas forcer les objets à implémenter des méthodes dont ils n'ont jamais besoin. Voici un exemple:
interface Animal {
eat: () => void;
walk: () => void;
fly: () => void;
swim: () => void;
}
Tous les animaux ne peuvent pas voler, marcher ou nager, donc ces méthodes ne devraient pas faire partie de l'interface ou devraient être facultatives.
D) Principe d'inversion des dépendances
Ce principe ne peut pas être surestimé. Nous devons nous fier à des abstractions et non à des implémentations concrètes. Les composants logiciels doivent avoir une faible cohésion et une cohérence élevée.
Vous devez vous soucier non pas de la façon dont quelque chose fonctionne, mais de la façon dont cela fonctionne. Un exemple simple est l'utilisation de dates en JavaScript. Vous pouvez écrire votre propre couche d'abstraction pour eux. Ensuite, si vous modifiez la source d'obtention des dates, vous devrez effectuer des modifications en un seul endroit, et non en mille.
Parfois, il faut des efforts pour ajouter cette couche d'abstraction, mais cela s'avère payant à la fin.
Jetez un œil à date-io à titre d'exemple , cette bibliothèque a une couche d'abstraction qui vous permet de l'utiliser avec différentes sources de date.
6. Évitez l'optimisation prématurée
Éviter l'optimisation prématuréeCette pratique encourage les développeurs à optimiser leur code avant que l'optimisation ne soit avérée nécessaire. Je pense que si vous suivez KISS ou YAGNI, vous ne tomberez pas dans ce crochet.
Bien faire les choses, il est bon d'anticiper que quelque chose de mauvais va se passer. Mais avant de vous plonger dans les détails de l'implémentation, assurez-vous que ces optimisations sont vraiment utiles.
Un exemple très simple est la mise à l'échelle. Vous n'achèterez pas 40 serveurs en supposant que votre nouvelle application deviendra très populaire. Vous ajouterez des serveurs au besoin.
Une optimisation prématurée peut entraîner des retards dans le code et, par conséquent, augmenter le temps nécessaire pour mettre des fonctions sur le marché.
Beaucoup considèrent l'optimisation prématurée comme la racine de tout mal.
7. Rasoir d'Occam
Brithva Okkama (parfois Lezvie Okkama) est un principe méthodologique qui énonce brièvement: «Vous ne devriez pas multiplier les choses inutilement» [1] (ou «Vous ne devriez pas attirer de nouvelles entités à moins que cela ne soit absolument nécessaire»).
- Wikipédia
Qu'est-ce que cela signifie dans le monde de la programmation? Ne créez pas d'entités inutiles inutilement. Soyez pragmatique - considérez s'ils sont nécessaires car ils peuvent finir par compliquer votre base de code.
Conclusion
Ces principes ne sont pas très difficiles. En fait, c'est la simplicité qui les rend belles. Si vous êtes confus, n'essayez pas de les appliquer tous en même temps. Essayez simplement de travailler avec conscience et essayez d'intégrer progressivement ces principes dans votre flux de travail.
L'utilisation de principes de base mais puissants vous permettra de devenir un meilleur programmeur et de mieux comprendre pourquoi vous faites quelque chose.
Si vous appliquez la plupart des principes de manière intuitive, il vaut la peine de réfléchir et de comprendre pourquoi vous faites quelque chose d'une certaine manière.
Tous mes vœux.
- Premier système de contrôle série de Russie pour un moteur bicarburant avec séparation fonctionnelle des contrôleurs
- Dans une voiture moderne, il y a plus de lignes de code que ...
- - Automotive, Aerospace, (50+)
- McKinsey: automotive
