3
阅文笔记（一）
source link: https://www.rowkey.cn/blog/2021/02/23/article-notes/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
阅文笔记（一）
Feb 23rd, 2021
Posted by 飒然Hang in
记录在阅读公众号、博客上一些好的文章时的笔记和心得。
《张一鸣：为什么 BAT 挖不走我们的人才？》
人成功了就会到处说自己多厉害，张一鸣自然有他的独到之处，但是这些东西可能也就适用于头条。
- 流程的好处与坏处：没有流程会乱，流程太多会束缚
- 优秀的人只需要原则即可
员工激励
- 最好的ROI，找优秀的人，干优秀的事
- 把更多的激励放到事后，放到年终，把更多的激励换成与个人贡献相关而不是与投资眼光相关。
- 公平理性按照岗位职级和绩效考核定薪酬
- 好的特质：满足感
《没有被了解的API？一个老码农眼中的API世界》
文章有点难懂，不过API的设计和实现确实是一个值得好好思考的事情。
API设计的经验性原则
- 功能的完整性
- 调用的简单性
- 设计的场景化：预期的场景用例
- 有无策略性的设置： 使用回调、虚函数、代理或模板等来实现调用者的策略设置
- 面向用户的设计：调用者编写函数名
不推卸责任
- 害怕设置策略，函数参数多达十个
- 牺牲可用性来提高效率
清晰的文档化
- 最不适合编写文档的人是API的实现者
- 最不适合编写文档的时间是在实现之后
- 确保文档是完整的，特别是关于错误处理的文档
API的人体工程学
- 一致性问题：相同顺序放置特定类型的参数；统一的错误处理
性能约定
分类
- 恒定的性能
- 通常的性能
- 可预期的性能
- 未知的性能
- 按性能划分API
- API的性能变化
- API调用失败时的性能
确保API性能的经验方法
- 谨慎地选择API和程序结构：考虑性能约定
- 在新版本发布时提供一致的性能约定
- 防御性编程
- API公开的参数调优
- 测量性能以验证假设
- 使用日志检测和记录异常
API设计的文化认知
- API的有意识训练
- API设计人才的流失
- 开放与控制
《疫情下技术的应对之道-成本篇》
最近公司也在做技术成本优化，这篇文章系统化地阐述了优化措施，给了自已一些思路。
- 考虑降本介入的时机：业务发展平稳期
- 统一思想：多部门配合，顶层推动，明确衡量标准，统一制定目标，分解KPI，分阶段落实
制定可量化的指标。目标一定要和业务结合起来。【这一点我之前忽视了，单单去追求价格了，其实应该和业务结合了】
- 电商：每订单IT成本
- 视频：用户在线时长与IT成本比值
- 游戏：收入流水与IT成本比值
- 制定目标后，纵向可以看每单位成本是否呈下降趋势。横向可以和具有相同业务模式的公司横向对比。
多维度分析钱花到哪里去了
支出构成，构成的比例是否合理
- 自建IDC：服务器、网络设备、机柜电力费用、专线、带款、备件
- 公有云：cache、DB、带宽、ECS（云硬盘、EIP）
供应商和分类维度
- 哪个类型的供应商支出最高
- 哪家供应商支出最高
部门和应用维度
- 哪个部门支出最高
- 哪个应用支出最高
成本优化原则
- 该节省的节省，该花钱的花钱，控制成本不能以牺牲稳定性为代价，切忌过度优化
- 抓大放小，从供应商、业务、资源等多个角度去看，哪里花钱多就先从哪里着手
优化实施
- 买便宜的东西。如在成本上升期指定采购框架，阶梯定价等
- 买合适的东西。制定标准，做相对最优的选择
- 用好已经在线的资源。提高已有资源的使用率
- 基于虚拟化、容器技术提高资源切分颗粒度，资源调度的能力，提升部署密度
- 架构优化，基础组件平台化、池化部署。提高资源复用程度，避免重复建设
- 基于工具化、智能化、可视化，保证成本优化能持续地、低成本地进行，要成为日常技术运营工作的一部分，一个常态。
《如果只定一个指标，研发的考核指标应该是什么？》
我自己的看法是如果不能衡量一个事物的所有方面，那么就不要衡量。但这篇文章在作者自己的场景下确实有它的适用之处
- 研发团队考核指标：是否完成JIRA上分配的关键任务，所有任务都是以两周为周期进行安排，基本完成记3分，彻底完成记5分，彻底完成而且有测试例验证，记8分。一个周期至多三个关键任务，一个季度按照总得分发放季度奖金。
理由
- 简单的原则：指标要简单
- 软件研发的核心问题是进度保证
- 鼓励团队最先去解决能提升公司价值和竞争力的问题
- 借助CICD等自动化工具保证代码质量。侧重于看测试结果、性能报告，以结果来驱动优化、驱动质量的提升
- 实事求是，一切都要有无可辩驳、可以查证的记录。任务全公司透明。
- 追求卓越。卓越用数字量化，用数字说话。
- 任何任务，产出或提交产物需要定义清楚，软件研发的提交物应该明确包括API与测试用例。
《美团张川：做了8年平台，我总结了平台的5道坎》
https://mp.weixin.qq.com/s/bwcJGpR2iwai-LJY0sMoew
对平台的阐述确实有独到之处：能做大的平台都需要动态不平衡。低频需求靠广告，高频需求靠补贴。
动态不平衡形成真正的平台
- 不会产生单个用户和单个服务提供者在一段时间内多次达成同一个交易的过程
陷阱：表面看上去是动态不平衡，实际上是平衡的
- 初始不平衡，结尾平衡：家教、美容美发->标准化服务、拆细服务
- 平台专家: 专家和普通服务者差距不大的服务，专家服务标准化
标准化决定平台大小
- 判断服务是否可以标准化：服务的体验可以一致化，客户的评价可以标准化
- 把不标准化的服务变成标准化的服务;在不标准化的服务上形成平台
- 把复合型的服务拆解开来，变成一些可以标准化的分步骤
- 不做交易的平台，做信息的平台
高频打低频是误解
- 高频不能带动低频，或者说高频带动低频不太明显：高频带动中频，形成巨大的用户平台，然后优化低频体验
- 高频服务靠补贴，低频服务靠长期广告
- 多个低频可以聚集成高频
- 低频服务很难出现好的产品经理
供给端的效率高，平台价值大
- 短期看需求，长期看供给
两个方向
- 供给是不是可以大批量供给，并且接近于无限供给
- 是不是平台提高了供给端的效率，让供给端能赚到钱
三个关键点
- 供给的快和慢
- “供大于求，供不应求”
- 没有稳定供给的市场，不会是一个巨大无比的市场
商业模式：剃须刀还是电冰箱
- 剃须刀（LTV，生命周期总价值）vs 电冰箱（CAC，用户获取成本）
- 关注NPS（净推荐值），客户推荐的概率。在低频业务里面降低CAC（获客成本），在高频业务中提升LTV（生命周期总价值）
《翻译漫谈 - 地道中文怎么写？英中翻译要避免哪些坑？》
所谓的英式中文，每次读到真的是觉得很别扭。本文则讲述了如何避免这些情况。
与字对字翻译有关的问题
- 避免不必要的主谓语分离，不要在中文中使用类似「As a…, he is…」的句式。
- 避免在翻译「When/After…, …」时，用「当……，……」的句式。
- 「while」「though」的翻译
- 很多情况下，「you」「your」都不必要翻译成「你/您」「你/您的」
- 翻译「such as…」「…like…」 以及写作中文的时候，除非后面举例的内容很长，否则请避免使用「……，比如……、……、……。」的句式
- 在使用/翻译术语时避免生搬英文字面意思，而是要通过调研市场以及中文语言环境，找到最合适的地道中文词
与中英文语法/表达习惯有关的问题
- 避免泛泛地使用「……之一」，列举确定数量的事物之一时除外
- partly because of」不要翻译成「部分原因在于」或者任何带有「部分」的形式
- 尽量少用被动句式，因为地道的中文里并没有太多被动语态
- 尽量避免「万能动词＋抽象名词」的句式
- 复数的处理： 中文并没有单复数变化，我们会在名词前加上「许多」或是数量，甚至不加修饰只透过前后文来强调复数，而不是加上「们」
- 中文写作时要避免受到英文习惯的影响： 英文经常会用设问句式来启发用户阅读后文，而中文会更多使用清晰肯定的陈述句。
好的翻译Tips
- 目标语言（target language）语感（即直接、迅速地感悟语言文字的能力）好，知道什么样的句子/表达是好的/不好的，知道什么样的内容需要对应什么样的语言风格，写作有逻辑，用词丰富
- 源语言（source language）语感好，能分清句子（尤其是长句/复杂句）结构、拆分意群
- 善用工具，包括辞典、搜索引擎、计算机辅助工具（CAT）等等，寻找最准确、最适合所译内容的词汇和表达
- 不做字对字的翻译，译文没有翻译腔，即在理解源语言文本所蕴含意思的基础上，摆脱源语言的句子结构、表达习惯，灵活运用目标语言，准确恰当地表达原文含义
《聊聊数据库的未来，写在 PingCAP 成立五周年前夕》
网红数据库TiDB的创始人写的关于数据库的未来。总体就是数据库越来越智能，无须再担心分库、分表的问题
- Single Source of Truth： 数据贯穿在应用逻辑各个角落，系统中对于任意数据的存取都应该是可以不加限制的
数据是架构的中心
- 系统=业务逻辑x数据
以分布式数据库为统一中心的架构
- 整个架构的中心是一个场景覆盖度足够广，且具有无限的水平伸缩能力的存储系统。大部分数据的流动被限制在这个数据库内部，这样应用层就可以几乎做到无状态，因为这个中心的数据库负责了绝大部分状态，每个应用可以通过自己的缓存来进行加速。
- 缓存层需要离业务层更近
未来
- 弹性调度会是未来的数据库的核心能力
- 下一个阶段是智能
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK