关于javascript:精读可维护性思考

PS: 所有没给原文链接的精读都是原创，本篇也是原创。

前端精读之前写了 23 篇设计模式总结文，再加上 6 种设计准则，开闭、繁多职责、依赖倒置、接口拆散、迪米特法令、里氏替换准则，基本上对代码的可维护性有了全面粗浅的了解。

但你我在工作中都会一直遇到烂代码，快要无奈保护的大型项目，想一想，仅凭设计模式就能解决这些问题吗？为什么一直收缩的大型项目总是变得越来越难以保护，而复杂度更高的真实世界，但没有人感觉快要崩塌了呢？

设计模式思考的是代码之间的关系，设计准则思考的是模块以及我的项目间的关系，那是否存在更下层的思考，解决大型项目越来越难保护的问题？

精读

先考虑一下，为什么真实世界没有可维护性问题？

真实世界为什么没有可保护问题

这个问题看起来有点傻，因为素来没有人会收回这样的埋怨“咱们的产品、科技、概念太多了，多到我感觉无奈在这个世界活下去了”。然而在代码世界，程序员常常会埋怨，我的项目的概念太多、设计过于简单，以至于他无奈持续再保护上来了，是时候寻找下一份工作了。

一种不言而喻的解释是，生存中，咱们都是小角色，活在本人的天空下并不需要涉及那么多概念，而程序员在我的项目中根本表演了上帝的角色，必须为每一个细节操心。

但这并不齐全解释得通。咱们认为本人接触的货色不多，但实际上日常生活的常识太多了，就拿家电来说，每个人都会同时接触几十种家电，大到空调冰箱洗衣机，小到手机牙刷充电器，即使这些产品被大量标准化，但每个产品用起来都有大量细节的区别，但没有一个人感觉学习应用一个新剃须刀是一种累赘，也并不感觉一款设计得不好的牙刷，会对整个牙刷行业造成怎么负面的冲击。

这背地的起因是：拷贝。正因为咱们用的每一件货色都是拷贝，所以即应用坏了也不会对其它雷同物品产生任何影响。但代码世界则不同，因为代码调用关系的存在，复用的越优雅，破坏力也就越大。一栋大楼断了几块钢筋尚可撑持，但换在代码世界，只有断了一块钢筋，就意味着这栋大楼所有钢筋都断了。这就是程序员最痛恨的问题之一，就是为什么改了一处看似人畜有害的代码，却导致一场故障。

从这个角度来说，代码世界是无奈汲取真实世界教训的。而且代码世界的这种副作用，在商业上是有微小正向价值的，即软件的边际老本简直为零，这是实体产品做不到的，因而软件须要付出可维护性代价，仿佛是这种极低边际老本的代价。

尽管通过借鉴真实世界的教训，使本人保护老本变成零时不可能的，但真实世界对软件世界的确有可借鉴之处，上面咱们就来探讨几个有意思的点。

真实世界一直屏蔽复杂度

不晓得你会不会有过这样的思考：面试官总是问原理，就是放心我只会用框架，而不足根底。但根底是什么呢？懂得 js，java 算是根底吗？也能够说不算，因为这些语言背地的编译原理如同才是根底，编译原理背地还有操作系统，操作系统运行在硬件上，而硬件的原理呢？从 CPU 设计到背地的硅是如何制作的，等等，这样上来，仿佛永远也无奈把握原理。

但当咱们从软件推导到硬件时，能够很天然的发现，没有人感觉把握硅胶的制作过程是一件必须的事，咱们能够始终应用硅胶制作的产品，但却能够不必理解硅胶制作的原理。

真实世界总是一直屏蔽复杂度，作为消费者时，咱们面对的商品总是通过精心包装，简略易用的，只有咱们工作时，才须要对某个业余畛域的原理有所理解。

这个情理能够迁徙到代码世界，即对于一个宏大而简单的我的项目，不能指望每位开发者都理解全副原理后能力工作，咱们须要在大多数时候把开发者当作消费者来对待，提供精美而稳固的接口。要做到这一点，须要一个相似下图的架构设计：

<img width=400 src=”https://z3.ax1x.com/2021/10/08/5PTFBR.png”>

从图中能够看出，即使是业务层代码，我也不须要关怀过于底层的实现，底层的代码就像脚下被压实了的土地，只须要在下面走就行了。

然而最让人解体的是上面的设计：

<img width=400 src=”https://z3.ax1x.com/2021/10/08/5P7Fxg.png”>

为了解决一个问题，须要面对无穷无尽的上下文，这就是保护老本高的最次要起因。

为什么感觉保护老本高

作为开发者，曾经习惯了评估代码保护老本高还是低，明天咱们换个视角，想一想为什么你会感觉保护老本高？

对保护老本的感触不齐全是主观的，我画了一个四象限图：

<img width=300 src=”https://z3.ax1x.com/2021/10/09/5iGjZ6.png”>

右边是和人相干局部，包含你对代码的理解能力，以及对我的项目的相熟度。

