打造一款互联网产品一般需要三种角色：产品，技术，运营。产品研究目标用户的需求痛点，将其转化成可实现的互联网产品。技术负责产品研发，将产品的需求文档转化成可上线运行的软件。运营是对互联网产品进行人工干预，让产品更好地为用户服务。说的简单一点，产品把东西想出来，技术把东西做出来，运营把东西用起来。由于职责分工不同，三种角色对互联网产品的视角并非完全一致，而是会存在一定的偏差。这种偏差经常引发他们之间互相伤害。作为一个程序猿，我觉得技术往往是最受伤的。运营说明天要做个秒杀活动，心情一下子就不好了；产品一句“需要得改一改”，想死的心都有。所以为了减轻技术的痛苦，我们有必要认真研究一下此事。

首先，提炼下三种角色的核心技能：（产品）想，（技术）做，（运营）用。从时间角度看，“做”的成本是最大的，当开始“做”的时候，技术是不喜欢“变”的。而产品喜欢想一些有创意的东西，即使有同类产品，也会绞尽脑汁想些差异性。对产品来说，“变”是必须的。运营则强调对产品的控制和驾驭，最好产品上所有的元素都是可控制的，其底层需求依然是产品是可“变”的。产品和运营对“变”的需求是技术痛苦的根源，破解之道就是以变制变，面向变化做技术设计。

对产品的需求做一层技术抽象，而非直接转化
一些初级程序猿在拿到产品设计文档时，喜欢直接转化，有时甚至把产品设计文档当成技术设计直接开发。这会导致一个严重的后果：技术就完全被产品牵着鼻子走，产品设计的任何改动都会映射到技术的改动。来看一个例子，假设产品提出这样一个需求：做一个学生列表页，可根据姓名和学号查询学生。直接转化这个需求，技术可能是这样一个设计。

1. list query(name,id);

复制代码

这样设计当然没问题，但这不是一个纯粹的技术设计，为什么？因为这个设计里有两个产品属性的东西：name（姓名），id（学号）。从技术视角看，这是一个查询需求，姓名和学号是两个查询条件。因此一个纯粹的技术应该是这样：

1. list query(conditions<k,v>);

复制代码

当作了一层的技术抽象后，可以满足产品更多变化的需求，比如上面这个需求，产品如果想增加对性别筛选，几乎不用改代码。

比产品多想一步，面向未来设计
对于上面的学生列表需求，一个更好的设计是这样的：

1. list query(conditions<k,v>, sort="id", dir="ASC", start=0, limit=0);

复制代码

sort表示排序字段，默认按学号排序；dir表示排序方向，默认正序排列；start和limit表示查询的记录位置和条数，默认返回全部查询结果。虽然需求并未说明是否要排序，是否要分页，但是作为一个查询问题，排序分页是基本需求。产品现在不需要，但未来可能会需要。当产品急匆匆地跑过来说加个需求，而你却很淡定地回他“已经实现了”，这种感觉非常棒！

请在设计之初引入运营变量
运营变量简单来说，就是可配置的变量，是写在配置文件中的数据。许多初级程序员都不擅长运营变量管理或者说配置管理，认为没必要引入配置，需要调整的时候，改下代码就可以了。但请注意，虽然改代码和改配置都能实现需求变动，但是这两者的性质是完全不同的：
（1）改代码是一次开发行为，改配置是一次运营行为；
（2）改代码要经过测试，上线操作才能达到目标，流程复杂，涉及的人工协作多；改配置即时生效，只需运营操作；
（3）改代码是技术承担责任，改配置是运营承担责任。

业务流尽可能灵活，不要固化
这个不太好实施，只能提供一些设计经验：
（1）多使用运营变量，而非HardCode
（2）架构设计时引入hook机制，在业务流上多引入hook点
（3）弹性设计，结构上可伸缩，业务上可扩展

打造一款互联网产品一般需要三种角色：产品，技术，运营。产品研究目标用户的需求痛点，将其转化成可实现的互联网产品。技术负责产品研发，将产品的需求文档转化成可上线运行的软件。运营是对互联网产品进行人工干预，让产品更好地为用户服务。说的简单一点，产品把东西想出来，技术把东西做出来，运营把东西用起来。由于职责分工不同，三种角色对互联网产品的视角并非完全一致，而是会存在一定的偏差。这种偏差经常引发他们之间互相伤害。作为一个程序猿，我觉得技术往往是最受伤的。运营说明天要做个秒杀活动，心情一下子就不好了；产品一句“需要得改一改”，想死的心都有。所以为了减轻技术的痛苦，我们有必要认真研究一下此事。

首先，提炼下三种角色的核心技能：（产品）想，（技术）做，（运营）用。从时间角度看，“做”的成本是最大的，当开始“做”的时候，技术是不喜欢“变”的。而产品喜欢想一些有创意的东西，即使有同类产品，也会绞尽脑汁想些差异性。对产品来说，“变”是必须的。运营则强调对产品的控制和驾驭，最好产品上所有的元素都是可控制的，其底层需求依然是产品是可“变”的。产品和运营对“变”的需求是技术痛苦的根源，破解之道就是以变制变，面向变化做技术设计。

对产品的需求做一层技术抽象，而非直接转化
一些初级程序猿在拿到产品设计文档时，喜欢直接转化，有时甚至把产品设计文档当成技术设计直接开发。这会导致一个严重的后果：技术就完全被产品牵着鼻子走，产品设计的任何改动都会映射到技术的改动。来看一个例子，假设产品提出这样一个需求：做一个学生列表页，可根据姓名和学号查询学生。直接转化这个需求，技术可能是这样一个设计。

1. list query(name,id);

复制代码

这样设计当然没问题，但这不是一个纯粹的技术设计，为什么？因为这个设计里有两个产品属性的东西：name（姓名），id（学号）。从技术视角看，这是一个查询需求，姓名和学号是两个查询条件。因此一个纯粹的技术应该是这样：

1. list query(conditions<k,v>);

复制代码

当作了一层的技术抽象后，可以满足产品更多变化的需求，比如上面这个需求，产品如果想增加对性别筛选，几乎不用改代码。

比产品多想一步，面向未来设计
对于上面的学生列表需求，一个更好的设计是这样的：

1. list query(conditions<k,v>, sort="id", dir="ASC", start=0, limit=0);

复制代码

sort表示排序字段，默认按学号排序；dir表示排序方向，默认正序排列；start和limit表示查询的记录位置和条数，默认返回全部查询结果。虽然需求并未说明是否要排序，是否要分页，但是作为一个查询问题，排序分页是基本需求。产品现在不需要，但未来可能会需要。当产品急匆匆地跑过来说加个需求，而你却很淡定地回他“已经实现了”，这种感觉非常棒！

请在设计之初引入运营变量
运营变量简单来说，就是可配置的变量，是写在配置文件中的数据。许多初级程序员都不擅长运营变量管理或者说配置管理，认为没必要引入配置，需要调整的时候，改下代码就可以了。但请注意，虽然改代码和改配置都能实现需求变动，但是这两者的性质是完全不同的：
（1）改代码是一次开发行为，改配置是一次运营行为；
（2）改代码要经过测试，上线操作才能达到目标，流程复杂，涉及的人工协作多；改配置即时生效，只需运营操作；
（3）改代码是技术承担责任，改配置是运营承担责任。

业务流尽可能灵活，不要固化
这个不太好实施，只能提供一些设计经验：
（1）多使用运营变量，而非HardCode
（2）架构设计时引入hook机制，在业务流上多引入hook点
（3）弹性设计，结构上可伸缩，业务上可扩展