Bonjour, je fais de la programmation depuis 8 ans et de la programmation dans toutes ses manifestations: développement du côté serveur dans différents langages de programmation, développement du côté client, programmation des réseaux, administration de linux et optimisation des performances. Et quand vous avez été occupé avec une entreprise pendant si longtemps, que vous l'aimez sincèrement et que vous vous efforcez de vous développer vous-même, alors inévitablement, diverses relations causales dans le domaine correspondant commencent à émerger, vous commencez à voir ces relations que vous ne connaissiez même pas auparavant ou simplement considérées comme insignifiantes, c'est ce que les gens appellent l'expérience.
Et c'est à propos d'une de ces relations causales que je voudrais partager avec vous dans cet article. J'ai pensé écrire que c'est l'une des relations de cause à effet les plus importantes afin d'être un peu moins radicale, mais toujours pas, cette relation de cause à effet est la relation de cause à effet la plus importante dans la programmation par une énorme marge. Il fonctionne comme un fil conducteur dans absolument tous les domaines de la programmation: écrire du code, concevoir une interface, déployer une application, organiser une équipe, maintenir un traqueur de bogues, etc. Et j'appelle cette relation causale sacrée la
minimisation des variables .
Par le terme variable, je veux dire non seulement les variables ordinaires (qui sont déclarées via les mots-clés
var ,
let ,
function ), mais aussi les variables dans un sens plus abstrait du mot: dossiers créés dans l'arborescence du projet, bibliothèques connectées, nombre d'appels ajax au serveur, nombre composants de l'interface, le nombre de protocoles que le programmeur doit suivre lors de la validation du code (par exemple, révision du code, chaque fonctionnalité dans un brunch séparé), etc.
En fait, l'ensemble du processus de programmation est une énumération de variétés dans le sens de la façon de mettre en œuvre telle ou telle fonctionnalité en utilisant le nombre minimum de variables possible (au moins j'examine la programmation dans cette perspective). Le code qui implémente la fonctionnalité avec moins de dépendances / fichiers / lignes de code est meilleur que celui qui implémente la même fonctionnalité avec un grand nombre de variables. Si une classe utilitaire ne contient qu'une seule fonction - vous devez vous débarrasser de cette classe utilitaire, si la fonction se compose d'une seule ligne - vous devez vous débarrasser de cette fonction s'il n'y a que 10 lignes de code dans le composant - vous devez supprimer ce composant s'il n'y a qu'un seul fichier dans le dossier - vous devez vous débarrasser de ce dossier, etc. Et lorsque plusieurs milliers de ces changements apparemment insignifiants sont ajoutés ensemble, le résultat est un code beau, concis et minimaliste qui est très facile à lire. Le diable est dans les détails comme on dit.
Voici une liste d'effets positifs qui apparaissent lorsque vous démarrez la programmation sur la base du principe de minimisation des variables:
- Moins de bugs. Étant donné que moins de code est écrit, le nombre d'emplacements où vous pouvez faire une erreur est réduit en conséquence.
- Il est plus facile de présenter de nouvelles personnes au projet. La complexité du projet est directement proportionnelle au nombre de variables de ce projet, moins il y a de variables, plus il est facile d'introduire de nouvelles personnes.
- Plus facile d'ajouter de nouvelles fonctionnalités. Puisqu'il est nécessaire d'étudier une plus petite quantité de code, il devient plus facile de «charger» la fonctionnalité dans la tête et, par conséquent, d'ajouter de nouvelles fonctionnalités ou de modifier le code existant.
- Prévisibilité. Le processus de programmation devient beaucoup plus prévisible, il devient plus facile pour vous de prévoir combien de temps il faudra pour développer une fonctionnalité ou une autre en raison du fait que le nombre de "gags" est réduit. Généralement, ce sont les bouchons qui causent le plus grand nombre de problèmes et entraînent le retard des délais.
Mais très souvent, la situation inverse se produit, les programmeurs commencent à s'affirmer en introduisant de nouvelles variables. Nous introduisons 20 bibliothèques différentes, des cadres CSS, créons un grand nombre d'abstractions à plusieurs niveaux comme
UserFactoryManager (en particulier les programmeurs Java pèchent pour une raison quelconque), créons trop de répertoires, introduisons des méthodologies de développement plus avancées, ajoutons plus de protocoles avant de valider les fichiers, et ainsi de suite. Et la motivation derrière de telles décisions peut être comprise, car cela crée l'illusion du professionnalisme, disent-ils, regardez ce que je sais et quelles abstractions complexes je peux gérer. Mais souvent, cela nuit terriblement au projet.
Ne vous méprenez pas, je ne suis pas contre l'utilisation de méthodologies, de cadres et de technologies plus avancés, je dis simplement que très souvent, ils sont introduits simplement à cause du battage médiatique, et non pas parce que cette technologie résout un problème urgent dans le projet.
La solution au problème du trop grand nombre de variables peut être appelée
Overengineering . Mais vous devez admettre que si vous décrivez cette situation comme si le problème était résolu par trop de variables, c'est une description beaucoup plus précise de ce phénomène.
Souvent, l'introduction de nouvelles variables est justifiée par l'évolutivité, disent-ils si vous créez
ici un
UserManagerFactory , alors nous pouvons prendre et ajouter une fonction à tout moment si nécessaire. Mais en réalité, l'évolutivité n'est pas lorsque de nombreuses variables sont introduites, mais plutôt quand il y a peu de variables. Pensez à où il vous sera plus facile d'écrire de nouvelles fonctionnalités: dans le moteur de navigateur Chrome ou dans un tout nouveau projet que vous écrivez à partir de zéro?
L'introduction de nouvelles variables n'entraîne pas l'évolutivité de l'architecture. Ce qui améliore vraiment l'évolutivité d'un projet, c'est lorsque vous supprimez des variables inutiles et simplifiez le code existant.
Un grand nombre de variables inutiles - c'est exactement la raison pour laquelle je déteste le langage de programmation Scala avec une haine féroce, et la raison pour laquelle j'aime JavaScript. Scala n'est que la quintessence d'un système de type trop compliqué et très déroutant, de nombreux concepts qui se dupliquent, des conversions implicites, un grand nombre de façons de faire la même chose. Lorsque j'utilise ce langage de programmation, je ne pense pas à
ce qui doit être fait, mais à la
façon de le faire. Je me retrouve très souvent tout à l'heure, mon objectif est juste de fermer le compilateur. En revanche, JavaScript est l'exact opposé de Scala, c'est un ordre de grandeur plus minimaliste, en l'utilisant je dépense beaucoup moins d'effort mental pour exprimer l'un ou l'autre concept. Bien sûr, cette simplicité a aussi ses inconvénients, par exemple, dans Scala, le compilateur signale une erreur au stade de la compilation, tandis qu'en JavaScript, vous ne pouvez reconnaître qu'une erreur lors de l'exécution et il est fondamentalement impossible pour JavaScript d'écrire le même IDE fonctionnel que pour ceux fortement typés. mais ce sont les victimes avec lesquelles je suis prêt à me réconcilier.
Le principe de minimisation des variables doit être appliqué lors de la conception des interfaces, par exemple, comparons les interfaces Web de deux réseaux sociaux concurrents pour sortir avec
Tinder et
Badoo . En fait, il n'y a qu'une seule page dans l'interface Web de Tinder, le profil utilisateur, les discussions actives et la recherche de nouvelles connaissances sont affichés sur une seule page et il n'est pas nécessaire de passer à d'autres pages, dans cette interface tous les besoins des utilisateurs sont satisfaits par un nombre minimum de composants. Alors que sur Badoo, la fonctionnalité de basculement vers le profil utilisateur, l'interface de message et la page de recherche de paires sont implémentées en tant que pages distinctes, l'utilisateur doit effectuer plus d'actions pour répondre aux besoins, et en conséquence, cette interface est moins efficace. Bien sûr, ce n'est qu'un très petit exemple, mais quand il y a des dizaines et des centaines de tels exemples, tous ensemble, ils déterminent si l'interface est pensée ou non.
Lors de la conception de l'interface, il est nécessaire de créer un nombre minimum de composants afin de satisfaire les besoins de l'utilisateur.Pour la même raison, je n'aime absolument pas les approches qui séparent la logique, les données et la présentation, car dans ce cas, une situation se présente dans laquelle écrire un élément de fonctionnalité dont vous avez besoin pour créer trois fichiers, puis le nombre de composants commence à augmenter et lorsque le projet est déjà devenu grand, le nombre de fichiers commence alors à dépasser toutes les limites raisonnables. Par exemple, lors de l'écriture d'interfaces Web, les styles sont généralement décrits dans des fichiers séparés, tandis que les nœuds auxquels ces styles sont attachés se trouvent dans un autre fichier. Aussi étrange que cela puisse paraître, la principale motivation d'une telle séparation est la mise à l'échelle, donc si vous séparez les nœuds eux-mêmes et leurs styles, il deviendra plus facile de naviguer dans le projet, et il sera possible de développer indépendamment ces deux parties de la fonctionnalité. Mais voyons quelles variables sont ajoutées avec cette approche: nouveaux fichiers avec des styles pour chaque composant, sélecteurs (ils décrivent à quel nœud les styles sont attachés), règles de cascade (si plusieurs sélecteurs s'adressent au même nœud). Alors que si vous écrivez des styles directement dans les nœuds auxquels ces styles doivent être connectés (par exemple, via l'attribut style), toutes ces variables supplémentaires ne sont plus nécessaires, ce qui simplifie considérablement le code. Récemment, cette approche est devenue de plus en plus populaire, il existe de nombreuses bibliothèques qui vous permettent d'écrire des styles directement dans l'attribut style.
De nouvelles variables doivent toujours être introduites progressivement dans le projet. Par exemple, au tout début, lors de l'écriture d'un projet, j'ai tous les fichiers dans le répertoire racine, sans aucun sous-répertoire, simplement parce que c'est plus facile, et seulement lorsque le nombre de fichiers atteint 40 à 60 fichiers, certains fichiers sont regroupés dans des répertoires. Au tout début, aucune méthodologie de développement n'est nécessaire, il suffit de jeter tous les programmeurs dans un tas, de leur donner des tâches, puis ils le découvriront eux-mêmes, si la méthodologie de développement est introduite trop tôt, cela ressemblera à une sorte de concept de substitution. Lorsque des variables sont introduites avant qu'elles ne soient nécessaires, cela s'appelle l'optimisation prématurée.
De la même manière, il est nécessaire de minimiser les variables lors de la rédaction de documentation / articles, lorsque j'écris de la documentation, je pense toujours au nombre exact de phrases dont j'ai besoin pour exprimer mes pensées. J'analyse littéralement chaque phrase, et s'il me semble que cette phrase n'est pas nécessaire, elle ne supporte aucune charge sémantique supplémentaire, puis elle est supprimée, en conséquence une page très compressée avec de la documentation est obtenue, qui contient la quantité maximale d'informations nécessaires dans un minimum de texte.
En fait, en général, toute variable a une présomption de culpabilité, aucune variable n'est nécessaire jusqu'à preuve du contraire.
Vous pouvez m'objecter, ils me disent la même chose, ont découvert l'Amérique, elle est connue depuis longtemps et est décrite par des principes tels que:
Rasoir Okama ,
SOLIDE . Mais je préfère appeler ce concept «minimisation des variables», tout simplement parce que cette interprétation est très succincte dans la tête et, en conséquence, il est beaucoup plus facile de s'en tenir à la pratique. Combien d'entre vous peuvent se vanter de se souvenir de chaque point du principe SOLID?
Les débutants écrivent du code simple parce qu'ils ne savent pas écrire du code complexe, les programmeurs moyens écrivent du code complexe, simplement parce qu'ils le peuvent, les professionnels écrivent du code simple parce qu'ils ne veulent pas écrire du code complexe.
Il faut se rappeler que tout extrême est mauvais: s'il est fanatique de minimiser les variables jusqu'au niveau atomique, cette approche, ainsi que l'introduction de trop de variables est un extrême. Et tout extrême, comme vous le savez, est mauvais, la vérité est toujours quelque part entre les deux.