Introduction

开闭原则-对扩展开放，对修改关闭。 开闭原则要求在扩展新功能时应当避免对旧代码的改动。但现实的开发中，新增功能多数情况下都要涉及到旧代码的改动，这主要是因为在业务刚开始推进的时候并不能很清晰的看出业务的拓展方向，因此通常情况下都不会进行预留扩展的设计（避免过度设计）。 当扩展需求出现时，就是开始重构原有代码的时机，而开闭原则就是指导重构的主要思想，在重构过程中，应将此次扩展的业务方向做一个通用方案的处理，保证下次再出现同类型的扩展可以做到不改动或少改动旧代码。 依据开闭原则做架构设计时，我们应该清楚要保护什么，可以通过分层来决定保护级别，最高层的保护级别最高，最低层的保护级别最低。低层级的改动不会影响高层。 层级的划分可以根据业务来划分，核心业务逻辑应该是最高等级，其他层级根据与核心业务的关联程度依次向下划分等级。这样的划分逻辑我们能够保证核心业务规则不会因为其他相关模块的改动而受影响。 接下来通过《架构整洁之道》(clean architecture) 中的一张图来解释一下分层设计 图 8.2 < I > 表示接口，< DS > (data struct) 表示数据类，数据类的特性是第一次访问的时候会创建类，后续则是对该实体的读操作（实体类特性也是如此）。空心箭头表示对应接口的实现，实心箭头表示依赖关系， A->B 则是 A 依赖 B，A 知道 B 的存在，B 对 A 一无所知。 正是由于依赖的这种特性，我们可以把被保护的代码，写到被依赖的类中，这样被依赖的类不会以为依赖方代码的改动而受影响。 上图中：Interactor > (database) > Controller > Presenter 关于图 8.2 调用链路如下： 这种设计 Controller、Presenter、Database 任何模块代码的改动，都不会影响 Interactor ，从而达到了对 Interactor 代码的保护，如果某天对 Presenter 中的 PDF View 进行改动出现了 bug，仅仅印象 PDF View 这一个功能，把 bug 进行最大程度的隔离，实现功能的稳定。 总结 开闭原则保证了程序的扩展性，同时用分层的思想设计架构，通过依赖保护核心业务逻辑，避免核心逻辑的频繁改动，隔离低层代码的改动影响高层。 如果你对架构设局同样感兴趣，推荐给你一本书《架构整洁之道》(clean architecture) 。这本书对架构设计的讲解十分深刻，相信你也一定会有所收获。

面向接口编程： 当一个实体依赖另一个实体时，不依赖实体而是依赖实体的抽象。 比如说生产一个电灯，电灯需要一个开关来控制电灯的点亮和关闭，如果电灯依赖某个具体的开关,，比如电灯出场内置开关依赖了 A 品牌，当有一天买电灯的客户家里是 B 品牌的开关，那么电灯就没办法使用了。但是如果我依赖的是开关的抽象接口，它提供打开和关闭两个行为给电灯，电灯根据打开和关闭的行为去控制电灯的点亮和关闭。 这种设计可以让生产的电灯适应市面上的所有开关，那怕未来实现了脑机接口的开关，只要这个它遵循开关的抽象提供打开和关闭两种行为，这款电灯就能受这种新开关的控制。 从上面例子上可以看出，所谓的接口是依赖双方提前的一种约定，依赖方按照这种约定去调用，被依赖方按照这种约定去实现，这种约定其实就是标准化，调用方按照约定去实现功能，使用方按照约定去使用功能。 标准化的好处 从上面的例子中可以看出，标准化带来最大的好处就是复用，你可以任意的生产各种各样的开关，只要是按照标准制定的，我的电灯都是可以使用的。 其次标准化会带来效率的提升，现实中交通规则就是一个很好的例子，交规就是一个标准, 只要是在路上的走的，都受到交规的约束，而正是有了这种约束我们才有了更高效的通勤，绿灯了可以走，红灯了，就停下来等待，我们对路上所有的车辆和行人的轨迹都有预期，从而提升通行效率。 可以设想一下没有交规，是一个什么样的场景，大概率会出现所有车辆堵在了路口，整个路口堵的水泄不通，最后整体通行效率变得无比低下。 标准化还会带来工具化，再拿生活中常见的交通为例，有了完善的交通规则，后续就可以生产适用这种规则的自动驾驶车辆，这将大大改善人们的出行效率。 标准化在工作中的用处 标准化在工作中也有着十分重要的作用，如今的工作大多都会有工种之间的划分，工种和工种之间就存在着依赖关系，上一个工种的工作要到什么程度，下一个工种应该怎么衔接，这就是一个依赖，而在这两个工种之间就需要一个明确的约定。 有了这种约定，可以减少很多不必要的沟通，不需要去关心上个工种的实现细节，只需要双方按照约定各自生产，在产品成型阶段把各个工种生产出的设备进行组装即可。 当公司来了新人的时候，他也不需要重新去每个环节去了解其他工种的产品特性，只需要去了解约定的标准化制度即可投入到生产中。 标准化的问题 标准化也并非都是好处，它在设计阶段需要投入相当的人力去设计，并且需要在后续的生产阶段通过实践中得到的反馈，去不断的完善标准。 如果标准设计的不好，频繁的变更标准，将会导致所有依赖的标准方都要进行变动，这种变动的成本是相当高的。 因此在标准设计的时候要进行必要的论证和演练，确保标准没有明显的问题，最大限度的减少标准化带来的成本。 总结 标准化相当于在一个有限范围内设计了一个小型的生态系统，标准化制定了基本的流程和规则，生态系统的其他元素按照这种流程和规则去演化出标准化所期望达成的效果。 标准化的制定是有难度的，有些时候仅从设计阶段，无法看到最终的结果，这时可以通过抓大放小的形式去解决。刨除细节，去设计整体框架，保证大方向的正确，在标准化实践的过程中去不断的丰富细节，完善标准，从而让标准化实现最终的落地。 可能某些情况下理想下的标准化永远也无法达成，但这不能成为放弃标准化的理由，不能因为我们理想是得到 100 分的好处，因为我们拿不到 100 分就放弃。拿不到 100 分，能拿 60 分也比一分都没有要好一些，你觉得呢？

单一职责原则：一个模块的功能只能因为一个原因进行修改。 单一职责介绍 我们假设一个场景： 有一个动物类，它会呼吸空气，用一个类描述动物呼吸这个场景： class Animal{ public function breathe(string $animal){ echo $animal . "呼吸空气"; } } $animal = new Animal(); $animal->breathe("牛"); $animal->breathe("羊"); $animal->breathe("猪"); 当有一天我们发现并不是所有的动物都呼吸空气，例如水生的动物他们呼吸的是水，我们就需要进行如下的代码改动。 class Animal{ public function breathe(string $animal,string $type){ if ($type == "terrestrial") { echo $animal . "呼吸空气"; } else { echo $animal . "呼吸水"; } } } $animal = new Animal(); $animal->breathe("牛","terrestrial"); $animal->breathe("羊","terrestrial"); $animal->breathe("猪","terrestrial"); $animal->breathe("鱼","aquatic"); 上述代码的改动就违反了单一原则，breathe 方法会因为两个因素造成修改，分别是 terrestrial 和 aquatic 。 这种违反会带来什么问题，最直观的问题就是会更容易造成 bug, 比如我们 terrestrial 需要增加新的功能，在些新功能的时候引入了一些 bug ，这将导致 aquatic 的代码块也无法执行，具体例子如下：...

