Il y a 3 problèmes de code que vous rencontrez dans la programmation: Hardcode, Govnokod et Schizokod.
Parlons-en.
Hardcode
Il s'agit d'un problème bien connu lorsqu'un programmeur, en raison de précipitation ou de paresse, écrit du code sans tenir compte des variables. Le cas le plus courant est peut-être le domaine du site. Elle peut varier d'un environnement à l'autre et cause souvent beaucoup de problèmes. Ici, tout est simple. Dans différentes plates-formes, cela est résolu de différentes manières. L'essentiel est de se conformer aux accords et règles adoptés au sein de la plateforme.
En règle générale, les problèmes de cette classe sont rapidement détectés et facilement traités.
Govnokod
C'est un problème plus difficile. Souvent subjectif. En gros, il s'agit d'une violation du style de code adopté par le chef, l'équipe ou la communauté.
Il existe différents styles de code selon la plateforme et même parfois à l'intérieur de la plateforme:
C'est du monde php. Dans d'autres communautés, la situation est similaire. Cela comprend également des histoires sur l'onglet, l'onglet après 2 espaces ou l'onglet après 4 espaces, etc.
Ici se pose le problème du code pur ... par exemple, les fonctions longues de 3-4 pages, ce qui est critiqué. Ce n'est pas toujours certainement mauvais, mais il est souvent possible de raccourcir ces fonctions, de les diviser en une série de fonctions courtes, chacune résolvant son propre problème.
En règle générale, ces problèmes sont facilement traités par le logiciel et le contrôle des normes acceptées dans une équipe spécifique.
Voltige aérienne, lorsqu'un développeur peut basculer entre différents styles de code en fonction du projet.
C'est mauvais lorsque le développeur viole le style de code adopté par l'équipe ou considère que son style de code préféré (souvent le seul appris) est le seul correct.
Il n'y a pas de bons styles de code. Il existe des styles approuvés dans l'équipe ou des styles généralement acceptés.
Également un problème relativement simple et facilement résolu.
Schizocode
C'est un problème moins courant, mais souvent le plus cher.
Schizocode - vient du concept de schizophrénie. Squeeze de Wikipedia:
Schizophrénie (d'un autre grec: σχίζω "split", "split" + φρήν - "mental, thinking, pensée"), précédemment lat. la démence praecox («démence prématurée») ou la schizophrénie est un trouble mental polymorphe endogène ou un groupe de troubles mentaux associés à la rupture des processus de pensée et des réactions émotionnelles.
Il y a 2 points importants: le fractionnement et la démence. Quelles sont les causes du schizocode.
Un code idéal est celui qui n'est pas écrit. Les schizocodeurs ne connaissent pas ce concept.
En bref, le schizocode est un code qui viole le principe d'Occam Razor.
Squeeze de Wikipedia:
Le «rasoir d'Occam (lame)» est un principe méthodologique, nommé d'après le moine anglais franciscain, philosophe nominal William Ockham. Dans une forme simplifiée, il se lit: "Vous ne devriez pas multiplier l'existant sans besoin"
Cela s'exprime dans le fait que les développeurs commencent à compliquer le code et l'architecture sans raison valable. Ou le poids des raisons n'existe que dans leur imagination.
Problèmes imaginaires - la racine des mauvais logiciels
Il y a 2 symptômes principaux: l'invention des vélos sur béquilles et la multiplication des couches d'abstraction.
L'invention des vélos sur des béquilles
Il est exprimé que les développeurs, compte tenu de la faible capacité d'apprentissage, au lieu de rechercher des solutions / méthodes optimales dans le cadre de la plate-forme et de l'architecture existante, commencent à inventer des vélos / béquilles.
Exemples:
- Écrire vos propres frameworks CMS / ptm que ceux existants ont une faille fatale
- Blog Symfony Malgré le fait que le monde entier utilise WordPress pour cela.
- Boutiques en ligne sur Laravel, malgré le fait qu'il existe WooCommerce (n ° 1 mondial), Magento (également bon), 1C-Bitrix (au pire, meilleur que Laravel)
- J'ai rencontré une situation lorsque la mise en page était sur Bootstrap, mais le développeur a décidé d'écrire ses propres styles pour les étiquettes. Qu'est-ce qui vous a empêché d'ajouter la classe d'étiquettes que Bootstrap possède déjà?
- Les fonctions, méthodes et classes redondantes n'ont pas de calcul qui pourrait être évité en utilisant des bibliothèques et des méthodes prêtes à l'emploi dans les plates-formes utilisées
Propagation incontrôlée de couches d'abstraction: classes supplémentaires, héritage, méthodes
Le lecteur attentif pouvait remarquer un conflit avec le govnokod. Dans un cas, le problème est que la fonction ou la classe est trop longue, mais le problème est qu'au contraire il y a une fragmentation excessive des entités.
Il convient de noter ici qu'il s'agit d'un des extrêmes, dont la frontière n'est pas toujours facile à observer.
D'une part, il est mauvais d'essayer de tout résoudre avec une seule fonction sur 3 pages ou une classe qui contient du HTML et des mécanismes de modèle et quelque part, il est plus rentable de diviser le code en plusieurs fonctions / classes / composants, chacune résolvant son propre problème. C'est un extrême.
D'un autre côté, un code mal simple est divisé en 5 classes, chacune ayant 3-4 méthodes de 3-4 lignes, avec de nombreux héritages inutiles, quand vous pouvez en faire une ou deux avec un héritage minimal ou même sans héritage si cela peut être évité.
Les conséquences des abstractions superflues et mauvaises
Propagation des méthodes, des classes, de l'héritage sans raison valable - c'est du code superflu et la croissance de couches d'abstraction.
Tout a un prix, ainsi que des abstractions supplémentaires:
- nouvelle formation développeur choyée
- plus il y a de code, plus il y a de points de défaillance, plus il y a d'erreurs
- les diagnostics et le débogage de code sont compliqués
Problème de pensée
Plus il y a de couches d'abstraction, d'héritage, de méthodes, plus il faut de carburant réfléchi pour les changements, les améliorations et le diagnostic des problèmes.
Et le volume de travail du combustible est limité et souvent sa pénurie entraîne des coûts de développement très importants.
Chaque développeur qui a fait le diagnostic et changé le schizocode s'est reposé sur une pénurie de carburant de pensée. Mais tout le monde n'en était pas conscient.
Une vidéo qui explique ce que pense le carburant et donne un exercice simple pendant 1 minute, qui vous permet de rappeler la sensation de pénurie de carburant sur un exemple simple:
Fonctionne-t-il dans la POO, les classes et l'héritage?
Pas du tout. Cependant, il y a une part de vérité à cela. Dans un style fonctionnel, c'est plus facile de novokovodit, mais schizokod c'est difficile là-bas. La POO, d'une part, offre de nombreux avantages, mais ouvre également la possibilité d'un schizocode.
La POO, les classes et l'héritage ne sont ni mauvais ni bons. Ce sont les outils. Je les utilise personnellement.
Cependant, j'ai un certain nombre de mes propres règles:
- J'écris presque toujours des classes à cause de l'encapsulation, mais j'ai souvent assez de singleton, de méthodes statiques et d'apatrides
- Là où il y a une méthode couramment utilisée, j'écris des fonctions qui ne sont souvent que des wrappers pour les méthodes d'une classe, mais parfois une fonction est juste une fonction sans classe et c'est bon le cas échéant.
- Cours avec état - oui, mais moins souvent et encore seulement là où il y a de bonnes raisons
- L'héritage est encore plus rare, et seulement là où il y a de bonnes raisons à cela (j'essaie de réduire les couches d'abstraction et d'économiser la pensée et le carburant dans une équipe)
Résumé
Nous parlons beaucoup de hardcode et de govnokode car ils sont compréhensibles et facilement tangibles. Mais le schizocode reste souvent impuni, car il est plus difficile d'identifier et de comprendre l'ampleur des dommages qui en découlent. Et la quantité de mal qui en découle est peut-être plus que ce que l'on peut imaginer en un clin d'œil.
Mon manifeste est simple:
- il est préférable d'apprendre le principe du meilleur de la race avant d'inventer un autre vélo à béquille dont personne n'a besoin
- écrivons moins de schizocode
- Apprenons à nous conformer au principe d'Occam Razor et à ne pas compliquer le code sans raison
- sauvons nos pensées et notre équipe
Eh bien, je serai heureux de commenter à la fois le manifeste et ses critiques.