培训心的随记.docVIP

架构设计培训随记 这次参加了《一线架构师实践指南》作者温昱的“软件架构最佳实践与工程化方法”的教学培训，收益颇深、感慨良多。4天的培训时间是很短暂，可谓是意犹未尽。然而培训只不过是一个引入蜂，为你指引方向，能不能朝着正确的方向继续走下去，能走多远？靠的还是自己。 守破离 初次见到这个单词，相信大家的第一感觉会和我一样，会认为这是某宋词里的词牌名。其实不然，这是一个初级软件工程师走向架构工程师经历的过程。守是模仿，遵循，是无我的过程。刚毕业一两年的初级软件工程师，软件开发的过程就是守，教程上说怎么弄的那只能这么弄，依葫芦画勺；公司框架定义好的那只能按部就班的这么来，循规蹈矩。破是变，是自我意识逐渐增强,心智逐渐收缩的过程。经过2，3年的磨练后，当初的初级软件工程师也逐渐成为准高级软件工程师了， 破由心生,处于这个阶段的工程师已经开始提出“目前公司这个框架还有太多不完善的地方；这个地方耦合度太高了”。当有能力将大多数项目架构。经过进一步的磨练，终于可以挣脱层层束缚，自行设计底层乃至系统整个框架。即为离。离是返朴归真, 是忘我的过程。 架构设计千万不能瞎子摸象 架构是什么，每个人都可以说上两句，但是很少有人能说得清楚。一说到系统架构，许多软件工程师脱口而出的就是架构设计=模块划分，思想嘛当然就是高内聚低耦合。这个回答可以说不错，但不能说正确。 5视图方法： 架构设计师不能只关注中间那层开发架构。从逻辑层、物理层、数据层都需要面面俱到。架构设计师是将实施工程师、DBA、需求分析师、测试工程师连接起来的桥梁。 架构设计师只需要技术强就行了么 答案当然是否定，架构师首先要了解目标驱动的概念。正所谓需求进、架构出。首先要以需求为最根本依据。印象最深的是有一副漫画画的是一个猴子收到一份肉骨头的礼物。送礼之人犯的错开发工程师是经常犯。如果不注重需求，结果可想而知。 同时，不能停留在需求表面，不能局限于《软件需求规格说明书》。不必多说，需求文档不可能是100%全面的，也不必多说，需求变更是时常发生的。所以架构师必须对需求进行有理性、有针对性的权衡、取舍、补充。 约束性需求：也是一个不能不考虑的因素。一方面是来自客户的约束性需求，如客户对系统上线时间、预、算、行业特性等，另一方面是开发维护人员的约束性需求：开发团队技能水平、磨合度等。这些都是一个系统架构师必须考虑在内的。 性能是设计出来的，而不是测试出来的 说到非功能需求，大家脑中第一个冒出来的当然就是性能了，的确性能是非功能需求中非常重要的一个因素，当然非功能需求除性能外还有很多，如易用性、鲁棒性、健壮性、可移植性等。我们开发的教育培训系统最初一直受性能问题影响，用一个类似简单的例子来说明。 性能出问题了，测试能解决问题么？当然不能，睿智的架构设计师会使用科学的方法，做到问题驱动。之前在公司，我们已经学习过类似的方法，如解决问题的技巧，其中包括鱼骨图、决策树、头脑风暴等。上图通过对物理层性能产生影响的原因逐个拆分破解，决策也就自然而成了。 RUP迭代之架构设计 该话题的重要性，相信不用多说，远行公司研发团队目前正是基于RUP模型进行软件开发，如何在迭代模型中做好架构设计，其意义重大、深远。 架构要涵??的内容和决策太多了，超过了人脑一蹴而就的能力范围，因此采用分而治之的办法从不同视角分别设计。RUP 4+1视图的方法主要是为了使不同架构视图承载不同的架构设计决策，支持不同的目标和用途。 比如设计一座跨江大桥：我们会考虑连接南北的公路交通这个功能需求，从而初步设计出理想化的桥墩支撑的公路桥方案；在RUP初始阶段，我们需要完成这些。然后还要考虑造桥要面临的约束条件，这个约束条件可能是不能影响万吨轮从桥下通过，于是细化设计方案，规定桥墩的高度和桥墩之间的间距；另外还要顾及大桥的使用期质量属性，比如为了能在湍急的江流中保持稳固，可以把大桥桥墩深深地建在岩石层之上，和大地浑然一体；在RUP的细化阶段，我们要完成这些。建造期间的质量属性也很值得考虑，比如在大桥的设计过程中考虑施工方便性的一些措施。那么，在RUP的构造阶段我们要完成这些工作。