理解能力越强，越不容易感觉保护老本高；对我的项目越相熟，哪怕是屎山代码，也会感觉重构后可维护性并不会进步，因为本人对我的项目会变得不相熟。

左边是和我的项目相干局部，包含业务自身的复杂度，以及这背地的技术形象实现的品质。

业务自身越简单，保护老本就会越高，因为信息量不可避免的增大了，咱们永远不能只盯着 Hello World 的 Demo 钻研框架；代码品质体现了技术对业务的形象，形象的好，复杂度曲线就会比拟贴合业务实在复杂度，形象的不好，Hello World Demo 也可能新人进来喝一壶。

在这四个关键词中，业务复杂度是简直无奈扭转的，对我的项目相熟也须要一个过程，所以重点应该放在理解能力与代码品质两局部。

无论是集体理解能力，还是代码品质，指标都是帮忙咱们疾速了解我的项目，也就是说，只有能疾速了解技术我的项目在做什么，我如何疾速融入，就会感觉可维护性高，反之则感觉不好保护。

所以一个简略的我的项目，或者一个分层正当，文档清晰的大型项目都会让人感觉可维护性好。在这一点上，须要向真实世界学习的教训就是，即使在软件世界，也并不是理解所有原理，所有犄角旮旯的逻辑才表明技高一筹，带着这种思维工作只会让大家陷入无尽的内卷和了解焦虑。咱们要给大家思维减负，不须要了解的模块、代码设计，就不要轻易展现进去，将每个模块开发所需理解的最小常识设定好，最大水平缩小开发者的了解累赘。

当然要补充一句，这并不意味着局限开发者的成长和学习空间，其它常识随时敞开大门，只是了解它们并不是日常开发所必要的，这些常识造成文档能够用完即弃，不必成为长期记忆。说到这，就引出了真实世界第二个乏味的中央，就是说明书。

真实世界的说明书

我回头想想也挺不堪设想的，无论快递买来任何须要组装的货色，依照说明书的指引最终都能够组装好，而且装好之后就能够把说明书扔了，齐全没有认知累赘。

与其说快递包裹的说明书太欠缺了，不如说阐明不欠缺，不好用的商品基本卖不出去。咱们早已习惯极度易用的商品，及其详尽的说明书了，这是商业社会继续倒退，长期博弈后的后果，而且会稳固继续上来。试想一下，如果咱们参加保护的我的项目也有精美的设计，欠缺的文档，那保护就不是什么问题，依照文档说的一步步来就行了。

那为什么大部分状况，咱们接手的我的项目就像一个没有说明书的乐高呢？这应该是商品与代码的本质区别了，即商品质量好不好，是由买家用钞票投票的，做得好用，说明书欠缺的商品能力存活下来，但这背地的技术实现是看不到的，也没有人能够投票，即使技术人员吐槽代码无奈保护，但如果我的项目获得了商业上的胜利，也只会越做越大，技术债越滚越多。

技术我的项目的买家是程序员，但程序员没有拒签的方法，导致无论我的项目品质如何都要承受，没有市场机制的作用，就导致了烂代码随处可见。

要解决这个问题，首先要意识到这个问题，即技术我的项目品质实质上是无人长期、继续关怀的，你可能会说，技术 Leader 会关怀呀？但这和业务驱动相比切实是太弱了。产品有用户侧钞票的投票，无论管理者换多少人，还是会从源头继续提供能源，但我的项目品质总是要反复强调，间歇性整治，并且不同的 Leader 关怀水平也不同，因为这背地没有源能源，除非我的项目品质影响到用户那头的现金供应了，但这种状况产生时，阐明我的项目早已烂透了。

正是因为技术品质不足源能源，或者说源能源传导链路太长，咱们才要人为的不断加强器重，器重文档、器重应用体验、器重是否合乎设计模式。只有长期主义者能力保持做代码品质治理，因为深信总有一天，代码品质会影响到业务倒退。

总结

这次从真实世界借鉴了一些教训到软件世界，咱们从借鉴真实世界的屏蔽复杂度，谈到了为什么真实世界的说明书这么好用，但技术我的项目文档却总是缺胳膊少腿的问题。

咱们总结出的教训是，设计准则与设计模式诚然能够晋升可维护性，但归根结底还是能源的问题，晋升代码品质自身就是一件不足能源去做的事，或者长期被认为是重要不紧急的事，往往很难找出理由当初就去做，但没有人感觉不应该做。

所以想要晋升可维护性，找到为什么当初，立即，马上就要做技术优化的起因，并立刻开始优化才是最重要的。

探讨地址是：精读《可维护性思考》· Issue #359 · dt-fe/weekly

如果你想参加探讨，请 点击这里，每周都有新的主题，周末或周一公布。前端精读 – 帮你筛选靠谱的内容。

关注 前端精读微信公众号

<img width=200 src=”https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg”>

版权申明：自在转载 - 非商用 - 非衍生 - 放弃署名（创意共享 3.0 许可证）