我读《软件架构设计》

      本人现已5年的工作经验，其中有1年的技术经理和2年的项目管理，个人也在管理和技术方面抉择过很久，不过我最终还是选择了做项目管理，而非走技术然后到架构师的路线.当然选择走项目管理主要是因为主要的是当前环境不太适合走技术，并不代表要放弃技术，并且我内心同样是向往走架构师的这条路线。所以我选择了读这本书

  比较遗憾的是本书只提供的3章的试读，不过虽然三章也要我学到了很多知识.

看完这本书的第一个主观感受：

      下载之后简单的花5分钟扫了一眼，感觉整体结构特别乱.有点看不下去的感觉，但是一想到书目中的几个"专家"的强力推荐， 越发觉得自己在本书的阅读方面有些问题，所以又仔仔细细的看了3遍...这才恍然大悟..原来本书中包含了这么多宝贵的知识. 如果你对软件架构设计感觉朦朦胧胧，这本书定能让你拨开云雾见青天。 

     

看完试读篇章我学到的知识和感悟

       1、软件架构的组成大体上分为2种大的方式和两种方式的交互

           组成派： 先不说概念，我直接用具体的实例进行讲解.

                  比如现在很火的 SSH架构, Spring 作为控制层，Struts2作为界面展示层，Hibernate作为数据存储层，他们每个都是一个组件，他们3个组件构成了SSH架构.

               

                  下面我们再来讲概念就比较容易理解了：简单的说就是整个架构应该是多个小组件(也可以理解成 模块|架构)整合而成，而每个小架构又有自己的软甲架构，就这样一直拆分成不能拆分的组件为止。 

                  这个派系关注的是“分割和交互” ，“分割”对上SSH 中的 分割成的3个组件，“交互”对应着3个模块之间的相互关系

                  所以说： 组件+交互 就构成了软件架构中的“组成派”

          决策派：关于对“决策派”这个概念的理解我花费了好长的时间。

               

                 所谓的决策其实就是 软件架构师的决策,而这个决策的出发点是成就受益人的利益，目的是为了最终做出决策.

                举个例子来说:在一个系统架构的设计过程中通常会有如下的问题：

                        模块如何划分。 

                        每个模块的职责为何。 

                        每个模块的接口如何定义。 

                        模块间采用何种交互机制。 

                        开发技术如何选型。 

                        如何满足约束和质量属性的需求。 

                        如何适应可能发生的变化。 

                        。。。

                这一系列的问题都需要架构师来进行决策适合进行实现.

                例如，你设计一个 C/S 系统时，是不是经历着这样一个“决策树”过程：……嗯，我决定采用 C/S 架构，系统包含 Client 和 Server；……嗯，我决定将 Server 分为三层；……嗯，我决定将 Server 的引擎层划分为 N 个模块；

                例如，你设计一个 B/S 系统时，可曾有过这样的“决策过程”：……嗯，我决定 B/S前端采用 JSP 技术；……嗯，具体到 Framework 我选 Struts；……

                架构师思考的出发点是成就受益人的利益，目的就是为了最终做出决策。在开始的时候，往往会有一些明显的途径，也会有一些隐含的途径。架构师要根据所掌握的信息，结合自身的知识、经验，尽可能找出所有的途径，思考哪条途径是最合适的。在这个过程中，有一些途径会很快被排除。排除一条途径的依据，首先是软件的价值，其次是软件的假设和前提。良好的实践是记录这些思考过程中被排除的途径，特别是对于经验不是特别丰富的架构师来说，这非常重要。

                需要特别提出的是，不要因为不精通某项技术而排除可行的途径。因为一般情况下，技术对软件价值的影响是次要的。比如，当你在JSF和struts之间摇摆的时候，把这个问题提出来讨论，是更好的做法。

   

                当然在实际的开发过程中 组成和决策是交织在一起的，2个结合起来才算完美

                简单的概括就是 ：组成派和决策派无非是个叫法，它们只不过是所站的角度不同罢了，你在具体设计一个架构时都会有所体现的。 

      2、让我思路更清晰的一些概念比如软件企业应该如何培养人员：

 

           1、定期分析和掌握本公司的员工能力状况、人才结构状况； 

           2、员工专项技能的渐进提升（例如架构技能、设计重构技能）；             

           3、研发骨干整体技能的跨越转型（例如高级工程师向架构师、系统工程师和技术经理的转型）。 

      3、概念架构设计

         这个我第一次听说到“概念架构设计”这个概念，作者把这个概念规划的很好.大体的意思就是 “关键需求进，概念架构出”的过程。

         我们接着拿刚才说到的 SSH框架的例子，系统架构师选择了SSH框架作为系统的架构，那么他为什么要选择SSH作为架构呢？他的设计思想是什么呢？ 而这些问题所涉及的内容就是软件概念架构设计了..

         概念架构应该避免的一些错误思想：

 

               概念架构≠理想化架构   实际工作当中，单纯采用功能需求驱动的方式，未免太理想化了，会造成“概念架构  =  理想化架构”的错误。 

              概念架构≠细化架构   概念架构一级的设计更重视“找对路子”，它往往是战略而不是战术，它比较策略化而未必全面，它比较强调重点机制的确定而不一定非常完整。所以，概念架构≠细化架构。 

这本书的优点：

        本书介绍了整个结构设计工作中的基本概念，适合不懂架构设计概念的程序员进行概念学习

        本书的例子很丰富很简洁(第一章的例子：其他的没看到过)，很容易让人理解

 

读这本书的一些经验：

 

       这本书要深读，读取一遍和读取3遍的感觉是完全不同的，读取第一遍的感觉，这本书就是在堆概念对于新手来说没有任何的实践价值，在读取第三遍的时候才发现本书的价值。。

       去这本书之前最好去搜索一下这本书的评价，看一下别人评价的重点，毕竟理论性为主实践为辅助的书籍肯定不能像小说那样去读，不然你一点收获都没有

 

个人感觉本书适合的人群： 

       工作2年以上对软件开发有自己的想法，参与过系统的设计并且个人的发展的目标是系统架构师.

挑骨头篇（当然只是个人感觉，和这本书给本人带来的价值来说下面面的缺点完全可以忽略.）

       1、作者的文笔不太行,有些生硬,刚开始读起来一点欲望和想象都没有，整个过程中都要比较费力的去思考作者是想表达什么意思.(本书例子还算可以)

    

       2、读这本书很累，在本次提供的5本试读的图书中这本书应该是读起来最累的一本,就拿《神一样的产品经理》和本书做比较吧，段落太紧密 + 上下段落缺少些承上启下的语句，例子字体居然比正文的颜色还突出， 在本书的图片配图上面不能有效的统一，图片的样式各种各样.天马行空。本书最少有5中不同风格的图片。

       3、有些段落标题和段落没有什么关系 。例如："1.1.2  从程序员向架构师转型 "  这个段落里面的内容都是软件行业和软件公司的现状.需要读者自己发挥想象力来关联两者的关系，还有就是有很多段落看完了之后不知道作者要表什么意思？

总结：

      读了三遍之后才知道是我想要的....

      试读了其中的三章，有种意犹未尽的感觉，这个本书为我以后的软件架构设计做了很大的铺垫.  感谢作者.

---------------------------------

备注：入门新手需要什么样子的书呢？

下面这两本是我在学习敏捷开发的时候读过的2本书。我们希望的内容应该是这样的

如果想写实践类的数据 可以参考“硝烟中的Scrum and XP ”,如果想写时间指导类的数据 请参考“Scrum checkList”

 

评论

1 楼 aijuans3 2012-07-21  

写的不错