Devenir programmeur, c'est s'inscrire à une formation permanente. Le flux de nouvelles - nouvelles fonctionnalités, nouveaux langages, nouveaux outils, nouveaux cadres - ne se tarit jamais. Mais en même temps, la programmation est une sphère, étonnamment fidèle aux traditions, où tout repose sur des principes éprouvés par le temps. Nous avons introduit la programmation orientée objet, les solutions matérielles modernes, l'intelligence artificielle, cependant, malgré tous ces changements, bon nombre des axiomes qui ont été formulés dans la génération précédente se révèlent être vrais aujourd'hui.J'ai consacré cet article à quelques-unes de mes déclarations préférées sur la programmation. Le seul critère par lequel j'ai fait la sélection était l'exigence que le devis soit égal à au moins vingt ans. Car ce ne sont que les technologies obsolètes qui deviennent rapidement inutilisables, alors que les anciens commandements de nos programmeurs ancêtres sont restés longtemps d'actualité.1. Indirectité
«Tous les problèmes de programmation sont résolus en créant un niveau supplémentaire d'indirection» - David Willer
Voici une citation du livre Théorie et application de l'informatique, que tout le monde aime répéter et que peu de gens aiment expliquer. Néanmoins, c'est l'une de mes vérités de programmation préférées - elle révèle avec justesse l'essence même de la programmation.Le moyen le plus simple de donner un sens à l'indirection est d'imaginer les couches. Eh bien, par exemple, imaginez que vous avez un petit projet dans lequel vous devez placer le composant A à l'intérieur du composant B:Les deux composants sont standardisés, donc les démonter en composants et changer le principe de fonctionnement ne fonctionneront pas. Vous pouvez créer un composant complémentaire distinct ( PlugTwoProngVariant), mais cela représente à la fois beaucoup de travail et une duplication inutile. Il existe une meilleure solution: ajoutez une couche d'adaptateur entre ces deux composants qui interagit avec succès avec les deux et sert d'intermédiaire entre eux.Avec tout cela, si l'indirection était épuisée par l'ajout de couches supplémentaires entre des composants qui ne seraient pas autrement ancrés, cela serait, bien sûr, utile, mais très limité dans son application. Mais l'idée même de résoudre les problèmes en modifiant l'environnement des zones à problèmes imprègne toute la programmation de haut en bas. Vous le rencontrez lorsque vous essayez d'adapter un nouveau modèle de données à l'ancienne interface. Vous le rencontrez lorsque vous essayez de joindre une application avec un code hérité au backend d'un nouveau service Web. Vous le rencontrez lorsque vous devez ajouter plusieurs nouvelles fonctions de haut niveau comme la journalisation et la mise en cache ou coordonner le travail de plusieurs services de haut niveau comme l'envoi de messages et la réalisation de transactions.Tout en haut de cette pyramide, vous arrivez à des directions raffinées comme l'apprentissage automatique (si vous ne pouvez pas écrire votre propre comportement, ajoutez une autre couche de code qui résoudra ce problème pour vous).Beaucoup vous diront que le but de la programmation est d'écrire des instructions claires dans un langage que même l'ordinateur le plus stupide peut comprendre . Mais la citation de David Wheeler offre un examen plus approfondi de la question. Être un bon programmeur signifie gravir les échelons de l'indirection, en recherchant les solutions les plus courantes.Un devis bonus sur l'indirectité est un outil puissant, mais vous devez payer pour la complexité. Les gens citent rarement la déclaration immédiatement après la célèbre citation:«Cela crée généralement un nouveau problème.» - David Wheeler.
C'est grâce à cette vérité que les programmeurs sont restés longtemps en affaires.2. À propos de la simplicité
«La simplicité est une condition préalable à la fiabilité» - Edsger Dijkstra
Il ne manque pas de programmeurs avisés qui nous mettent en garde contre la complication du code sans besoin urgent. Mais peu ont réussi à montrer si clairement quelle est la complexité pour nous en tant que pionnier de l'informatique, Edsger Dijkstra .C'est le point: vous faites un choix en faveur de la simplicité non seulement par une volonté de rendre l'avenir agréable aux gens. Et pas parce que vous assumez la possibilité de réutiliser ce code à l'avenir. Et non pas parce que vous voulez qu'il examine plus précisément les inspections, et non pas parce que vous voulez faciliter le processus de modification à l'avenir (bien que tout cela, bien sûr, soit un avantage précieux). Vous faites cela parce que la simplicité est une condition préalable. Sans cela, vous n'aurez jamais de code fiable que vous pouvez confier pour gérer une entreprise ou travailler avec des données.Pour prendre la position de Dijkstra, nous devons changer notre compréhension de ce qu'est un «bon code». Ce n'est pas nécessairement le code le plus concis, ni le plus rapide, et certainement pas le plus abstrait. Un bon code est un code sur lequel vous pouvez compter.Une citation bonus sur un sujetL'une des meilleures façons de garder le code simple est de se rappeler que moins c'est plus. Dijkstra propose une nouvelle unité de mesure qui nous le rappellera toujours:«Si nous voulons compter le nombre de lignes de code, nous ne devons pas les percevoir comme écrites, mais comme dépensées» - Edsger Dijkstra
3. À propos de la lisibilité et de la réécriture
«Le code est plus difficile à lire qu'à écrire» - Joel Spolsky
À première vue, cette citation de Joel Spolsky , légende de la programmation et co-fondateur de Stack Overflow, semble raisonnable, mais trompeusement superficielle. Oui, les fragments de code sont riches en informations, trop compressés ou fastidieusement longs. Et cela ne s'applique pas seulement à ce que les autres ont écrit. Si vous regardez votre propre travail de l'année dernière, vous aurez besoin de temps pour recréer la logique que vous connaissiez autrefois de et vers.Mais l'observation de Spolsky se déroule dans quelque chose d'intéressant. Le danger d'un code difficile à lire n'est pas seulement les conséquences les plus évidentes (il est difficile de le corriger et de l'améliorer). Il existe un autre grand danger: le code difficile à lire semble pire qu'il ne l'est réellement. En fait, comprendre le code de quelqu'un d'autre peut sembler une tâche si écrasante que vous serez tenté de faire ce que Spolsky appelle la plus grossière de toutes les erreurs : tout réécrire.Je ne dis pas que l'architecture système ne bénéficie jamais de telles réécritures. Bien sûr, il arrive que ça gagne. Mais une telle amélioration coûte cher. Dans tout ce qui concerne le test et la correction des bugs - et ce sont deux éléments de développement qui prennent plus de temps que d'écrire le code lui-même - vous revenez à la position de départ. La réécriture semble tentante car elle s'inscrit dans l'une des idées fausses les plus courantes des développeurs - la tendance à sous-estimer les coûts de main-d'œuvre des choses conceptuellement simples. C'est pourquoi 50% du temps est consacré aux 5% finaux du projet. Les tâches élémentaires peuvent être étonnamment longues! Et la solution à un problème qui a déjà été résolu dans le passé semble toujours simple.Eh bien, si vous réécrivez tout à partir de zéro pour perfectionner le code, cela ne devrait pas, alors quelles sont les alternatives les plus efficaces? Réponse: impliquer chaque développeur dans le processus de refactorisation fragmentée continue . Ainsi, votre code est constamment amélioré, en raison d'une chaîne de petits changements - un réel avantage avec un minimum de risques. La lisibilité peut être améliorée en cours de route.Citation supplémentaire au sujetSi vous doutez encore de l'importance de la lisibilité, Martin Fowler vous aidera à regarder le problème plus largement:«Tout imbécile peut écrire du code que les ordinateurs peuvent comprendre. Les bons programmeurs écrivent du code que les gens peuvent comprendre. »- Martin Fowler
En d'autres termes, la tâche du programmeur est d'émettre non seulement du code de travail, mais du code avec une logique interne.4. À propos des répétitions
«Ne répétez pas. Chaque élément de connaissance doit avoir une représentation unique, sans ambiguïté et fiable dans le système »- Andy Hunt et David Thomas
Chaque programmeur qui se respecte sait que de nombreux problèmes résident dans la répétition. Si vous écrivez la même chose à plusieurs endroits, vous devez consacrer plus d'efforts à tester et à corriger les bogues. Pire, vous créez les conditions des écarts; par exemple, un morceau de code peut être mis à jour ultérieurement et d'autres procédures connexes peuvent ne pas être mises en conformité. Un programme différent est un programme auquel on ne peut pas faire confiance et un programme auquel on ne peut pas faire confiance ne peut pas être considéré comme une solution viable.Ce bogue pourrait être évité avec la méthodeGetTeamUniform(), mais les répétitions font des ravages non seulement dans le code. Cette version du principe bien connu DRY (Don’t Repeat Yourself) interprète largement le principe de l’élimination des doublons, couvrant d’autres endroits où les répétitions peuvent se faire. Maintenant, la conversation ne concerne plus les doublons dans le code - nous parlons également de répétitions dans tout le système. Et les systèmes codent les connaissances dans différents formats. En particulier, ce sont:- Les opérateurs
- Commentaires sur le code
- Documentation pour développeurs ou clients
- Schémas de données (par exemple, tables de base de données)
- Autres spécifications - plans de test, documents d'organisation des processus, règles d'assemblage
Tous ces groupes peuvent se chevaucher dans le contenu. Et lorsque cela se produit, il y a un risque qu'ils commencent à diffuser différentes versions d'une même réalité. Disons que faire si la documentation décrit un modèle de travail et que l'application elle-même en suit un autre? Dans ce cas, qu'est-ce qui est considéré comme le détenteur de la vérité? Mais que faire si les tables de la base de données ne correspondent pas au modèle de données du code? Ou si les commentaires du code décrivent une opération ou un algorithme fondamentalement différent de l'implémentation réelle? Chaque système a besoin d'une représentation unique et fiable sur laquelle tout le reste repose.Soit dit en passant, il ne faut pas penser que les conflits entre les candidats à la vérité ne se produisent que dans de petits projets ou sont le résultat d'un code de mauvaise qualité. L'un des meilleurs exemples qui a éclaté à la vue est la bataille entre XHTML et HTML5. Un côté a affirmé que les spécifications - il s'agit de la version officielle correcte, et les navigateurs devraient s'y adapter. Un autre camp a objecté que c'était le comportement des navigateurs qui devait être considéré comme la norme de facto - après tout, c'est ainsi que les concepteurs imaginaient tout lorsqu'ils écrivaient des pages Web. En fin de compte, la version de vérité promue par les navigateurs a gagné . Depuis lors, HTML5 est ce que les navigateurs font vraiment, y compris les raccourcis valides et les erreurs.Citation bonus dans le sujet.La possibilité que le code et ses commentaires entrent en conflit les uns avec les autres a généré des discussions animées: qu'y a-t-il de plus à tirer des avantages ou des inconvénients des commentaires? Les partisans de la programmation extrême les traitent avec une méfiance pure et simple.«Le code ne ment jamais, mais cela arrive avec des commentaires» - Ron Jeffries
5. À propos de problèmes complexes
«En informatique, il n'y a que deux problèmes complexes - invalider le cache et trouver des noms» - Phil Carleton
En apparence, cette citation semble être juste une blague de programmeur, drôle, mais ne se démarquant pas des autres. Tout le monde peut sentir le contraste entre quelque chose qui ressemble à une tâche intimidante (invalider un cache) et quelque chose qui ressemble à un vrai non-sens (inventer des noms). Tout programmeur a au moins une fois tué des heures entières pour un problème ridiculement petit - deux paramètres, mis dans le mauvais ordre, une variable qui se trouve quelque part avec une majuscule et quelque part pas (merci, JavaScript!). Alors que les gens doivent travailler avec des ordinateurs pour atteindre leurs objectifs, la programmation sera toujours un mélange de planification système de haut niveau et de fautes de frappe stupides.Mais si nous regardons de plus près les paroles de Phil Cardboard, nous trouverons ici plus de place pour la réflexion. Il est difficile de trouver des noms, pas seulement à cause des petits maux de tête du programmeur, la vie continue sur des talons. Le point ici est que les noms sont l'une des facettes de la tâche principale du programmeur, la conception du programme. En d'autres termes, comment un code clair, net et cohérent est-il généralement écrit?Il existe de nombreuses variétés de mauvais noms. Nous avons tous rencontré des variables nommées d'après des types de données ( myString, obj), des abréviations ( pcc.-à-d. Catalogue de produits), certains détails d'implémentation insignifiants ( swappable_name, formUserInput), ou même laissés sans nom ( ret_value,tempArray) Il est facile de tomber dans un piège et de nommer une variable en fonction de ce que vous en faites maintenant, et non de son contenu. Et avec les valeurs des types de données logiques, le problème est: qu'est-ce que cela signifie progress- que la progression a déjà commencé, que vous devez afficher des informations sur la progression dans l'interface, ou autre chose en général?Source: CommitStrip.comTransfert«results_tmp_2? ?.. , ? !» — «, … , results_tmp_2. »
Mais les noms de variables ne sont qu'un début. Lorsque vous commencez à trouver des noms pour les classes, la question se pose de savoir comment diviser le code en parties indépendantes. Les noms des membres du public déterminent quelle sera la présentation de l'interface à travers laquelle les différentes parties de l'application interagiront entre elles. En attribuant un nom à un morceau de code, vous ne décrivez pas seulement ce qu'il peut faire - vous définissez ce qu'il fera.Citation bonus dans le sujet.« – , » —