公司软件架构设计的现状分析 第二弹

前言

有了“第一弹”的基础，现在回过头来看我们的设计

现状

根据业界的说法，我们其实已经把设计做得蛮好了。我们项目中的设计一般有：
1、物理视图：网络示意、服务器部署图
2、逻辑视图：系统大的功能模块划分
3、开发视图：技术选型，3层架构（虽然都是复制来、复制去）
4、数据视图：表结构设计

这些已经做得较好的工作需要固化，如果能100%加上评审环节就更好了（请各个项目组在设计环节都能邀请彭大神，O码王，林大牛参与）

差距

1、我们没做过的是“运行视图”，这是因为我们以前开发的系统很少是分布式、实时协作式的项目（如：在线多人游戏），所以对进程同步、分布式事务等关注不多。
2、我们都是纵向分工（按功能模块来分工），一个人就负责了从前端界面到后台数据库表结构的一条龙，所以一些中间可能共用的模块、接口考虑不会太多。
3、我们整体只考虑功能需求，非功能的约束几乎不考虑（除了现在被电网强制要求的安全性，个别项目也会测一下性能），造成系统的扩展性、可维护性偏弱。实际上，如果各个项目在参数化、日志输出方面有所加强，后期的运维压力会小很多。
4、各个项目设计的风格、粘度不太统一，正象我们的系统界面风格不是很统一 一样。甚至有些设计文档纯凑页数，当然，也不排除有些项目组缺少有设计经验的人。

改进

非功能约束的问题更多是暴露在运维阶段，能不能由研一、二的相关人员总结一下，目前三线运维经常碰到哪些问题，这些问题的原因、用时、难度，而且有没有可能在设计阶段就采取办法进行处理？

不然运维部的兄弟痛苦，我们一边开发新项目，一边还要接三线的运维也痛不欲生。

后话

立志成为架构师或已经是架构人员的，都建议看一下《软件架构设计》第2版，对书中内容相信也好，批判也行，都会给自己带来帮助。