Posts

最近读《微信背后的产品观》很受启发，张小龙在文中阐述了他的产品哲学，以及微信产品的发展过程中的一些思考与体会。对于好的产品，共性之一就是他们都足够的简单。 微信发展了这么多年，他已经成为一个非常重的应用，里面的功能也是非常的复杂，但是这些复杂没有暴露给用户，对于大多数人，常用的功能占 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】 ...

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

最近看苹果无创检测血糖技术实现突破，专家说精度不足1的新闻，及前一段时间大火的 ChatGPT 都让我有一种感受，一项新技术的出现，总会出现两种人的声音，一种是及其看好，把其堪称为颠覆和突破，另一种则是觉得新技术各种瑕疵，无法替代现有方案。 两种看法都是相对来说片面的，技术是会迭代的，在迭代的过程中可能发展向第一种看法，打造出颠覆性的解决方案。也有可能迭代的过程中依然无法解决核心的问题，那么就可能永远无法颠覆现有解决方案。 飞机最初的发明思路，是按照鸟的飞行结构去设计的，但是鸟由于骨架轻等特点可以用自身的结构实现飞行，但飞机显然是不可以的，飞机的自重加上载重如果利用鸟的飞行结构去设计显然是无法飞行的。 我们回到刚刚发明飞机的那个时间节点去看，有人觉得飞机会颠覆出行，有人觉得飞机连飞都飞不起来，不可能替代现有出行方案，双方观点截然相反，但又有各自的道理。而从事后来看飞机显然成为现代出行必不可少的交通工具，但是如果飞机在设计的时候没有空气动力学的支持，飞机可能永远也无法飞起来，那么后者的观点也就成了对的。 既然两个观点都是片面的，应该如何看待一项新技术的产生？我认为我们应该用乐观的态度和发展的眼光看技术的突破，也就是更倾向于第一种观点了。 原因是任何技术的诞生之初都是不完美的，悲观的态度只能阻碍其发展，而乐观却不同，乐观能够更大程度的促进技术发展，即便是技术没有实现落地，至少也努力验证了其不可行性，也能为后续的技术的发展提供一个不可行案例，也是存在贡献的。悲观可能会导致直接放弃，对于技术发展而言是没有任何贡献的。 所以不管是对一项技术还是人生中在做的事情，我们都应该用积极的态度去面对，也许用尽各种努力最终还是失败，失败只是结果，但在努力的过程中是一定会有所收获。 从结果上看，努力尝试和直接放弃最终都是失败，但是收获上来看是完全不同的。 References 苹果Apple Watch将实现无创测血糖？专业人士：物理检测 精度不足 (10jqka.com.cn) ↩︎

在开发中与别人交流或在程序员社区中，经常会有关于烂代码的讨论，并且为其起了一个打趣的名字”屎山“。 仅从名字上也不难看出，大家对于这种代码是十分的厌恶的。其实随着需求的变化和增加，项目不可避免的会变的混乱，在物理学里有个名词叫“熵增”。 熵增过程是一个自发的由有序向无序发展的过程 既然代码会膨胀，并且会变得混乱，如何做能够尽量的避免这种情况的发生呢？ 核心办法就是主动做功，在规划、实施、复盘等各个阶段有意的去做治理，从而避免代码的混乱。 勾勒整体 在需求开发之前，要建立对需求的整体的认识，从整体拆分细节，从细节着手开发。这么做的主要目的就是对需求有一个全局的规划，确定需求边界，就不会再开发的时候迷失方向，导致整个需求的实现变得混乱，代码和思想都没有清晰的表达。 在整体确定，边界清晰的时候，还需要考虑一点：当前需求与已有功能的关系时怎么样的，如何能花费更小的成本将新增需求融入现有系统。 完成上面说的还有一步就是追问，此方案是否为最优方案，是否还存在更为简化更易于理解的放啊的方案，如果回答全部为是，那么关于整体这部分的考量也就到此结束了。 化繁为简 我对专业的定义是：可以将自己领域的复杂问题简单化的能力。把简单的事情做复杂是庸才，把复杂的事情做复杂是通才，把复杂的事情做简单是天才。 在程序开发中，以易读为第一要务。写代码的主要目的是给人阅读，其次才是机器执行。在开发中，应该以代码的可读性为最高优先级，其次才是性能或其他指标。 大道至简，做到简不容易，需要通过不断的练习与反思，才能窥其门径。 摒弃过度设计 好的程序设计应该是立足业务的基础上长出来的，在业务不是很明朗的时候，应该更专注于方案和代码的简单而不是过度设计。 业务不明朗的时候大多数的设计是无用的而且一些设计会带来代码复杂读的增加，虽然可以美其名余曰有更好的扩展性，没有用的扩展性等于没有扩展性。 好的设计应该是以对业务有深入理解后，通过重构的手段展现出来的，而不是在业务一开始就过分的考虑设计。 不断重构 重构的时机有三种： 对业务有更深入理解的时候 在原有功能扩展新功能的时候 已有功能存在设计缺陷的时候（性能，扩展性，易读性） 重构不应该等”有时间“的时候，”有时间“就等于没有时间。重构应该发生在发现问题的时候，发现问题就解决问题。 就像打扫卫生一样，每发现一个地方乱了，就顺手整理一下，虽然没有刻意的花时间去进行整理，但是整个房间依然会保持整洁。 应该缩小重构的粒度，增加重构的频率，使重构变得小而频繁。 总结 除了上述说的情况之外，保持学习也是很关键。思而不学则殆，通过学习他人项目治理的思想，来增加自身的理解，并在开发中不断的去验证、思考和改进，从而写出更简洁高效的代码。 纸上得来终觉浅，绝知此事要躬行。学习只能是觉知，关键在于实践，知行结合，才是真正把知识内化为己所用。希望本文能对你有所帮助，个人观点难免会有疏漏和偏颇，如果有不同观点，欢迎留言讨论。