PS：所有未链接原文的精读均为原创，本文亦为原创。前端精读之前，写了23篇设计模式总结文章，外加6条设计原则，开闭、单一职责、依赖倒置、接口分离、迪米特定律、里氏替换原则，基本上对代码的可维护性有了全面而全面的了解深刻的理解。但是你我将继续在工作中遇到糟糕的代码和几乎无法维护的大型项目。想一想，光靠设计模式能解决这些问题吗？为什么越来越大的项目在现实世界中越来越难维护、越来越复杂，却没有人觉得它们快要崩溃了？设计模式考虑代码之间的关系，设计原则考虑模块和项目之间的关系。有没有更高层次的思考来解决大型项目越来越难维护的问题？精读首先考虑，为什么现实世界中不存在可维护性问题？为什么在现实世界中没有可维护性问题这个问题看起来有点傻，因为从来没有人发出过这样的抱怨“我们的产品、技术、概念太多了，多到我觉得活不下去”在这世上。”但在代码世界里，程序员经常抱怨项目有太多的概念和设计太复杂，他无法继续维护，是时候另谋高就了。一个明显的解释是，在生活中，我们都是小人物，生活在自己的天空下，不需要接触那么多概念，而程序员在项目中基本上扮演着上帝的角色，必须操心每一个细节。但这并没有多大意义。我们认为我们不知道很多事情，但实际上我们对日常生活的了解太多了。以家电为例，大家会同时接触到几十种家电，大到空调、冰箱、洗衣机，大到手机牙刷充电器。这些产品在很大程度上是标准化的，但每个产品在大量细节上都不同，但没有人觉得学习使用新剃须刀是一种负担，设计糟糕的牙刷也没有，这对整个牙刷行业造成了多大的负面影响。这背后的原因是：抄袭。正因为我们所用的一切都是副本，就算是坏掉了，也不会对其他一模一样的物品造成任何影响。但是代码世界就不一样了，因为代码调用关系的存在，复用得越优雅，破坏力就越大。断几根钢筋还能支撑一栋楼，但在代码世界里，只要断一根钢筋，就代表整栋楼的钢筋全部断了。这是程序员最痛恨的问题之一，就是为什么一个看起来对人畜无害的代码改了，却造成了失败。从这个角度来看，代码世界无法从现实世界的经验中学习。而且，代码世界的这种副作用在商业上有着巨大的正向价值，即软件的边际成本几乎为零，这对于实体产品来说是不可能的，所以软件需要付出可维护性的代价，这似乎是案件。边际成本极低的价格。虽然通过借鉴现实世界的经验不可能将维护成本降为零，但现实世界确实有可以向软件世界学习的地方。下面我们来讨论几个有趣的观点。现实世界不断阻碍复杂性。不知道大家有没有想过：面试官总是问原理，就是担心自己只会用框架，没有基础。但依据是什么？会js，java算不算基础？也可以说不算，因为这些语言背后的编译原理貌似是基础。编译原理的背后是操作系统。操作系统运行在硬件上，但硬件原理呢？从CPU的设计到背后的硅片是怎么做出来的等等，好像永远也抓不住原理。但是当我们从软件推演到硬件的时候，自然可以发现，没有人认为掌握硅胶的生产工艺是必须的。我们可以随时使用硅胶制成的产品，但我们不需要了解硅胶的制作原理。现实世界总是在屏蔽复杂性。作为消费者，我们面对的产品总是经过精心包装，使用方便。只有在工作的时候，我们才需要了解某个专业领域的原理。这个原理可以移植到代码世界，即对于一个庞大而复杂的项目，我们不能指望每个开发人员都了解所有的原理才能开始工作。很多时候我们需要把开发者当作消费者，提供美观稳定的接口。为此，需要类似下图的架构设计：从图中可以看出，即使是业务层代码，我也不需要太在意底层实现。底层代码就像脚下的压实土地，走在上面就好了。然而，最令人沮丧的是下面的设计：为了解决一个问题，你需要面对无穷无尽的上下文，这是维护成本高的主要原因。为什么您认为维护成本高？作为开发人员，我习惯于评价代码维护成本是高还是低。今天，我们换个角度思考一下，为什么大家觉得维护成本高？维护成本的感受并不完全客观。我画了一个四象限图：左边是和人相关的部分，包括你对代码的理解能力和对项目的熟悉程度。理解能力越强，越不会觉得维护成本高；对项目越熟悉，即使是石山代码，你也会觉得重构后可维护性并没有提高，因为你对项目会变得陌生。右边是与项目相关的部分，包括业务本身的复杂度和背后技术抽象的好坏。业务本身越复杂，维护成本越高，因为信息量不可避免的增加，我们永远不能只关注HelloWorld这个demo研究框架；代码质量体现了技术对业务的抽象，抽象的好，复杂度曲线会更符合业务的真实复杂度。如果抽象的不好，HelloWorldDemo也可以让新人进来喝一杯。这四个关键词中，业务复杂度几乎是不变的，熟悉项目也需要一个过程，所以重点应该放在理解能力和代码质量上。无论是个人理解能力还是代码质量，都是以帮助我们快速理解项目为目标。也就是说，只要能快速了解技术项目是干什么的，如何快速集成，我就会觉得可维护性高，反之亦然。维护良好。所以一个简单的项目，或者层次合理、文档清晰的大型项目，都会让人觉得可维护性好。在这一点上，需要从现实世界中吸取的经验是，即使在软件世界里，也不是所有的原理都懂，各个角落的逻辑都说明技巧高人一等。带着这样的想法去工作，只会让大家陷入无尽的迷茫之中。涉及和理解焦虑。我们想减轻每个人的负担。不需要理解的模块和代码设计不要轻易展示。设置了每个模块开发所需的最低知识，以最大限度地减少开发人员的理解负担。当然，我要补充的是，这并不意味着限制开发者的成长和学习空间。其他知识随时开放，但了解它们不是日常开发所必需的。这些形成知识的文档在使用后可以丢弃，不需要成为长期记忆。.说到这里，就引出了现实世界中第二个有趣的地方，那就是说明书。回想起来，现实世界中的手册真是不可思议。不管你用快递买什么，最终都可以按照说明书上的说明进行组装，安装好说明书就可以扔掉，完全没有认知负担。与其说快递包裹说明书太完善，不如说说明书不完善，不好用的产品根本卖不出去。我们早已习惯了极其易于使用的产品及其详细说明。这是商业社会不断发展和长期博弈的结果，并将稳定地持续下去。试想一下，如果我们参与维护的项目也有精美的设计和完善的文档，那么维护就不成问题了，跟着文档一步步来就可以了。那么，为什么在大多数情况下，我们接手的项目就像没有说明的乐高积木一样呢？这应该是产品和代码的本质区别，即产品的好坏是由买家用钞票投票的。只有做工好、说明书齐全的产品才能生存，但这背后的技术实现是看不见的，没有人可以投票。即使技术人员抱怨代码无法维护，如果项目取得商业上的成功，只会越做越大，技术债越积越多。一个技术项目的买家是程序员，但是程序员没有办法拒签，导致不管项目质量如何都接受。没有市场机制的作用，烂代码随处可见。要解决这个问题，首先要意识到这个问题，即技术项目的质量本质上是没有人长期持续关注的。你可能会说，技术负责人会关心吗？但这与业务驱动相比就太弱了。该产品有来自用户钞票的选票。无论更换多少经理人，权力都将继续从源头上提供。但是，项目质量总是要反复强调，断断续续整改，不同的Leader关注的程度不同，因为背后没有源头。势头，除非项目的质量影响到用户这边的现金供应，但是一旦出现这种情况，就意味着这个项目已经烂了。正是因为技术质量缺乏源动力，或者源动力传输链路太长，所以我们必须继续更加关注文档，用户体验，是否符合设计模式。只有长期主义者才能坚持代码质量治理，因为他们坚信总有一天，代码质量会影响业务发展。综上所述，我们这次从现实世界中借鉴了一些经验到软件世界中。我们从屏蔽现实世界的复杂性出发，讲了为什么现实世界的手册这么好用，而技术项目文档却总是缺胳膊少腿。我们得出的经验是，设计原则和设计模式固然可以提高可维护性，但归根结底是动机的问题。提高代码质量本身就是一件缺乏动力去做的事情，或者长期以来被认为重要但不紧急的事情，现在往往很难找到这样做的理由，但没有人认为不应该这样做。所以，要想提高可维护性，最重要的是找出为什么现在要做技术优化，马上，马上开始优化。讨论地址为：Jingdu《可维护性思考》·Issue#359·dt-fe/weekly想参与讨论的请戳这里，每周都有新话题，周末或周一发布。前端精读——帮你过滤靠谱的内容。关注前端精读微信公众号版权声明：免费转载-非商业-非衍生-保留署名（知识共享3.0许可）
