目录

服务端服务：

  • 横向抽象服务：数据输入服务（管理后台或客户端）、数据输出服务（页面站点或客户端）
  • 纵向具体通途服务：web服务、接口数据服务

web服务

  • 面向客户的企业或产品门户站点（如公司主站、电商网站等）
  • 面向客户的管理后台（如企业邮局客户管理后台、移动互联网如各种平台后台）
  • 面向产品内部管理后台（如运营、运维支持后台）

web服务开发实现：

web精品开发，高大上的界面，友好的操作，满足用户基本需求的功能，高并发可扩展、易维护，前期产品设计或需求收集分析，熟悉业务并反复推敲，UI设计，界面风格确定，出图切图静态输出，技术架构、前后端框架选型，功能模块设计确认、划分，计划排期，任务调配等；

接口数据服务

  • 面向客户端（桌面或移动）、第三方服务（也可以为web逻辑数据及页面渲染分离服务）

接口数据服务开发实现：

接口数据服务相对于web服务少了前端渲染，约定格式数据输出即可； 接口数据开发比起web服务更注重协议请求细节、要求数据灵活传输、保证单点高并发、考虑数据结构缓存、设计数据安全访问方式、注重请求输入及响应输出约定，保证功能同时易扩展且兼容、关心文档完整性、预留调试日志、提供数据统计及时发现接口问题等；

服务端参与产品开发过程

传统互联网产品

产品策划：公共资源，专员负责产品规划；

技术项目：产品专职技术开发团队，负责产品功能需求开发及维护；

UI 设计：公共资源，专员负责单一产品UI设计甚至有UI负责切图及静态输出；

质量管理：公共资源，专员负责单一产品需求预过滤、产品每期功能及性能测试；

过程管理：公共资源，监督及协调产品项目进度、外部资源需求或配合；

运维管理：公共资源，专员负责产品线上运维；

移动互联网产品

移动互联网日新月异，要求产品快速迭代驱动产品迅速成长占有市场份额；

对于产品技术不再是主导，技术是实现产品的一个过程，产品有品牌，
品牌的树立与宣传需要产品、商务、市场、运营的拓荒、运作、内外结合；

但带责任的技术、靠谱的技术、争上的技术是产品的一个必要条件，是木桶的一个木板，不可或短；

快速迭代要求能快速调动所需资源，所需资源可快速做出响应，产品奉献人员对产品有主人翁精神，
让奉献人员以产品为荣，做好产品，好产品赋予他们物质及精神方面的奖励，良性循环，调动人员积极性，专心为产品服务；

这几年移动互联网产品如雨后春笋，单一产品创业公司如同精锐麻雀五脏俱全，快速部署，快速响应，灵活操作，行动迅速，步伐小但推进速度迅速，也容易迅速回滚修正继续前进；

参与产品过程

1、主要技术负责人参与立项及需求分析，由产品策划、主要技术、主要测试、
    项目管理或公司高层参与讨论重要性、紧急性、可行性等；
2、主要技术负责人参与需求整理确认；
3、产品策划及技术负责人协调以下职责：
    UI设计、切图、页面布局静态输出、交互组件编写、后端数据逻辑设计、底层数据存储设计、
    框架扩展预留、开发实现、全局缓存设计、负载均衡考虑、文件存储及分发设计、
    数据安全访问、热备方案、大数据历史数据、自动化测试编写、bug修复自测等；
4、开发期间产品策划收集新需求及反馈；
5、开发自测及调整；
6、提交测试；
7、一轮测试（提测当天超出要求则打回由开发自测及再调整），准备下一期需求分析；
8、安排修复bug及调整；
9、二轮测试；
10、安排修复bug及调整；
11、三轮测试；
12、出测试报告；
13、协商是否需要去除功能点或功能点下期上线，或保证完整功能延期上线；
14、产品验收
15、安排上线及线上跟踪测试一段时间
16、产品运营推广及收集反馈

编码以外考虑

1、关注服务器的硬件及部署，考虑cpu、硬盘、内存、带宽等使用情况，
比如cpu对一些加解密、转码等耗时操作，比如文件系统对硬盘的要求，
比如缓存数据对内存的要求，比如大并发对带宽的要求；

2、关注数据库设计及协议的设计，考虑逻辑模式设计、数据库物理设计、结构设计、
行为设计，包括文件类型、索引结构、数据存放次序、位逻辑、存取方法和存取路径等；
在物理层的基础上考虑协议设计；

