公司软件架构设计的现状分析第一弹-CSDN博客

##背景 1、每个有良知的人类都知道软件开发有设计阶段 2、部门里普遍认为我们的设计做得不到位，但设计如何做，怎么才算到位又说不清楚。设计给人的感觉就是有经验的人灵光一现，啪啪啪就出来了。

##学校的理论在学校的时候大多数时候教的是“自顶向下”或“自底向上”的模块化设计，再加上一些数据流的分析。然而这些理论根本不足以支撑现实的设计工作，这就和国军说反攻大陆一样没用。

##工作的总结参加工作以来，绝大多数是参与中小Mis类项目，发现此类项目特点是搞清楚业务需求，然后再把数据表结构设计出来就可以开工了，只要表结构适当，项目工作也会非常顺利！但数据表结构如何得来，当然就是看着需求文档撸出来的。

我们目前各个项目中有用的设计文档几乎只有这个：数据库表结构（有时也叫数据字典）

##无用的进阶随着OO（面向对象，不是OOXX）的火热，专家搞出了OOA-OOD-OOP（面向对象分析-面向对象设计-面向对象编码）的理论，大体是用OOA得出用例、实体、领域模型，然后用例转成界面设计，实体转成数据表，领域模型转成业务层，正好与三层体系（界面、业务、数据）符合。然而，实践中，这些方法都不具备可行性。而且我的个人观点是：OOD根本不适用MIS系统，这是由于数据持久化本身已经把数据和行为拆分所决定的。

而且最大的问题是，这些OO理论搞起来的成果都不能用于投标的方案、建设解决方案，简直是又难用，又无用。

##反思如果找不到一条可行的路子，能不能对现有已完工的项目做反思，逆向出设计文档？然后再考虑这些设计文档，能不能在需求分析结束后通过一套可分解的体系得出。这就象我军已有各种吹上天的导弹，还要进口北极熊的S400一样，是希望通过逆向搞出设计图。当然，有了设计图，能不能研究出“设计图产生的办法”，又是另一个话题了。反正我是没找到，所以暂且相信：设计就是灵光一现出来的！

##靠谱的方法最近看了研发二组买的书《软件架构设计》，发现此书作者经验丰富，属于实干派，关于设计概念、步骤都说得很清楚。寡人窃以为可以用于今后部门的设计指导。以下是我的读书笔记 ###第一章从不同视角说明了软件人才结构，整体来看，还是高手太少。。。这不废话嘛

###第二章软件架构到底是什么，这个一定要先搞清楚，不然后面都扯犊子！作者认为，软件架构就是：重大决策

###第三章架构的2种主要视图：物理、逻辑。

###第四章架构设计的基本步骤（速查手册），以下5~11章均是这些步骤的详细说明。

###第五章架构师要连接需求、开发人员，因此需要对需求分析方法进行掌握

###第六章不同规模的项目，所需要的不同需求分析方法。这个对我部门有特别的指导意义，其实也就是CMMI中的裁剪。

###第七章只描述业务的领域建模：把需求分析的大段文字转成清晰易懂的图形，通过一图胜千言理清思绪。

###第八章关键需求决定了概念架构。

###第九章概念架构如何得出，鲁棒图->顶层子系统

###第十章细化架构设计，由之前的2视图转成5视图

###第十一章架构验证，通过原型检查风险。

###第12~15章通过纵向的功能、横向的层次可划分出模块，并通过用例等技术对模块进行评审、优化，最终得到详细的“逻辑视图”以指导开发。