经历一个工具软件版本架构设计后的总结

一、背景

所开发版本目标是构建一个电信辅助软件系统，帮某运营商提升网络管理能力，降低维护成本。

二、摸索&迷茫

为降低成本，缩短开发周期。该软件系统基于一历史系统构建。新系统与历史系统定位不同，但数据来源大部分是相同的，也有不少功能能重用。应该说考虑基于历史系统构建是一条合理的快捷方式。

作为一个兼职的版本架构师(部门原架构师大牛已转其它部门)，之前未参与过正式版本的架构设计(自学过架构相关的一些书籍)。

架构是什么?架构有什么?很茫然。经过反复的试错和诸大牛们的悔人不倦;总算对架构分析过程有了一个初步的认识。总结一下，供后面参考。

三、确定架构需求

分析架构之前首先分析用户的需求，从中提取出影响架构的需求。很多客户的核心需求可以直接作为架的需求。在这点上我吃了亏，匆匆看了一下需求文档就开始提炼架构需求，提炼的需求也没有紧扣包需求。大佬评审后的意见就是你还是没有说清楚要做什么。打击很大。

事后总结:架构需求一定要紧扣用户包需求，核心需求copy过来也可以。满足用户需求是架构设计的首要目标。

四、子系统与模块划分

跌跌撞撞，九易其稿，总算把架构需求弄得像个样子了。开始划分子系统和模块，架构基本沿用老系统的C/S架构，客户也要求分布式部署，这块大体是支持的。主要设计针对新版本功能补充的模块，还有就是旧模块划分混乱，特别是前台客户端系统，就没有模块的概念，做一些架构的重构。

我拿到这个系统，首先划分出两个子系统:客户端子系统和服务端子系统。两个系统为独立的进程，可分别部署到不同的PC上，二者通过低层网络通信，多客户端操作上存在一些互斥。

大部份模块继承。一开始根据需求整了几个模块扔到子系统中，部门技术领导看了后提出两点意见:
1. 看不出从子系统到模块分解的过程。
2. 模块划分的意义在哪里。

深入分析，受益匪浅。重新划分，首先描述系统由客户，服务端子系统构成。子系统通过第三方控件通信。再依次展开客户端子系统和服务端子系统描述内部模块及模块间的关系。

基本思路是系统分子系统，子系统分层，层分模块。
1. 客户端子系统分为客户端应用层，客户端平台层。客户应用层包含与用户交互的应用模块，逻辑不多，负责数据录入和结果呈现。客户端平台模块包含基础控件，界面公共逻辑模块。应用层模块依赖于平台模块。
2. 服务端子系统分解为服务端应用层，服务端数据管理层，服务端基础数据管理层，服务端平台层。服务端应用层负责接收从客户端来的请求和发送客户端请求的数据。数据管理层负责对象的crud管理。基础数据管理层管理与业务产品相关的信息，产品数据用配置文件管理，数据相对比较稳定。服务端平台提供服务端子系统的基础服务，如配置文件管理，底层通信接口封装，模块管理，数据转换等。 越底层的模块越稳定，移植到其它产品复用的难度越低。规定接口调用的原则是只允许上层模块调用下层模块接口，不允许反向依赖。

通过分子系统，分层，分模块并约定依赖规则的方式一程度上保证了软件有清晰的结构。其实种分层设计是一开始就有的想法，之所以被批结构不清除我想应该是输出文档比较粗糙，行文上下不连贯导致。

五、技术选型

技术选型涉及数据库选型和开发技术选型。技术选型也是以满足用户需求为第一要务。数据库选型考虑数据量，性能要求，并发能否支持包需求。开发技术选型考虑技术成熟度，员工的技能情况，大部门的目标方向。

数据库的选型要结合客户需求分析，证明所选择的技术是能达成业务目标的，这一点相当重要。一开始未抓住重点，说了很多。开发技术的选型，这个版本的开发技术选性就是开发语言的选型，历史系统包袱沉重，语言的选择上无法与部门整体要求一致(被部门老大一巴掌拍死)，随后沟通，扯皮就来了。一方面需要深入分析列数据，讲道理，另一方面找各级老大汇报。脱了一层皮，两个重要的问题基本上定下来了。沟通的困难大部分来源于沟通的平等。

六、关键释疑

有些意见你总是必需要重点关注，有些问题你总是必须要优先解决。部门技术的头是一个，部门管理的头是另一个。部门管理大佬提出最关注的两个问题:后续版本如何调整架构，与部门要求的开发技术对齐;历史代码如何重用，能重用多少。

经过讨价还价，最后确定开发技术沿用当前后台C十十的开发模式，需要分析后续版本转换为JAVA的可行性和工作量。针对这个问题我先分前后台两个子系统描述。前台一直使用JAVA开发可平滑过渡，后台模块分三类:稳定的老模块，新增模块，易变的老模块。稳定的老模块提供接口让后续的JAVA代码直接调用C十十的逻辑，新增加模块使用JAVA代码，易变的老模块逐渐整改为JAVA代码，根据业务需要一个版本处理一些。最终给出了一个还算可行的方案。分析的过程中已转到其它部门的老架构师给予细心的指点。

历史版本代码重用性分析。项目申请过程中描述了版本一个关键算法的代码可以重用一个老项目的代码。但是深入分析后发现没有多少可重用的，连一个最底层的算法也因为老项目中的设计问题导致不满足新版本数据量的要求，需要重写。部门管理的大佬大为光火，要求分析清楚。拿到这个问题我首先把老项目代码拿过来按模块分析，对照项目申请材料逐一分析无法重用的理由:开发语言不同不能重用，数据库模型不同不能重用等。分析到底层算法时(按理这部分应该是最有可能重用的)，发现原算法用邻接矩阵的方式建模，内存占用随数据规模呈指数增长，需要修改为邻接表。但原算法与数据模型耦合，修改模型算法需要重写。无法重用。

以上两个问题回答了。基本上过了管理层大佬这一关。

七、架构演进

由于版本在历史系统中开发，但毕竟业务上还是存在差异。考虑后续系统的发展，我分析建议分开发布，代码上除公共平台层其它业务模块从物理上隔离。开发团队的组建上分成两个开发小组。

八、总结

开发过半来总结自己在架构设计中的得与失。
1. 架构设计是偏实践性的工作，光看过一些资料或者读过两本书是不够的。我之前从未参与过正式版本的开发，前期拿处的东西质量太低，时间耽误了，非常被动。
2. 要吃透需求，紧扣需求，围绕需求设计的架构才有说服力。
3. 分析透架构涉及的受众，把握关键受众，比如上文描述的技术部大佬和管理部大佬，重点解决他们关注的核心问题。他们掌握生杀大权。
4. 作为架构师不能假设涉众已经很了解需求，了解历史系统，了解业务。他们会问一些最基本的这个功能怎么操作，也会问一些大到到你无法回答的问题产品如何发展，和某某产品有何差异等。对方方面面都要分析，花很多经历。
5. 最后一点就是对困难估计不足，也是无知者无畏。部门领导要求三天输出初稿，我还没搞清楚要分析到何总程度的情况下应承下来。实际上从后面反反覆覆来看，三周都搞不定。也是吃一堑长一智吧。

发自我的 Windows Phone