My Blog.

home

hihi! have a good day! 👋

400

Who am i

  • 陈浩(hao), chinese, a coder

What I Writed

  • no-auto-test-dev-philosophyno-auto-test-dev-philosophy灵活 敏捷 迭代。 自动化测试 辩思 测试必不可少 想想看没有充分测试的代码, 哪一次是一次过的? 哪一次不需要经历下测试的鞭挞? 不要以为软件代码容易改, 就对于质量不切实际的自信---那是自大! 不适用自动化测试的case * 遗留系统。 * 太多的依赖方, 不想用过多的mock => 逻辑核心能力就是那些不容易测试的 * 大量依赖 第三方商业服务、自己的rpc服务/http服务 * IO 操作密集的 * 似乎很少有IO密集型的应用具备完善测试的 * (注意) 容易测试的一般是 无状态的(无IO状态的), 就内存中存储了状态 * 对应的代码在线上的时间比较短, 属于实验性代码。 * 越是早期, 自动化测试的必要性就越弱。靠手工测试就可以支持一定水平的质量。 无自动化测试系统设计方法论 这一切都需要 一点代价, 但是相对于 单元测试来说, 代价还是轻微很多。 无自动化测试, 也要关注可测试 * 模块、组件间的边界情况 * 使用 "谦虚对象" 设计模式来隔离可测试和不可测试的领域, 划定边界。 划分边界 注意耦合关系 需要更审慎的对对应的
  • NOTES-Minimal-MarketingNOTES-Minimal-Marketing\> Hint * 极简营销=差异化定位+品牌落地+增长黑客手段+数据驱动广告投放 * 定位落实差异化、品牌落实定位 * Promotion=反复沟通+更高声量+促销=传统广告(Advertising)、数字营销(Digital Marketing)、公共关系(Public Relations)和销售促销(Sales Promotion) * 品牌广告+流量广告: 突击品牌、常常流量。 看完书的提问&回答 市场洞察怎么做 * 使用PEST模型、SWOT 、波特五力模型、用户画像等模型分析 * 收集用户数据: 一手数据和二手数据。 * startup 优先使用二手数据(搜索引擎、付费资料)定性、定量, 然后在创新性领域使用一手数据(访谈、问卷)来帮助决策 * 定性和定量结合: 定性定方向挖掘未知、定量来辅助定性研究 * 产品 MVP 后: 大数据时代的追踪技术: 例如 AF、byteplus、mixpanel 为什么要差异化(只服务指定用户)&& 如何差异化 为什么只服务指定类型用户 用户需求的共性是很平谈的, 细分领域的用户需求更专化。而专化就是抛弃一部分其他的用户
  • yujun-product-philosophyyujun-product-philosophy更多: 俞军产品方法论 概要 认知体会 * [ ] 要素 和要素关系 快速迭代、数据、AB测试和正方面 AB测试是必须的,但不是万能的。 互联网在线产品可以很容易的通过信息服务或者市场反馈/用户反馈,更新产品内容(代码、UI)也很快,试错成本降低、让原本需要的"多年领域经验和懂技术"不再是必须的了。 标准化能降低门槛 从0到1的产品孵化,往往AB测试帮助较小,需要经济学、心理学等多领域的深刻认知,但是从1到10的产品调优,只要懂得控制变量法,产品的演进和优化就很容易了----当然这是非重大产品模块演化时。 如果每一件事都要做AB测试,很多事就做不了,容易形成依赖或者导致产品经理有目的地去挑选项目。 数据认知有限,只能反映过去,无法预知未来。当样本不足、实验目标过于复杂/大时,就不能使用AB测试. 重视体验 重视体验最好的方法,就是从产品经理的角度,以用户为中心,横向组织资源,按需求进行生产和销售 好的体验只是在一定程度上降低了用户的交易成本 用户是需求的集合 与其说抢占用户, 不如说抢占用户时间 或者说抢占用户需求点。 如果某个用户一个月有100次使用专车的
  • how-legacy-systems-drive-testinghow-legacy-systems-drive-testing摘要 说说常见遗留系统的变更难、系统脆的问题,并提出若干手段。 正文 功能测试是盾,只有它的保护,我们才能放心地对遗留系统动刀;而单元测试是刃,它撬动的不仅是遗留系统,更是遗留团队。 遗留系统问题 * 系统晦涩难懂,可读性可理解性很差。理解原有系统往往占据了进行一个修改的大部分时间。 * 系统设计僵化,改动困难,一个小修改,会迫使系统做很多部分的改动。 * 系统难以重用,大多软件单元缺乏可重用性。 * 系统脆弱,引入一个小功能会引入几个缺陷,修复一个缺陷又引起几个新缺陷。 投入大量人力,产生的价值却微乎其微。 测试ROI金字塔 如下图所示: 从上至下分别是验收测试、API 测试、集成测试和单元测试。 * 越往下测试粒度越来越小,测试数量越来越多。 * 越往上悲观路径覆盖率越来越低 通过提高验收测试的覆盖率,可以快速将系统的质量提升到 及格线以上。但是想要更高的质量保证, 需要更靠近"金字塔底层"。 -> 集成测试在功能保护上体现效果更快;而单元测试不仅仅有保证质量的能力, 还会驱动内部质量的提升。 Pasted image 20230924024957.