单一职责原则：一个模块的功能只能因为一个原因进行修改。 单一职责介绍 我们假设一个场景： 有一个动物类，它会呼吸空气，用一个类描述动物呼吸这个场景： 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，但是他们可能都是基于某个基础需求所衍生出来的。如果只是去解决现象，那不仅会辛苦而且收获甚微。思考和找到其本质，才是一劳永逸的解决之道。 沉浸其中 深入到产品中, 了解你产品是什么？解决了什么问题？解决了谁的问题？ 你得清楚的了解它，才能在新需求来时知道如何安置。才能找到一个支点，用最小的代价撬起万钧之力。 所以深入到你的产品中，深入到你的客户中，去感受他们给出的回应。 总结 做产品也是一定程度上反人性的，有些时候我们凭借直觉给出方案，但这种方案仅仅是满足需求而已，它既不好用，也不简单。这样的事情做的多了，产品就会膨胀和混乱，最终导致复杂且晦涩，用户更没办法理解和使用。 所以我们需要适时的提醒自己，这样做对吗？它足够简单吗？它能使我的客户更方便吗？ 去让客户自然的使用你的产品，而不是教他如何使用你的产品。

Fiddler 抓包原理并复杂，Fiddler 软件会在 PC 上起一个代理的服务，手机连上 Fiddler 代理服务后，手机访问某个网址时，其实时发送给 Fiddler, Fiddler 去请求对应的地址，把响应结果在返回给手机显示，这样 Fillder 就可以在软件里做一个记录从而显示出手机访问的所有请求信息了（如下图所示）。 知道原理后，我们要抓包也就十分明确了，我们需要 Fillder 软件，一部手机即可。 Fiddler 下载地址 安装可以自行百度如何安装。 Fiddler 配置 配置 https 请求抓包 配置端口号 此步非必要，如果本机 8888 端口，未被占用，可以用默认的 8888 跳过此步 完成上述配置后，重启 Fiddler 软件。在软件右上角有个 Online 鼠标放在上面就可以看到本机 ip 地址，这个 IP 我们叫做【代理 IP】需要记住，手机配置的时候需要用到。 手机配置（IOS） 如果你的手机是安卓，可以 Google 安卓是如何设置 wifi 代理的，设置上即可，安卓安装证书更加的简单，只要点击证书安装上即可，不需要其他的额外操作。 配置代理 前置条件：手机连接的 WIFI 需要和电脑是同一局域网。 配置 WIFI 代理：设置->无线局域网->点击连接的 WIFI ，拉到最底部点击【配置代理】选择【手动】。 服务器：Fiddler 软件右上角 Online 显示的 IP 即【代理 IP】 端口号： 8888 （如果自己设置了，就改成自己设置的） 下载证书 这里需要下载 TLS 证书，不然是无法抓到 HTTPS 请求内容的。用手机浏览器访问 【代理 IP】...

由运营同事提出的一个问题引发了我对开发需要理解需求的思考。为了业务的保密，我把问题简化为：某个用户下的数据能否迁移到另一个用户下。 仅从技术的角度，这个迁移肯定时可以迁移的。如果回答可以，并帮运营同事去做了，看上去也没有什么问题。 回到运营同事提的需求本身，我们看一下，我要迁移一个人所属的数据到另一个人下面，我要找到所有被迁移人的数据，这需要涉及到系统中各个功能产生的用户数据，本身涉及的表就会比较多，操作起来会也就会比较容易出错（可能会漏掉某些功能产生的数据），且通过运营同事的沟通，我认识到这种迁移操作可能会高频出现。 问题分析到这里，好像我们通过脚本就可以解决了，一次找到所有的表，写完脚本，后续的迁移只需要传入两个人的 ID，就可以把数据实现迁移了。 如果仅从当前看，上述想法没有任何问题，如果我们把时间再拉长一些，我们后续业务又开发了一个新的功能且此功能也会产生用户数据结果是怎么样的呢？ 那我可能就需要在原来写的脚本里加上这个功能的迁移逻辑，那么这个迁移脚本的维护成本如下图所示： 作为一个开发来讲，这样的模型当然不是我们所希望的，我们都不想给系统添加了一个新功能还需要去维护和修改以前的功能，才能保证系统的平稳运行。 我意识到上述问题后，问了一下运营同事：“为什么会有这种迁移的需求？"，经过和运营同事的更进一步的交流后发现，运营同事要解决的问题其实可以通过其他方式解决，而且这种方式，在系统加入新功能后，不需要改动和维护任何的已开发功能，开发成本如下图所示： 到此即解决了运营同事的问题，也减少了开发的维护成本，可以说是一举两得。 在职业生涯中，我们不乏碰到一些人并不认真去理解需求，甚至会说出：“你直接告诉我怎么做”，这样的话，最中导致的解决可能就是： 没有按照需求实现功能 实现了需求的功能，但是影响到了其他已有的功能模块 实现了需求代码写的复杂、难懂。 往小了说会造成个人开发效率的下降，且 bug 相对较多，往大了说会对团的和公司带了负担。 因此在开发过程中，了解需求是很有必要的。有时候我们会与不同的人讨论问题，有时是运营，有时是产品，有时也可能是老板，但是作为开发，我们除了完成需求交付之外，我们也有责任让他们了解，他们所提方案的成本，以及该方案下会产生哪些潜在的风险。 clean architectrue 里面有一句话非常受启发分享给大家： The goal of software architecture is to minimize the human resources required to build and maintain the required system 软件架构的目标是用最少的人力成本去构建和维护所需系统