产品架构的好坏- 首先第一个问题就是你做的是class还是instance的问题 这更多是一种意识。如果做的是个instance那肯定毫无架构意识的做法， 这点要对需求和整体的结构有很好的理解，需求方总是无序的提一堆功能点， PM需要很好的格局和产品结构理解然后把有机的类子系统的概念把需求整合。 大致目的是做成class，一劳永逸，此类instance需求都从这个口子进和出。 实例比如我们最近刚做的一个“排行榜需求”，业务方的要求是要新增收入为算法的排行榜。 我们最后的结果是我们在已有的以点击数维度的“畅销榜”（特意使用抽象的名称）修改算法，增加收入维度的权重。而不是业务方提一个维度就上一个新榜单。 然后的问题是你的class怎么做的好 这点需要一定的技术理解能力，对产品本身的架构和业务很好的理解怎么区分哪些需求该怎么设计，这需要有一些技术能力的理解，需要了解数据基础层的结构，然后设计应用层的功能点。实际工作中会存在多点需求多种方式，就需要判断能力。 这点的判断基本上的原则是 首先要跟着产品的定位和战略要求清楚结构以便建设日后更好的支撑能力， 第二保证pm理解的耦合度，现在流行的设计包括腾讯的插件方式，其实也是产品架构 的良好极致表现。任何上下某功能不会影响到最基本的功能。