那个架构师带来的东西

….自从我们的架构师来了以后，之前的坑都被捋平了……——一个技术主管说的话

这篇文章的起源是这周三去分公司交流技术。作为与会人员中唯一一个产品（唯一一个不懂技术的），看着满眼技术名词的PPT，听着分公司新来的架构师侃侃而谈着天书，倒是意外的听出了点不同味道的内容。

分公司与我们不同从事的完全是互联网产品的工作，主要是通过APP和平台的形式为护士做宣教以及辅助工作。由于它们依托了全国某护士教育杂志，所以在护士人群中的推广天生获得了不少的优势。但是在产品起步的阶段，他们的技术却使用了类似于我们这样的医院级产品研发的模式。因而暴露出了非常多的问题，简单的说就是，模块耦合度高，产品漏洞多，数据库效率低，冗余数据多以及难以更新新的框架和技术。

分公司的这些苦恼随着他们的架构师的到来而烟消云散。虽然大家没有明确介绍，但是可以推断这是一个前淘宝员工。他将淘宝处理电商交易的各类框架和各类服务都完美的移植到了分公司的产品中。我大致能理解的几点包括引用淘宝的前端架构通过自己的改写，优化产品界面MVC的开发过程，引入HSF服务，建立大数据服务中心为数据的激增未雨绸缪，建立运维中心完善日志系统来保证产品的可靠性等。从一个产品经理的视角，我不想过多的探讨技术层面这样的改动是不是能带来多大的变化，我更关心的是他带来的整个体系。

首先是研发层面，严格的执行敏捷开发，将产品拆分成微小化模块。通过大范围引入成熟框架的模式，优化代码和开发效率。这样的好处有几点：应用敏捷开发，逼迫产品经理在设计上精简每一期的需求，将过去大而全的产品设计转变成小而精的模块设计；由于产品的迭代速度加快，倒逼技术设计上降低模块的耦合度，因为任何bug和升级可能会由另一个团队完成甚至是在不知道第几个轮回中去做，必须要划清界限否则就会锁死；利用成熟框架，降低开发人员技术上带来的差异，同时大幅度提高代码的整洁率；

其次是数据层面，未雨绸缪的建设大数据中心，在数据量还没有很大的时候就开始应用大数据服务，这样的好处也是显而易见的，首先是将建设难度提前，在数据量小的时候虽然大数据服务的效果不明显，但是同时也将失败时的成本降低；让技术人员提前习惯大数据服务，因为一般的技术人员还是停留在传统数据库的模式下，对大数据中心需要时间理解和接受；强制重新设计数据结构，借机消除之前遗留的数据库问题；

最后是运维方面，通过建设完备的运维中心，一方面可以提供完备的日志系统来检测产品的运营情况，避免了现有产品不规范的日志带来的出现问题难以追溯的现象；另一方面，完整的运维中心能够更加明确产品的运营方向，以及产品的迭代服务整个产品生命周期，而不是简单的依赖产品经理或者领导拍脑袋决定方向。

我目前负责的应用是一个基于IBM Watson for Oncology的SaaS平台，虽然我们最终服务的终端客户是医院医生，是需要接入医院信息系统的产品，但是嵌入的过程是依托于公司的另一款开放交互平台，所以依然具有非常高的互联网性质。在设计产品的初期，我分析了IBM WFO产品本身具有非常高的更迭率，而且它是一个在垂直层面推进的产品，所以我也把垂直深度发展作为了我们产品的主要方向，并没有扩展太多的模块来拓展横向服务。因而产品只有一个核心（IBM Watson for Oncology)和3个服务（接入平台、计费、管理）。但是即使这样，我也发现在产品更迭时受到了极大的限制，主要是数据库的字段变化，模块单独更新的兼容性，接入平台版本不同的兼容性等问题。当然我遇上这些问题的主要原因是这个产品并不是公司的主线产品，在开发上只能够通过共用资源的方式来完成，包括架构师也只能是兼顾这个产品，所以更多的是依靠借助已有产品架构的形式来完成，这就会导致经常采用不适合互联网产品的工具和体系来开发。只能说在内心上好希望能有一个属于我的架构师和开发团队。