一次产品重构的复盘
本文深入复盘了一次完整的产品重构过程，明确了重构的时机和阶段性目标。重构中主要解决了架构混乱、性能瓶颈和用户体验不佳等问题。具体操作包括重构代码模块、优化数据库查询、引入缓存机制，并通过用户行为数据来调整功能细节。作者还提出了应对重构风险的方法，如建立测试闭环、逐步发布和快速响应用户反馈，以确保重构效果和产品稳定性。
相关分享
IM系统重构到 SDK 设计的最佳实践
本文介绍了 CIM 系统重构为 SDK 的实践，使用 Builder 模式创建客户端，实现了长连接、心跳检测及自动重连等功能，极大简化了消息收发流程。还优化了请求代理，通过 `ProxyManager` 动态管理 URL，提升了代码复用性。集成测试涵盖多服务器重连和消息验证，确保系统高可用性。重构增强了模块间解耦，使 SDK 更易于维护和扩展。
无图
对“技术质问产品的几个常见问题”的回答
给某大厂的技术新人做了一个关于产品思维的分享，提前收集了一些困惑，贴几条提及最多的，稍微聊一下。
哦对了，先帮产品说句话——技术同学，千万别简单地用“那个产品是傻X”来回答以下问题。这是因为，作为技术，如果你总觉得和你配合的产品都是傻X，那大概率，别人会觉得你也是——要不然，为什么选择与傻X共事？所谓 “若，我看周围皆傻X，料，世人看我亦如是”。
无图
腾讯云日志产品CLS使用以及成本控制的最佳实践
日志成本控制主要有如下几个维度：- 减量：去掉没有意义的无效日志，只打印关键日志。- 减周期：尽可能减少日志存储的时长。- 转低频：低频相较于标准存储，可降低 6 0%--70%的成本。- 慎开全文索引：全文索引将会把所有日志全部索引一遍，并且这个存储是未压缩的存储，如果开启全文索引，则存储往往会比不开的存储高出 4--10 倍。
无图
使用jscodeshift做自动化重构
在这篇文章中，我们从一个简化了的实际例子出发，描述了为何jscodeshift在某些场景下可以提供的帮助，比如降低大型修改可能带来的影响（而如果影响不可避免，那么如何使其变得不那么痛苦）。随后我们描述了jscodeshift中的一些基本概念和基本的工作方式，并结合之前讨论的例子实现了部分的自动化重构。
无图
常见代码重构技巧（非常实用）
项目在不断演进过程中，代码不停地在堆砌。如果没有人为代码的质量负责，代码总是会往越来越混乱的方向演进。当混乱到一定程度之后，量变引起质变，项目的维护成本已经高过重新开发一套新代码的成本，想要再去重构，已经没有人能做到了。
无图
张一鸣：给产品技术人才的建议
这是张一鸣多年前的一篇文章，彼时的头条还是个小公司，还在为招募人才发愁。
这篇文章对互联网产品技术人才如何选择公司，提出了很好的建议，互联网行业选择远比努力重要。
干货一篇，值得深读，全文如下：
无图
无图
产品经理应该了解的CMMI模型
产品经理学习CMMI，一方面是学习CMMI解决软件问题的方法论，另一方面是了解主流的软件开发流程，方便协调产品和项目开发。本文作者从CMMI的基本概念出发，对CMMI的级别和发展现状展开了详细的介绍，与大家分享，希望通过此文能够加深你对CMMI的了解。
在软件开发中，约束软件项目的三个要素是质量、进度和成本，被称为软件开发铁三角，软件开发总是在这三个要素中妥协平衡，不时要抉择保哪个牺牲哪个，不断在刀尖上跳舞。而决定质量的要素又有三个：人、过程和技术，其中CMMI主要关注过程的改进。
因为CMMI有一个基本的假设前提：产品的质量很大程度上受影响于所使用的开放与维护过程的质量。所以为了改进产品质量，需要改进过程质量，称为过程改进。
无图
无图
产品运营系列：现状跟踪，指标统计
跟踪产品和业务的状况，对整体情况，有一个客观的判断，才能支持下述决策：
1、发现风险：哪个地方，出现风险之前，细微的指标，都有反映，有的剧烈、有的微弱；
2、业务预测：预判业务的增长规模，以及需要提前准备的资源（人力、资金）等
支撑决策：发现业务的客观规律，获取客户/用户的反馈，支持科学决策。
上面所有的决策，都需要客观的跟踪产品和业务状况，都需要进行量化，也就需要指标，指标分为：
1、核心指标：真正的直接反应核心的供给、需求、利润、品质等情况；
2、关联指标：其他关联的周边指标，方便发掘潜在问题、增长点、改进策略等情况。
无图