知识库是什么？简单来说知识库是一系列文档的集合。文档是沉淀知识的载体，而存放知识的地方，就叫做知识库。 我想大多数程序员都和我一样是不爱写文档的，在这些年的开发过程中，我逐渐认识到写文档的重要性。因此才有了这篇文章，向你介绍一下为什么我们需要一个知识库。 知识库的作用 不知道你有没有这种困扰： 场景一： 某天你需要在某个同事开发的功能基础上拓展一些新的功能，但是你不清楚这位同事开发的功 能是怎么运行的。你想要了解程序的具体内容，于是你找同事咨询，恰巧这位同事有事请假了，于是你只能硬着头皮从代码层面去阅读理解，去梳理原有程序的实现逻辑，遇到某些复杂部分，你可能需要格外的小心，重读多遍，以便于能正确理解实现思想… 如果在你看代码前，你突然得到一个消息，这位同事之前写过关于这部分功能的实现文档，你心头会不会突然涌现出一丝暖意，嘴角不自觉的上扬呢？ 场景二： 你实现了一个核心业务，它被很多的其他的业务方关联，这些业务方在实现自己的业务之前都会跑来找你了解你这部分业务的实现情况。你每次都能耐心详细的把自己的业务讲明白，也很好的帮助了业务方调用你的业务。 随着业务的发展，会有新的业务实现人员发现自己的业务依赖你所实现的业务，于是他再一次找 到了你说：我需要你的帮助… 以上种种让你觉得深陷泥沼，无法自拔。这时如果你有一份文档详细的介绍了你所实现业务的逻辑，它去帮你解答他人的困惑，你是否觉得它就像天使一样，拯救你于水火呢？ 正如上述场景所描述的那样，知识库能够解决团队内的信息同步问题，当有需要的时候知识库能够帮助团队的成员更快的了解相关信息。 对于一些高频出现的问题，知识库可以作为你的助手一样，帮助你向有需要的人进行解答，解放出你的时间和精力，专注更重要的事情。 同时知识库还能作为你的外脑，帮你去记忆某些重要的事情。人的记忆是不稳定的，而计算机却十分擅长记忆，把需要长期记忆的通过知识库交予计算机，让大脑去做它擅长的事情。 如何选择知识库 知识库作为一个文档存储载体，它的选择是多种多样的，可以根据不同的需求做出不同的选择。 个人知识库 如果个人使用，你可以用笔记软件去组织自己的知识。它最好要有一下特性： 多端支持（IOS，Android, Windows, Linux） 多端之间要有相互同步的能力 支持 Mrkdown 支持双链 上述特性中，多端支持和多端同步是我认为必须要有的，它可以让你随时随地记录，并且随时随地调取你的文档。 Markdown 和双链 是选用功能，Markdown 是一个通用语法，如果你用 Markdown 写的文档可以很平滑的迁移到其他平台。双链可以帮你更好的组织文档之间的关系，可以让知识系统由一个个独立的点串联成知识网络。 团队知识库 团队知识库的选择，最重要的一个原则是：如何让团队以最小的成本接入。可以考虑从团队现有工具中找到相关的知识库进行使用。 所选知识库要有能对外分享的能力，有时候有些文档是需要让客户开放的。 推荐两个知识库软件：飞书，语雀。两款软件使用感受都不错，语雀的使用体验要更好一些，不过有些功能需要开通会员才能使用，比如把文档分享到互联网的功能。 飞书的使用体验比语雀稍差一些，最大的优势是它免费的功能能满足一般的使用需求。 如何使用知识库 知识库根据使用用途一般分为对内和对外两部分。对内可以根据知识库的敏感程度设置为：是整企业可见/部门可见/指定人可见。对外可以完全是对互联网开放，做开放平台开放的文档，或者产品使用手册等都可以设置为对互联网开放。 如何写一份功能文档 以功能文档为例，我认为文档应该在实现功能之前就要写了，这么做的目的是在开发功能之前梳理开发思路，形成一个框架。这个阶段主要是考虑全局，不需要深入细节。 如果梳理过程中有需要讨论的地方，也可以用文档来作为基础和参与讨论人员做思想对齐，使接下来的讨论更加的聚焦在问题本身。 框架梳理完成后，就可以进入功能开发了，功能开发阶段可以对关键业务部分做一些流程梳理，也不需要过分追求细节，能够明确的表达思想即可。有了这份文档在方向上的指引，也有助于在开发阶段少走弯路。 在功能开发完成后对文档进行补充，补充一些细节的说明，让整个文档更加的丰富，表达更为通畅和清晰。 什么情况下需要写文档 写文档也是需要付出成本的，因此在写文档之前需要考虑这个文档它的使用收益是否大于成本。因此写文档可以由一下两种策略：降低写作成本 和 提高写作收益。 降低写作成本：可以不用在意文档的完整程度，可以把这类文档作为一个提示文档，它只需要能够辅助我们想起来如何去找到答案即可，不追求写作的表达和完整性。 提高写作收益：对于一个问题多次被提及到，我们可以认为此问题形成文档的收益在提升，可以考虑输出文档去解决此类问题。 定期维护文档 文档也有生命周期，随着业务的发展，文档也需要进行相应的调整。这个维护工作应该是文档作者和所有使用的人，也就是说不仅仅写文档的人要维护文档，阅读文档的人也可以维护文档。 阅读人可以为文档补充案例。或者对于一些有疑问的地方得到解答后，可以细化到文档中，帮助后面的阅读者更好的理解文档。 总结 本文大概讲解了一些知识库的价值和使用方式，目的是在你的心中埋下一颗种子，它需要时间去发芽和成长。 知识库的使用并不是那么容易，肯定会遇到各种各样的问题，要有直面并解决的勇气。千里之台始于垒土。 如果你认为这是一件正确的事情，就坚持下去，潜心耕耘，静待花开。 扩展阅读 双链笔记是伪概念？聊聊双链的核心优势——知识管理 - 少数派 (sspai.com)

最近读《微信背后的产品观》很受启发，张小龙在文中阐述了他的产品哲学，以及微信产品的发展过程中的一些思考与体会。对于好的产品，共性之一就是他们都足够的简单。 微信发展了这么多年，他已经成为一个非常重的应用，里面的功能也是非常的复杂，但是这些复杂没有暴露给用户，对于大多数人，常用的功能占 1% 都不到，从此也能看出，微信的克制。 微信不会在你使用产品的时候打扰你。比如它不会在更新后，给你弹个操作引导，告诉你它更新了什么东西。当你在使用微信的时候，觉得这个地方应该可以进行某个操作，当你按照自己的想法去操作的时候，你会发现你想要的功能就在哪里。微信通过符合直觉的方式去展示他的功能，而不是去教育用户让用户去适应它。 像上述例子比比皆是，它贯彻微信的整个生命周期。如何能像微信一样，做一个简单且有用的产品呢？ 你有没有做伟大产品的决心 你是想做一个伟大的产品，还是想当一天和尚撞一天钟。是能否做出伟大产品的关键。心态在其中是起到无可比拟的作用的。 心态是决定你能把事情做到什么程度，它会潜移默化的影响着你。也时刻影响着你的产出质量。 你可以因为没有那么热爱而离开，但最好不要敷衍。你的时间不会重来，把时间浪费在低质量的产出是相当不明智的。 所以去全力以赴把产品做到当下的最好，不辜负团队，也不辜负自己的生命。这是你对自己生命最好的交代。 别用战术上的勤奋掩盖战略上的懒惰 做产品的时候，我们可能会从用户或者运营那里得到很多的想法，更有甚者会直接告诉你我需要一个什么样的功能，你帮我做出来就好。 如果面对这种情况，我们努力去完成每一个人的需求，勤奋的让自己都心生怜悯，这种做法也是十分不可取的。 做产品要解决的东西是本质，而非现象。现象是千变万化的，今天可能是 A 明天可能是 B，但是他们可能都是基于某个基础需求所衍生出来的。如果只是去解决现象，那不仅会辛苦而且收获甚微。思考和找到其本质，才是一劳永逸的解决之道。 沉浸其中 深入到产品中, 了解你产品是什么？解决了什么问题？解决了谁的问题？ 你得清楚的了解它，才能在新需求来时知道如何安置。才能找到一个支点，用最小的代价撬起万钧之力。 所以深入到你的产品中，深入到你的客户中，去感受他们给出的回应。 总结 做产品也是一定程度上反人性的，有些时候我们凭借直觉给出方案，但这种方案仅仅是满足需求而已，它既不好用，也不简单。这样的事情做的多了，产品就会膨胀和混乱，最终导致复杂且晦涩，用户更没办法理解和使用。 所以我们需要适时的提醒自己，这样做对吗？它足够简单吗？它能使我的客户更方便吗？ 去让客户自然的使用你的产品，而不是教他如何使用你的产品。