avant-propos
J'ai repris plus d'une fois le module de fonction commerciale complexe, et j'étais toujours immergé dedans au début, et d'innombrables personnes se caressant le cuir chevelu au milieu de la nuit maudissaient dans leur cœur.
Je crois que vous avez vécu une expérience similaire : face à une logique métier complexe, vous devez lire du code pendant deux heures et écrire du code pendant cinq minutes, sans aucun courage ni stratégie .
Je l'ai récemment résumé et revu pour une utilisation ultérieure. S'il y a un collègue qui aime le tromper, vous pouvez pratiquer cette méthode (le succès à 100% n'est pas garanti). Avis personnel, corrigez-moi si je suis inapproprié.
Table des matières
- Trop d'attributs de données
- Trop de paramètres d'entrée pour le composant
- couplage mixins et code métier
- Ne pas envelopper les fonctions pures
- La structure des données est aussi complexe que possible
- N'écrivez pas de commentaires ou n'écrivez pas de commentaires incompréhensibles
- Rendre la logique frontale lourde
- Ne pas encapsuler les mixins et les composants
texte
1. Trop d'attributs de données
Il est nécessaire d'utiliser davantage l'attribut de données et de placer des clés inutilisées pour rendre les attributs plus riches et augmenter le coût de la compréhension.
Il est préférable d'ouvrir les 100 premières lignes de la page avec des attributs de données, afin que le personnel qui maintient ou participe au développement du composant soit impressionné et respecte instantanément le composant.
Cela correspond à ce que la mauvaise odeur de code décrit :
La différence entre un bon médicament et un poison est la dose. Il peut être acceptable d'avoir une petite quantité de données globales, mais plus la quantité est importante, plus elle devient difficile à traiter de manière exponentielle.
Comme le montre l'image, l'effet est meilleur:
2. Trop de paramètres d'entrée pour les composants
Le problème avec l'attribut data est que dans un composant, vous pouvez le comprendre si vous lisez plus et ajoutez des commentaires, et ajouter trop de paramètres props à un composant peut simplement éviter ce problème. Trop de paramètres peuvent rendre la compréhension plus difficile. la valeur liée dans le composant parent est, puis comprenez ce que fait le paramètre d'entrée dans le composant enfant .
Bien sûr, il y a aussi une utilisation de plus haut niveau, qui consiste à rendre la valeur du composant parent incohérente avec le nom des props du composant enfant, ce qui est plus intéressant et la difficulté augmente fortement.
3, mixins et couplage de code métier
L'encapsulation raisonnable des mixins peut rendre le code plus facile à réutiliser et à comprendre, ce qui n'est pas ce que nous voulons. Le couplage des mixins avec le code des composants métier peut avoir pour effet d'obtenir le double du résultat avec la moitié de l'effort.
常规的做法是业务组件调用mixins的方法和变量，我们反其道而行之，让mixins调用组件中的方法和变量，然后让mixins多出引用，虽然看起来像mixins，但是并没有mixins的功能，让后期有心想抽离封装的人也无从下手。
小Tips：常见的mixins方法会加上特殊前缀与组件方法区分，我们可以不使用这个规范，让mixins方法更难被发现。
4、不要封装纯函数
如果有一个很重要的业务组件可读性很差，势必要小步快跑的迭代重构，这种情况也不用怕，我们一个微小的习惯就可以让这件事情变得困难重重，那就是不要封装纯函数方法。
纯函数的好处是不引用其他变量，可以轻易的挪动和替换； 让每个方法尽量引用data属性，当他人想迁移或替换你的方法时，就要先理解引用的属性和全局变量，再进一步，可以在方法里再引入mixnins里的变量和方法，这个小习惯就会让他们望而却步。
5、数据结构尽量复杂
让数据结构变复杂绝对是一个必杀技，数据结构随随便便循环嵌套几层，自己都能绕晕。
再加上一些骚操作，递归遍历加一些判断和删减，写上让人难以琢磨的注释，哪怕是高级工程师或是资深工程师都需要狠狠的磕上一段时间才能摸清真正的业务逻辑是什么。
这种方式还有另外一个优点，就是自己可能也会被绕晕，一起陷入有趣的逻辑梳理游戏。
6、不写注释或写无法理解的注释
如果其他方式都复杂且耗时，那这种方法简直是高效的存在，只需要胡乱的写一些注释让别人看不懂或容易误解的注释，就可轻松把接手代码的同事KO掉。
这个技能也看个人发挥的水平了，你也可以在注释中恐吓、劝阻参与开发人员改动功能代码，煽动开发人员放弃修改，让其内心崩溃。
7、让前端逻辑变重
良好的分层设计能够让系统变得简洁和健壮；为了凸显前端的重要性，应该将逻辑一股脑的承接到前端，让前端逻辑变重，尤其是写一些特殊的编码配置和奇葩规则。
不要和产品、后端讲述这件事情的不合理性，统统塞到前端，当需求被重新讨论时，他们会把特殊逻辑忘的一干二净，而你可以根据代码翻出一大堆，这样你就显得尤为重要了。
8、不封装mixins与组件
如果要让功能变得复杂，就不要拆分UI组件和业务组件，更不要按照业务抽离可复用的mixins方法，让组件尽量大，轻则一两千行，重则五六千行，不设上限，统统塞到一个组件里。
结尾
你有没有遇上过类似的场景，你的感受如何？又是如何解决的呢？欢迎评论，一起讨论。