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