关于平台研发的一些想法
最近公司研发部门提出了公司级技术平台的建设规划（下文以ABC平台指代），我将个人想法笼统地归结为七个问题，以自问自答的方式表述了对平台研发的一些个人见解，现分享出来供大家参考，欢迎讨论，欢迎拍砖。
首先列举出七个问题（欢迎大家分享自己的想法）：
•ABC平台是什么？近期、远期目标是什么？
•如何保证研发方向不偏离预定轨道？
•架构风格、技术选型等方面的倾向性指导意见有哪些？
•平台选用迭代的方式开发，模块的优先级应如何定义？
•针对平台模块，可否抽象出统一的作业指导说明书？
•平台模块可否委托研发？如何施行？
•ABC平台研发的产出是什么？除了平台本身还应该有什么？
下面我将依次作答，表述近期的思考结果并归纳为一个关键词。
问题一：ABC平台是什么？近期、远期目标是什么？
针对第一个问题，我提取“定位”作为关键词。
首先，ABC平台处于操作系统和基础环境之上，这里基础环境是Java、.NET、PHP或其它；其次，ABC平台（Platform）应该包含一个通用的技术框架（Framework）和一些通用模块（Component）；ABC平台与特定的业务领域相结合可以形成应用平台（例：针对“人力资源”进行领域建模，然后在ABC平台的基础上进行外延开发，最终形成人力资源应用平台）；应用平台提供二次开发支持（继承自ABC平台，可能包含泛化的成分），具体项目按现场要求扩展后形成应用系统。
在理想的情况下，业务部门只配备实施工程师不承担开发工作，因而ABC平台应该是“一组隐含层级继承关系的应用平台集合”，实施工程师在项目现场主要承担系统初始化相关的配置工作，其次是有限的二次开发定制。但现实和理想之间还有相当大的差距，所以ABC平台在近期只是“一个技术型的开发框架和一组可供自由装配的通用模块”，业务部门选用ABC平台可以节省相当一部分开发成本，但开发资源的投入仍是必不可少的。
问题二：如何保证研发方向不偏离预定轨道？
设当前位置为点A，近期目标为点B，远期目标为点C，两个箭头连起来即为我们的预定轨道。
我将箭头视作一条水渠，我们当中绝大多数人的任务在微观上看就是挖坑，按照点动成线的规则，坑挖够了渠也就修好了。前提条件是不能乱挖，乱挖一气莫说修渠，即便别人修好了也可能会挖断。
迄今为止，我们一直都在兢兢业业地“挖坑”，每个“坑”都挖得眉清目秀，可惜若以“渠”的标准衡量就惨不忍睹了，“眉清目秀的坑，惨不忍睹的渠”原因何在？我个人认为根本原因是大家眼里“只有坑而没有渠”，“坑”首先应该是“渠”的一部分，如果不符合“渠”的要求，再漂亮的“坑”也不是好“坑”。我们需要定义一个标准，说明什么样的“坑”是好的，每个挖“坑”的人在开挖之前不但要拿“坑的标准”严格要求自己，并且要把自己的“挖坑”规划拿出来集体评价，甚至是在“开挖”之后也随时展示“坑的进度”，看是否跑偏了（水渠要求坑深1米宽2米，当前状态是深2米宽1米，下一步还要计划深挖显然是不合适的）。
说了半天挖坑问题，再次回到ABC平台开发，我觉得保证研发方向的关键是“协作”，我们需要引入一套行之有效的协作模式并切实有效地贯彻执行（标准是死的，人是活的，标准可以变，执行是关键），这里的协作模式可以是业界流行的标准开发模式的变种（例如我们选择敏捷开发中的Scrum进行适度调整），具体如何尚需开发团队集体探讨。
问题三：架构风格、技术选型等方面的倾向性指导意见有哪些？
这里继续沿用问题二中“挖坑”的理念，我们需要明确“什么样的坑是好坑”，因而我选择“标准”用作问题三的关键词。
架构风格是描述某一特定应用领域中系统组织方式的惯用模式，附加上技术选型，我将其理解为倾向性的指导意见，具体条目仍需集体讨论，这里列举我个人的部分观点用作示例。
规约方面的倾向性意见：
1) 平台整体基于SOA设计，引入企业服务总线（ESB）；
2) 针对具体应用系统，采用分层架构风格；
3) 层次之间通过接口进行协作；
4) 层间传递的对象是为实体类，在规约层定义；
5) 实现层依赖于规约层，业务逻辑层的具体实现依赖于本模块相关数据层接口、实体类，与关联模块的业务逻辑层接口、实体类也可能存在依赖关系，不引用其数据访问层接口；
6) 作为消费者引用外部模块时，须在内部定义提供者接口（归属于业务逻辑层），然后针对外部模块按提供者接口标准设计专用适配器完成数据转换；
7) 层次之间采用IoC的方式实现整合；
8) 作为生产者对外提供服务时，须将服务接口封装形成应用支持SDK。
实现方面的倾向性意见：
a) 技术路线选择java，提供.NET应用支持；
b) IoC框架选用Spring；
c) 数据库以Oracle和Sql Server为主，预留扩展接口；
d) 数据访问层以Hibernate为基础进行封装实现；
e) 基于Web的前端展现以Extjs为核心，允许引入Jquery；
f) 浏览器和web服务器端的ajax交互以extjs的direct为主；
g) 为了增强用户体验，需统一界面风格和配色标准。
此外，诸如“分页查询的适用场景”、“存储过程的引入原则”、“事务控制的指导意见”、“安全通讯的备选方案”之类的指导意见库也需要不断的完善和丰富。
问题四：平台选用迭代的方式开发，模块的优先级应如何定义？
ABC平台的用户是业务部门，基于ABC平台开发的应用系统才会面对真正的终端用户，为了“在达成最终用户要求的基础上降低个人工作强度”，实施工程师必然会综合考虑最终用户的“应用级”需求，传递到平台研发这里，形成了平台开发要求。这里我没有使用“需求”，因为用户提出的永远都是要求，需求是由项目组相关人员分析获得的（个人观点），提交用户确认的需求分析报告中已经包含了功能优先级的定义。
由于着眼点的不同，开发团队和用户理想中的功能模块优先级很难获得统一。用户采用“哪个先上线带给我的好处最多”来判断，而开发团队则用“如何安排次序最能节约研发成本”来评判，最终的选择结果一般是二者相互妥协的折中。
对于ABC平台的研发，我觉得可以尝试考虑“最小可用版本包含什么功能”、“再扩大一下范围呢”、“先不做aa，直接做bb，能否满足可用要求”这几个问题来定义模块优先级。显而易见，业务部门眼里的“最小可用版本”应该不会包括系统服务总线，这就是冲突，需要讨论，需要权衡。
本节关键词：权衡。
问题五：针对平台模块，可否抽象出统一的作业指导说明书？
作为具备多年实践经验的软件工程师，我们都熟悉软件工程中定义的开发方法和开发流程，然而直接用作平台模块的作业指导却显得过于遥远，虽然我们理应遵循软件工程的各项原则，但我觉得依然需要一个可行性较强的作业指导说明书作为补充，或称之为操作指南。
我尝试着为这个操作指南罗列了如下条目（当然，若真的施行，还是需要研发团队集体的力量）：
1) 模块需设置“产品经理”之类的岗位角色，对整体功能和研发路线负责；
2) 产品经理主导需求调研和分析过程，是需求规格说明书的责任人；
3) 模块的技术架构遵循统一的平台标准；
4) 模块首先确定其功能定位和设计目标；
5) 模块第二步要明确的是关联系统和交互接口；
6) 将模块需求分类，为非通用需求设置辅助工具单独设计；
7) 模块内部功能细分形成逻辑独立的子模块，按实际需要提供剥离支持；
8) 外部接口的定义和伪装实现优先于内部设计；
本节关键词：指南。
问题六：平台模块可否委托研发？如何施行？
对于不能直接产出利润的平台研发，公司的资源总是紧张的，人手总是不足的，除了补充人员之外，我们可否选择委托研发呢？这里我没有使用“外包”，因为委托研发除了外包，还有“交由业务部门自行设计开发”的一层意思，而且我个人认为编码实现外包是可以的，而系统设计最好在公司内部实现，至于具体模块的产品经理（Product Owner）必须是内部人员。
委托研发的核心思想是研发任务“分流”，而工作“分出去”的重点在于如何“收回来”，这就需要制定一套评价体系（就是问题三的输出结果）用作任务回收时的验收标准，向业务部门分派任务时申明验收标准（他们无须理解水渠的规划，只需保证挖的坑符合特定要求即可）并附带作业指导说明书（诸如“如何挖坑更省力”、“论铁铲和头在挖坑工作中的效用”之类的东西），只要业务部门遵循这些规范进行开发，最终就可以顺利地纳入ABC平台达到“水到渠成”的效果。
本节关键词：分流。
问题七：ABC平台研发的产出是什么？除了平台本身还应该有什么？
虽然我们当前的主要任务是研发一个切实可用的优秀平台，但本着效用最大化的原则，还应当考虑一下平台研发的附带产出。对于这个问题，我首先想到的是“锻炼队伍”，后来又归纳出了“求渔”一词。
话说“授人以鱼不如授人以渔”，这是从赠予方的角度解读的，假设我们是接受方呢？于是想到了“求渔”一词，然后ABC平台在我眼里就成了一条鱼，如果通过这次捕鱼（不挖坑修渠，改结网捕鱼了）的经历进行有意识地总结，提升到渔的境界岂不更好？我们总结一套适合公司现状的行之有效的系统开发规范，新成员加入时首先参加流程培训，而后即可以最快的速度融入团队开发，虽然这些已经超出了ABC平台的范畴，但我还是觉得非常有必要分析讨论一下。
本节关键词：求渔。
最后总结一下，我对平台研发的个人想法主要集中在“定位”、“协作”，“标准”、“权衡”，“指南”、“分流”，“求渔”七个关键词上，或有词不达意之处，仅供参考，欢迎拍砖。
本文由Markcxz（丛兴滋）撰写于2011年11月，最早发布在其个人博客http://markcxz.cnblogs.com上，转载请注明出处。
本文pdf下载：http://files.cnblogs.com/markcxz/abc_Platform_2011-11.pdf
关于平台研发的一些想法
首先列举出七个问题（欢迎大家分享自己的想法）：
•ABC平台是什么？近期、远期目标是什么？
•如何保证研发方向不偏离预定轨道？
•架构风格、技术选型等方面的倾向性指导意见有哪些？
•平台选用迭代的方式开发，模块的优先级应如何定义？
•针对平台模块，可否抽象出统一的作业指导说明书？
•平台模块可否委托研发？如何施行？
•ABC平台研发的产出是什么？除了平台本身还应该有什么？
下面我将依次作答，表述近期的思考结果并归纳为一个关键词。
问题一：ABC平台是什么？近期、远期目标是什么？
针对第一个问题，我提取“定位”作为关键词。
首先，ABC平台处于操作系统和基础环境之上，这里基础环境是Java、.NET、PHP或其它；其次，ABC平台（Platform）应该包含一个通用的技术框架（Framework）和一些通用模块（Component）；ABC平台与特定的业务领域相结合可以形成应用平台（例：针对“人力资源”进行领域建模，然后在ABC平台的基础上进行外延开发，最终形成人力资源应用平台）；应用平台提供二次开发支持（继承自ABC平台，可能包含泛化的成分），具体项目按现场要求扩展后形成应用系统。
在理想的情况下，业务部门只配备实施工程师不承担开发工作，因而ABC平台应该是“一组隐含层级继承关系的应用平台集合”，实施工程师在项目现场主要承担系统初始化相关的配置工作，其次是有限的二次开发定制。但现实和理想之间还有相当大的差距，所以ABC平台在近期只是“一个技术型的开发框架和一组可供自由装配的通用模块”，业务部门选用ABC平台可以节省相当一部分开发成本，但开发资源的投入仍是必不可少的。
问题二：如何保证研发方向不偏离预定轨道？
设当前位置为点A，近期目标为点B，远期目标为点C，两个箭头连起来即为我们的预定轨道。
我将箭头视作一条水渠，我们当中绝大多数人的任务在微观上看就是挖坑，按照点动成线的规则，坑挖够了渠也就修好了。前提条件是不能乱挖，乱挖一气莫说修渠，即便别人修好了也可能会挖断。
迄今为止，我们一直都在兢兢业业地“挖坑”，每个“坑”都挖得眉清目秀，可惜若以“渠”的标准衡量就惨不忍睹了，“眉清目秀的坑，惨不忍睹的渠”原因何在？我个人认为根本原因是大家眼里“只有坑而没有渠”，“坑”首先应该是“渠”的一部分，如果不符合“渠”的要求，再漂亮的“坑”也不是好“坑”。我们需要定义一个标准，说明什么样的“坑”是好的，每个挖“坑”的人在开挖之前不但要拿“坑的标准”严格要求自己，并且要把自己的“挖坑”规划拿出来集体评价，甚至是在“开挖”之后也随时展示“坑的进度”，看是否跑偏了（水渠要求坑深1米宽2米，当前状态是深2米宽1米，下一步还要计划深挖显然是不合适的）。
说了半天挖坑问题，再次回到ABC平台开发，我觉得保证研发方向的关键是“协作”，我们需要引入一套行之有效的协作模式并切实有效地贯彻执行（标准是死的，人是活的，标准可以变，执行是关键），这里的协作模式可以是业界流行的标准开发模式的变种（例如我们选择敏捷开发中的Scrum进行适度调整），具体如何尚需开发团队集体探讨。
问题三：架构风格、技术选型等方面的倾向性指导意见有哪些？
这里继续沿用问题二中“挖坑”的理念，我们需要明确“什么样的坑是好坑”，因而我选择“标准”用作问题三的关键词。
架构风格是描述某一特定应用领域中系统组织方式的惯用模式，附加上技术选型，我将其理解为倾向性的指导意见，具体条目仍需集体讨论，这里列举我个人的部分观点用作示例。
规约方面的倾向性意见：
1) 平台整体基于SOA设计，引入企业服务总线（ESB）；
2) 针对具体应用系统，采用分层架构风格；
3) 层次之间通过接口进行协作；
4) 层间传递的对象是为实体类，在规约层定义；
5) 实现层依赖于规约层，业务逻辑层的具体实现依赖于本模块相关数据层接口、实体类，与关联模块的业务逻辑层接口、实体类也可能存在依赖关系，不引用其数据访问层接口；
6) 作为消费者引用外部模块时，须在内部定义提供者接口（归属于业务逻辑层），然后针对外部模块按提供者接口标准设计专用适配器完成数据转换；
7) 层次之间采用IoC的方式实现整合；
8) 作为生产者对外提供服务时，须将服务接口封装形成应用支持SDK。
实现方面的倾向性意见：
a) 技术路线选择java，提供.NET应用支持；
b) IoC框架选用Spring；
c) 数据库以Oracle和Sql Server为主，预留扩展接口；
d) 数据访问层以Hibernate为基础进行封装实现；
e) 基于Web的前端展现以Extjs为核心，允许引入Jquery；
f) 浏览器和web服务器端的ajax交互以extjs的direct为主；
g) 为了增强用户体验，需统一界面风格和配色标准。
此外，诸如“分页查询的适用场景”、“存储过程的引入原则”、“事务控制的指导意见”、“安全通讯的备选方案”之类的指导意见库也需要不断的完善和丰富。
问题四：平台选用迭代的方式开发，模块的优先级应如何定义？
ABC平台的用户是业务部门，基于ABC平台开发的应用系统才会面对真正的终端用户，为了“在达成最终用户要求的基础上降低个人工作强度”，实施工程师必然会综合考虑最终用户的“应用级”需求，传递到平台研发这里，形成了平台开发要求。这里我没有使用“需求”，因为用户提出的永远都是要求，需求是由项目组相关人员分析获得的（个人观点），提交用户确认的需求分析报告中已经包含了功能优先级的定义。
由于着眼点的不同，开发团队和用户理想中的功能模块优先级很难获得统一。用户采用“哪个先上线带给我的好处最多”来判断，而开发团队则用“如何安排次序最能节约研发成本”来评判，最终的选择结果一般是二者相互妥协的折中。
对于ABC平台的研发，我觉得可以尝试考虑“最小可用版本包含什么功能”、“再扩大一下范围呢”、“先不做aa，直接做bb，能否满足可用要求”这几个问题来定义模块优先级。显而易见，业务部门眼里的“最小可用版本”应该不会包括系统服务总线，这就是冲突，需要讨论，需要权衡。
本节关键词：权衡。
问题五：针对平台模块，可否抽象出统一的作业指导说明书？
作为具备多年实践经验的软件工程师，我们都熟悉软件工程中定义的开发方法和开发流程，然而直接用作平台模块的作业指导却显得过于遥远，虽然我们理应遵循软件工程的各项原则，但我觉得依然需要一个可行性较强的作业指导说明书作为补充，或称之为操作指南。
我尝试着为这个操作指南罗列了如下条目（当然，若真的施行，还是需要研发团队集体的力量）：
1) 模块需设置“产品经理”之类的岗位角色，对整体功能和研发路线负责；
2) 产品经理主导需求调研和分析过程，是需求规格说明书的责任人；
3) 模块的技术架构遵循统一的平台标准；
4) 模块首先确定其功能定位和设计目标；
5) 模块第二步要明确的是关联系统和交互接口；
6) 将模块需求分类，为非通用需求设置辅助工具单独设计；
7) 模块内部功能细分形成逻辑独立的子模块，按实际需要提供剥离支持；
8) 外部接口的定义和伪装实现优先于内部设计；
本节关键词：指南。
问题六：平台模块可否委托研发？如何施行？
对于不能直接产出利润的平台研发，公司的资源总是紧张的，人手总是不足的，除了补充人员之外，我们可否选择委托研发呢？这里我没有使用“外包”，因为委托研发除了外包，还有“交由业务部门自行设计开发”的一层意思，而且我个人认为编码实现外包是可以的，而系统设计最好在公司内部实现，至于具体模块的产品经理（Product Owner）必须是内部人员。
委托研发的核心思想是研发任务“分流”，而工作“分出去”的重点在于如何“收回来”，这就需要制定一套评价体系（就是问题三的输出结果）用作任务回收时的验收标准，向业务部门分派任务时申明验收标准（他们无须理解水渠的规划，只需保证挖的坑符合特定要求即可）并附带作业指导说明书（诸如“如何挖坑更省力”、“论铁铲和头在挖坑工作中的效用”之类的东西），只要业务部门遵循这些规范进行开发，最终就可以顺利地纳入ABC平台达到“水到渠成”的效果。
本节关键词：分流。
问题七：ABC平台研发的产出是什么？除了平台本身还应该有什么？
虽然我们当前的主要任务是研发一个切实可用的优秀平台，但本着效用最大化的原则，还应当考虑一下平台研发的附带产出。对于这个问题，我首先想到的是“锻炼队伍”，后来又归纳出了“求渔”一词。
话说“授人以鱼不如授人以渔”，这是从赠予方的角度解读的，假设我们是接受方呢？于是想到了“求渔”一词，然后ABC平台在我眼里就成了一条鱼，如果通过这次捕鱼（不挖坑修渠，改结网捕鱼了）的经历进行有意识地总结，提升到渔的境界岂不更好？我们总结一套适合公司现状的行之有效的系统开发规范，新成员加入时首先参加流程培训，而后即可以最快的速度融入团队开发，虽然这些已经超出了ABC平台的范畴，但我还是觉得非常有必要分析讨论一下。
本节关键词：求渔。
最后总结一下，我对平台研发的个人想法主要集中在“定位”、“协作”，“标准”、“权衡”，“指南”、“分流”，“求渔”七个关键词上，或有词不达意之处，仅供参考，欢迎拍砖。
本文由Markcxz（丛兴滋）撰写于2011年11月，最早发布在其个人博客http://markcxz.cnblogs.com上，转载请注明出处。
本文pdf下载：http://files.cnblogs.com/markcxz/abc_Platform_2011-11.pdf
关于平台研发的一些想法