Il est arrivé que la plupart de ma vie consciente, je programme en PHP. Notre cerveau, percevant des informations provenant de n'importe quelle source, le fait sans interruption de l'autorité de cette source. En gros, si vous aimez PHP - vous avez automatiquement ajouté des points de crédibilité à l'auteur de cet article, et si vous n'aimez pas - ils les ont automatiquement supprimés. Ce processus se déroule à un niveau inconscient et est essentiellement un prisme de perception qui, d'une part, nous protège de tomber dans une analyse sans fin d'informations de tout degré d'autorité, mais d'autre part nous limite dans la recherche d'informations nouvelles et plus pertinentes. Le pire, c'est que la crédibilité de la source est rarement vérifiée à un niveau conscient (car cela prend du temps et des ressources sous forme de calories précieuses), je peux être avec la même probabilité un développeur plus, une ménagère-cuisinière, un plombier sans princesse, ou génétiquement modifié chat. Ne jugez pas mon article strictement, j'ai des pattes.
La même chose s'applique à la lecture du code de quelqu'un d'autre: si son auteur se trouve à la gauche de votre trône, travaille dans votre entreprise depuis plus de 10 ans et gagne un zéro de plus que vous, ce n'est absolument pas la même chose que l'auteur qui a été licencié pour quelque chose - c'est mauvais, et vous avez été embauché à sa place. Mais en fait, le code ici et là n'est qu'un ensemble d'octets qu'il serait utile d'évaluer sans référence à l'autorité de la source.
Lorsque nous lisons le code de quelqu'un d'autre, une grande variété d'émotions peuvent nous rendre visite: admiration, rire, irritation, déception, rejet complet. Il est utile de savoir que la manifestation de toute émotion dans n'importe quel contexte est une réponse automatique du (premier) niveau inférieur du système nerveux, formée de manière évolutive, nécessaire dans un environnement primitif. La tâche principale d'une telle réponse, dans le cas d'une émotion «négative», est de lancer le mécanisme d'action «hit or run» avec un seul objectif - survivre. Dans notre environnement de bureau actuel, lors de l'analyse du code de quelqu'un d'autre, une telle réponse devient plutôt inutile et même nuisible, car vous y consacrez un temps et des ressources précieux, et vous polluez votre cerveau avec des neurotransmetteurs qui diminuent votre esprit rapide au nom de la vitesse de réaction. La bonne nouvelle est que cette réponse peut être reprogrammée. Vous pouvez supprimer les réactions émotionnelles négatives ou les inventorier, par exemple, rire là où vous étiez en colère. Le rire, contrairement à la colère, jette dans le cerveau des neurotransmetteurs bons, savoureux et utiles qui donnent du plaisir, renforcent l'expérience et vous motivent à continuer à travailler.
Afin de reprogrammer l'émotion, vous devez mentalement entrer dans une méta-position afin d'évaluer votre propre situation et de vous évaluer au lieu de condamner le code de quelqu'un d'autre. Pourquoi ce morceau de code de quelqu'un d'autre me dégoûte? Est-ce vraiment l'amateur qui l'a écrit, et maintenant je dois souffrir si bien et si expérimenté? Si je suis si bon et si expérimenté, alors pourquoi ai-je des problèmes pour comprendre le code de quelqu'un d'autre et le réécrire comme bon me semble? Peut-être que je n'ai tout simplement pas assez de RAM pour réaliser cette nouille? Peut-être que l'auteur de cette pièce sait quelque chose que je ne sais pas?
Les outils de développement modernes vous permettent de transformer le code de quelqu'un d'autre en structures plus compréhensibles et agréables presque à la volée. Une fonction ou une variable est mal nommée - ctrl + shift + R et en quelques secondes, elle est appelée pour de bon. Des tabulations au lieu d'espaces, de manière peu pratique, des retraits inhabituellement dispersés et des accolades ouvrantes dans le style égyptien - ctrl + shift + F et formatage restaurés! Le commentaire est redondant ou obsolète - ctrl + D et il ne l'est pas. Si vous changez le prisme de la perception, la lecture du code de quelqu'un d'autre peut se transformer en un amusant jeu de détective interactif.
Le code n'est qu'un outil. Peu importe à quel point il a été mal et terriblement écrit, à un moment précis et dans un endroit particulier, il a réussi à résoudre un problème spécifique, ce qui signifie qu'il est déjà «justifié». Quelque chose a changé dans les exigences de l'entreprise, quelque chose n'a pas été pris en compte - le code est cassé ou obsolète, et c'est normal. Le code a la capacité d'évoluer de différentes manières: et progressivement, envahi par des couches et révolutionnaire, écrit à partir de zéro. Bien sûr, c’est bien lorsque le programmeur prévoit l’avenir et que dans les étapes initiales il y a dans le code les possibilités de son développement ultérieur. Mais cette hache est tranchante des deux côtés, vous pouvez vous tromper en prédisant l'avenir, l'avenir peut ne pas venir du tout, et le temps et les ressources seront irrémédiablement perdus. Il est important de comprendre le code dans quelle mesure la qualité est exigée de vous. S'il s'agit d'un énorme système distribué, dont les modules sont programmés par vos collègues du monde entier dans des entreprises faiblement connectées au vôtre, alors oui, il est logique d'utiliser des modèles à la mode, d'envelopper les modules dans des conteneurs de service même lorsque vous ne pouvez pas imaginer pourquoi c'est besoin de. Mais s'il s'agit d'un petit CRM local pour une entreprise, dont les modules dépendent si rigidement les uns des autres que la désactivation de n'importe quel module empêche essentiellement le système entier de fonctionner ... dans ce cas, il est justifié d'appeler directement les méthodes d'autres personnes, cela réduira le nombre de classes et facilitera votre fonctionnement. mémoire et réduire le temps de débogage des problèmes. Mais ici, une situation se présente lorsqu'un petit CRM local se transforme en quelque chose d'extensible que votre entreprise veut mettre dans le domaine public et vendre. Les exigences commerciales ont changé. Faut-il blâmer le programmeur de ne pas l'avoir prévu?
Normalisation
Le code n'est qu'un outil, mais sa création est pure créativité. Tout problème peut être résolu par un nombre infini de façons les plus diverses. Certains d'entre eux sont plus productifs que d'autres - un exemple d'évaluation objective. Certains d'entre eux sont plus lisibles que d'autres - un exemple d'évaluation subjective. Même si vous convainquez l'ensemble du bureau qu'un morceau de code n'est pas lisible, il y aura toujours au moins un auteur en désaccord avec vous. La normalisation du code vise à transformer la créativité pure en un ensemble d'actions le plus routinier afin qu'il soit plus facile pour les autres programmeurs de comprendre votre code. C'est, en fait, pour que vous puissiez être remplacé par un autre spécialiste, plus docile et moins cher. Et après quelques décennies, c'est une intelligence complètement artificielle. Il convient de rappeler que si une norme est contraire au bon sens, il peut être judicieux de la violer à certains endroits, voire de l'abandonner complètement ou de la remplacer par une autre, plus appropriée.
Les normes matures se vendent de la position «lors du choix d'une norme, faites attention à la popularité de la communauté». Je me demande comment ils se sont vendus quand ils viennent de sortir. L'idée principale est que la popularité d'une norme particulière n'est pas un facteur que vous souhaitez tout d'abord prendre en compte lors du choix. La popularité et les communautés sont très inertes et peuvent pendant de nombreuses décennies rejeter de nouvelles normes meilleures. Surtout s'ils sont révolutionnaires.
Une attention particulière est accordée aux normes qui se sont profondément établies dans la culture simplement parce qu'elles sont nées plus tôt que d'autres normes similaires. Un exemple canonique est la guerre sainte entre les dispositions de QUERTY et de Dvorak. Le second, évidemment, est meilleur, mais le premier tient un coup (reste plus populaire) simplement en raison de la masse critique d'utilisateurs qui ne veulent pas se recycler sur un nouveau.
Des exemples similaires se trouvent tout au long et dans la culture de la programmation. La norme PSR représente 4 espaces au lieu d'onglets, ignorant le fait évident: l'environnement de développement de la plupart des programmeurs PHP est passé d'éditeurs de console à des IDE à part entière, dans lesquels la tabulation est plus pratique à bien des égards: il est plus facile de le supprimer en appuyant une fois sur Retour arrière, et vous pouvez configurer des longueurs individuelles Onglets au goût.
Lorsque vous appliquez telle ou telle norme, posez la question: à qui la rendez-vous plus pratique? Qui est le plus mal à l'aise? Qui bénéficiera de la règle "nommez les noms des méthodes du lowerKamelKeysom"? Évidemment seulement à ceux qui ont l'habitude de les appeler ainsi. Tous les autres deviendront mal à l'aise, ils devront s'adapter, et cette perte de temps et de ressources est absolument à partir de zéro, étant donné que
a) nous avons maintenant des IDE magiques qui mettent en évidence différents éléments du code dans différentes couleurs,
b) les programmeurs ont la capacité de passer d'un projet à l'autre, les normes de codage pouvant varier.
Personnellement, lors du développement de mes projets, j'utilise:
- CamelCase pour nommer les classes et les méthodes
- $ CamelCase pour nommer les variables contenant une instance d'un objet
- $ snake_case pour nommer des variables contenant des types simples
Je n'ai aucun problème à distinguer un nom de classe d'un nom de méthode puisque le premier est un nom et le second est un verbe. De plus, le rétro-éclairage aide. Mais c'est mon goût personnel, je ne l'impose à personne. Il s'agit d'un prisme personnel de perception, il est individuel pour chaque tête individuelle. Quelqu'un a eu la «chance» de plonger immédiatement dans la norme populaire, quelqu'un n'a pas eu la chance de commencer sa carrière avec des alternatives et quelqu'un a généralement développé la sienne. Je vous amène au fait qu'au lieu de recycler les autres, il peut être judicieux de vous recycler pour percevoir le code dans toutes les normes. Ou même au-delà des normes.
Bien sûr, les adeptes de la normalisation dans ce lieu seront scandalisés et me jettent de nombreuses raisons contre. Cet article n'est pas pour eux, je l'écris pour ceux qui sont intéressés à comprendre l'essence des choses, à essayer d'imaginer ce que l'auteur avait vraiment en tête et quel but il poursuivait.
Capacité à comprendre le code de quelqu'un d'autre
Le déclencheur qui provoque les pulsions de vomissement dans la grande majorité des programmeurs (un exemple d'évaluation subjective). Il ne vous a jamais semblé étrange qu'il soit souvent plus facile pour nous de réécrire tout le code à partir de zéro que de comprendre celui de quelqu'un d'autre? Dans toute autre industrie, nous agissons différemment: nous apprenons d'abord à lire, puis à écrire; la première utilisation (appareils électriques, bâtiments), puis les concevoir. Il me semble que l'essentiel est dans notre éducation (en particulier dans le domaine de la programmation). On nous apprend à atteindre l'objectif de la manière la plus directe et la plus rapide, en utilisant des connaissances fraîchement acquises. En conséquence, nous les combinons (connaissances) exactement jusqu'à ce que «ça marche», testons un peu et envoyons-le au professeur pour modération. À mon avis, il serait bon d'ajouter une étape supplémentaire à ce processus, dans laquelle nous comparons notre code avec le code maître, qui bien qu'il ne soit pas idéal et le seul bon, mais fournit une solution alternative, souvent plus optimale et lisible.
Quant au déclencheur, pour le désactiver, il suffit juste de se mettre mentalement à la place du client, qui a regardé les programmeurs à venir toute sa vie, affirmant que le travail de leurs prédécesseurs est des excréments et que vous devez tout réécrire pour le rendre bon. Le client n'a pas la compétence pour savoir si vous dites la vérité ou si vous êtes simplement paresseux pour comprendre le code de quelqu'un d'autre. Pour gagner sa confiance dans une telle affaire, vous devez vous plonger dans le code de quelqu'un d'autre et trouver quelques failles de sécurité géantes et les démontrer au client. Mais même dans cette situation, du point de vue des affaires, il peut être plus rentable de «durcir». Surtout s'il s'agit d'une externalisation avec des délais et de l'argent spécifiques. Faut-il blâmer le programmeur pour cela?
Conclusion
Wha, shcha écrivez avec la lettre I. Au lieu du petit déjeuner, buvez du café et du beurre dans un mélangeur.
Regardez plus loin, pensez plus loin, cherchez des alternatives. N'arrêtez jamais de vous développer.