3、关注访问效率，测试页面加载效率、每个接口的访问瓶颈，对业务服务分离，前端文件、
数据加载源分离，逻辑服务器及文件服务器分离，公共资源合并，优化网络传输数据，
优化压缩输出，保证页面及时加载，接口数据及时响应；

4、关注持久化及缓存，数据库的支持不足够时，首先考虑的缓存，全局缓存，
前端缓存或后端缓存，需要用什么hash算法，用什么缓存，如何查询才能更好命中缓存，
数据更新时，缓存数据如何更新，如何保证不遗漏或不出现脏数据，缓存数据生命期，
是否需要定期删除缓存数据等；

5、关注统计数据，运营统计数据属于产品内部需求，统计一般采用访问分析日志之类，
可能设计到各种perl、py、shell脚本，也有在日志逻辑前设计好相关统计记录，
方便后期二统计数据二次挖掘等；

6、关注兼容，web服务注重前端兼容主要平台、主要浏览器内核，接口数据服务不像web服务
可以为随时更新一份代码，客户端需求累积越来越多，可能出现多个版本，
需要考虑版本如何兼容或考虑实际业务情况对版本分离访问；

7、关注日志记录及调试，内部预留调试入口及调试开关，方便随时调试异常操作及异常数据，
关键代码做异常捕获，异常日志预记录，方便后期线上数据异常甚至性能瓶颈分析访问过程，
特别是与金钱交易相关的服务；

8、关注数据安全，至少考虑服务自己一个加解密算法，至少为接口给一个签名机制；

9、关注重构，在业务庞大后，可能会考虑新开发或重构，使得后续功能易开发、现有功能易维护，
考虑逻辑模型层或是数据存储层是否重构，对于重构，测试特别重要，需要很熟悉业务，
测试用例很全的测试集来保证重构后的正确性；

...

存在问题

1、产品快速成长，部分需求急于确定并实现；

2、插件量的要求，部分插件快速实现基本功能；

3、项目管理催促，仓促提交测试修复；

4、底层存储设计马虎，把关不严；

5、开发内在原因加上以上原因，底层数据部分结构不佳，中上层建筑结构复杂不清晰，不易维护；

6、快速迭代期间开发常陷入完成功能泥潭，较少时间思考、学习、吸收，眼界受局限；

7、上下目标不一，企业版实现初期，只满足基本要求，功能满足的情况下，
在性能及分布扩展方面投入人力等资源少，可后期投入资源深度开发及优化，
让产品从可用到易用再到自助使用；

8、对内服务桌面客户端接口服务，前期业务生疏，中间业务需求快速堆叠，
业务逻辑甚至存储层结构不清晰；

9、服务多，在各项目之间切换排查问题，实在是需要开发保证时时刻刻脑袋相当清醒；

10、根据以往及他人经验判断产品成型发布后，会在一段时间内陷入调整期及问题修复泥潭，
同时产品必须继续前行，需要有人坚守战场断后，更需要有人继续带着产品前行；

努力方向

1、加强开发人员、测试人员对产品业务了解，快速进入轮转阵营，
开发人员努力成为全能轮岗人员，测试人员使用更简单、更巧妙、更有力的测试方式，
减少不必要的因业务不清楚的bug发布及简单业务的不必要打扰；

2、编程方面，编程程度参差不齐，编码风格各异，统一稳定框架、代码风格约定，
提高review频率及细度，提高代码质量；

3、服务端开发，有UI设计、技术开发，但在web页面布局及交互设计上缺少专职人员，
技术开发实现页面布局及交互，耗时且不专业，努力外部寻求或内部培养专职负责人；

4、在运维方面，异地机房灾备、大并发处理、大数据存储及数据统计缺少经验，
寻求运维协助及外部大牛协助指点，内部分享及挖掘；

5、明确开发任务需求及实现程度、粒度细分，将需求分析环节从开发环节剥离，
支持快速迭代；

6、熏陶提高全员产品话语权、产品知情权、荣誉感、积极性；

7、开发、技术支持、运维任务责任区分或采用轮岗，提高开发、支持、运维效率；

8、重点分支投入重点资源，优先完成重点精品分支，加强自动化工具的使用；

9、胆大的带动胆小的，保守谨慎的拉住开放大胆的；

成长目标

产品的高层建筑高大上

产品的底层建筑靠谱健壮

产品的关键点螺丝钉、帽，起四两拨千斤作用

产品一键开通接入即服务

产品横向服务扩展，延伸更多利于开发者的服务，实现更多服务点及赢利点

@tsingchan 2015