- Published on
vol1.活在这珍贵的人间，太阳强烈，水波温柔
- Authors
- Name
- 两万焦
卷首语
这是我的第一篇 newsletter，“活在这珍贵的人间，太阳强烈，水波温柔” 来自海子的一首诗，近期工作稍微没那么忙了，开始思考工作和生活平衡，也开始骑行。我觉得之前自己的焦虑本质上都是源于外部信息铺天盖地的袭来，而骑行的两个小时里，没有手机，只有专注踏板和前进、耳边的风声，在逐渐意识到自己活着这珍贵的人间
本周阅读
前端简洁架构
IT/架构
架构设计的目的
- 将系统分离，不需要太多成本就能重新组合
- 可扩展性高，因为需求是不断变化的
简洁架构：根据其与应用领域的密切程度来分离职责和部分功能的方式
- 领域层（Domain Layer）：应用程序主题领域（subject area）的实体和数据
- 产品、订单、用户、购物车，以及更新其数据的功能，在不同的框架中逻辑都是一样的
- 领域和外部事件无关，比如购物车不关心商品是如何添加的
- 应用层（Application Layer）：描述用户场景
- 描述事件如何发生，比如添加购物车，描述按钮被点击后的操作
- 应用层通过接口（interface）和外部联系
- 适配器层（Adapters Layer）：兼容外部服务 API 和应用程序
- 目的为了减少与第三方服务的耦合
- 分为
- 驱动型：比如点击一个按钮，按钮与浏览器 API 交互，再返回特定的事件
- 被驱动型：与服务端的基础设施交互
简洁架构的核心规则：只有外层可以依赖内层
- 领域必须是独立的
- 应用层依赖领域层
- 外层可以依赖内层
简洁架构必须要遵循的规则
- 提取领域：确定核心的模块如何工作
- 服从依赖规则
简洁架构优点
- 领域分离
- 独立用例
- 可替换的三方服务
简洁架构的缺点
- 时间成本
- 冗余成本
- 更高的门槛
领域层设计示例：订单
- 领域的 4 个模块：产品、用户、订单、购物车，定义数据模型
- 创建不同模块之间数据转换函数
应用层处理数据：副作用 -> 纯函数 -> 副作用
- 检查购物车的状态（副作用操作获取一些数据）
- 调用购物车更新函数，将要添加的商品传递给它（对数据无副作用转换）
- 将更新后的购物车保存在存储中（执行副作用操作来存储或传递结果）
相关链接
玉伯的产品思考：技术人如何做产品
产品/方法论
玉伯虽然是一个技术大佬，但本质上我觉得他是一个产品人，在阿里期间领导的 Ant Design、AntV、语雀都是很出色产品，这篇文章也是玉伯对技术人如何做产品的一些指导
技术人如何选择产品方向？组织能力的杨三角理论
- 愿不愿意
- 有没有能力
- 容不容许
在应用杨三角理论的时候，要避免三个误区
- 团队有意愿，但是市场或者公司环境不容许
- 以为会，但实际不会
- 短期有激情，长期无热情
技术人做产品，需要扬长补短
- 如何扬长？
- 对代码的抽象思维能力应用在产品设计
- 通过代码快速验证
- 程序员更懂程序员的痛点
- 如何补短？
- 避免用户需求之坑：堆功能、赶超竞品...
- 避免产品实现之坑：100% 还原设计稿、过度追求技术细节
技术人做产品，就是做一个长期主义的事情，秉承着「西天取经」的心态
- 唐僧一样的创业，是你一开始在创业之前，内心就已经有了坚定的信念
- 你想去求真经，你的内心已经非常笃定，哪怕是你一个人也会去开启这段旅程
- 然后当你开启这段旅程之后，在这过程中去找到同路人，把合适的人凝聚起来形成团队
相关链接
我又听到人说：主要是人不行
事业/团队管理
当归因为人不行时，其实分两种情况：别人不行、自己不行，我们在很多时候说出的人不行，有没有可能是自己的能力不行，没有做好一件事的能力，所以也是在提醒自己
人性本来就是不可控的，如果用人性控制，知道你是懒散的，肯定不愿意认真付出，所以引出一个团队管理的方式：流程控制 > 人性控制：流程弥补能力不足，设置一个流水线，随着预设的轨迹被迫走一圈，强迫你从一个不足的人变成一个人才。某一天和同事聊到我们现在工作量大，需求反复变更，研发不断返工的问题，说到底还是从上层没有建立一个合理的研发流程制度，或者是有制度但没有执行，想要彻底解决，还需要从上层领导的流程设计入手
相关链接
短篇小说《蛋》
文学/短篇小说
一篇很有意思的关于人生观的讨论，每一个人都是自己，从这个角度看我们现在的工作、学习、生活，不是在了解新的东西，而是在不断的找回，所以生活中也才会有那么多的似曾相识，好像来过的街道，似曾相识的路人
另外还在网上看到一个观点，如果自己的生活中每个人都是自己，那自己完全可以不用在意别人看法、言论、批评，因为我现在生活的目的，就是为了做更好的自己
相关链接