最小改动原则：拒绝重写，也拒绝"裱糊匠"式打补丁

在创业公司里，”重写”是不被接受的——大的重构无论从时间还是人力投入上看，一般都是承担不起的。即便雪球曾经历过一次把大一统服务Snowball拆分服务化的完整过程，但重新上一个新业务时，团队依然选择先做成一个大一统的服务，只是这一次会提前定义好每个模块的service接口，为以后可能的服务化预留退路——这条选择说明”曾经吃过拆分的苦”并不必然导向”以后每次都要先拆分”，评估标准始终是当下的现实约束，而不是过去经验的机械套用。但”不重写”不代表可以走向另一个极端——”裱糊匠”式做法（哪里有性能问题就加机器、加缓存、加数据库，有可用性问题就加重试、加日志，出故障就加流程、加测试）同样不是雪球团队的工作方式，因为这种做法只是不断在症状上打补丁，没有真正定位和解决问题根源，补丁越打越多，系统会变得越来越难以理解和维护。雪球采用的是介于两者之间的”最小改动”方式：准确定义问题、定位问题根源、找到问题本质、制订最佳方案，用最小的改动代价把问题解决到可接受的范围内——这条方法论要求团队先花力气把”问题到底是什么”这一步做扎实，而不是急于动手加机器加缓存这类表面手段。团队还有一条配套的经验法则：能用cache的地方绝不用DB，能异步的地方绝不同步（俗称”吃一堑，长一智”）——这不是一条抽象原则，而是从此前多次性能瓶颈（如注册压测中DB成为瓶颈）里反复验证出来的经验教训，直接指导了后续的具体优化方向。另外还有”特事特办”原则：业务在发展、需求在变化，实现方式也要跟着变化，对遗留系统而言，最佳的优化方案有时候就是砍需求——承认某些历史包袱不值得继续投入去优化，而是从根源上去掉这个需求本身。