恰如其分的软件架构---不可取代的专业能力系列(二)
2016-07-29 10:53
344 查看
一、为什么要找到软件开发的道和术!
随着岁月的推移,软件系统无论是规模还是复杂度都在呈数量级增长。作为软件的构建者,这种非凡的变化带给我们的惊叹远甚于恐慌。设想我们采用同样的方式让篮球比赛不停的扩大规模,在十年内,从最初的5名球员,增加到50名球员,再到500名球员......该是多么困难。软件开发者常常陷入与复杂度和规模这些宿敌斗争的泥沼。但是很明显,开发者总会绝处逢生、甚至大获全胜。他们是如何做到的?
一种说法:软件开发者善于运用一些有形的武器,如集成开发环境和编程语言。然而无形的武器带来的影响可以说更为深远!
前提是你要能找到这无形的武器。就像中国古人经常提倡的,道和术,掌握了道,才能理解千千万的术。
例如:假设一个新手和一个教练一同观看篮球比赛,内行看门道,外行看热闹。教练所能察觉到的内容会远远超过新手。这并非因为教练火眼金睛,而是因为他掌握了某种无形的武器。通过建立一整套思维抽象,教练能够透过现象看本质,把对原始现象的感知转换为对目前局势简明扼要的理解。例如教练在看到传球的一瞬间,就会联想到某种进攻战术的成功。尽管教练和新手都观看了同一场比赛,但是教练却可以更好的理解比赛,原因何在?Alan
Kay早已捕捉到了这一现象,称之为你的“观察能力就值80分智商指数”。
二、软件开发的道是什么?(借鉴大师的书,浅析一下,推荐大家看看)
分治、知识、抽象,这是软件架构所能提供的最有力的武器,它有利于分割软件系统,提供有助于设计出更优秀软件的知识,提供有助于理解软件的抽象。不过它仍需要经验丰富的软件开发者。它并不是要扼杀创造力,而是使得开发者可以用其创造力去构建规模更大、复杂度更高的系统。
如何进行软件架构的设计?
这里有一个框架思路:《恰如其分的软件架构-风险驱动的设计方法》
假如你实现的是一个非常简单的系统,那么,很可能不需要软件架构的设计。只需要凭借经验直接开始干就好了。
而如果你实现的是一个复杂的系统,那么就不能像之前那么干了,就需要做宏观、微观分析,要做软件架构。否则,这个系统你很可能完不成,甚至都实现不了。
(1)如何掌握架构设计的分寸???
架构的风险驱动模型将指导开发者把握架构活动的程度,及时开始编码。
首先需要识别风险,假如这套软件架构在通过重构以后不能降低某一方面的风险,那么,这块就需要再做设计,以降低风险!
如果这套架构能够通过重构来降低某一方面的风险,那么设计到这里就可以截止了,不用再做过度的设计。
(2)软件架构难道仅仅关注宏观方面吗?
软件架构关注宏观部分,但有时不仅仅是这样。
判断某些细节是否属于架构的范畴,就看这些细节是否会直接影响建筑物的整体质量。是,则属于,不是则不属于!
如果大家想看更多的内容,推荐大家看看《恰如其分的软件架构-风险驱动的设计方法》
下篇我们继续解决前面遇到的问题。
随着岁月的推移,软件系统无论是规模还是复杂度都在呈数量级增长。作为软件的构建者,这种非凡的变化带给我们的惊叹远甚于恐慌。设想我们采用同样的方式让篮球比赛不停的扩大规模,在十年内,从最初的5名球员,增加到50名球员,再到500名球员......该是多么困难。软件开发者常常陷入与复杂度和规模这些宿敌斗争的泥沼。但是很明显,开发者总会绝处逢生、甚至大获全胜。他们是如何做到的?
一种说法:软件开发者善于运用一些有形的武器,如集成开发环境和编程语言。然而无形的武器带来的影响可以说更为深远!
前提是你要能找到这无形的武器。就像中国古人经常提倡的,道和术,掌握了道,才能理解千千万的术。
例如:假设一个新手和一个教练一同观看篮球比赛,内行看门道,外行看热闹。教练所能察觉到的内容会远远超过新手。这并非因为教练火眼金睛,而是因为他掌握了某种无形的武器。通过建立一整套思维抽象,教练能够透过现象看本质,把对原始现象的感知转换为对目前局势简明扼要的理解。例如教练在看到传球的一瞬间,就会联想到某种进攻战术的成功。尽管教练和新手都观看了同一场比赛,但是教练却可以更好的理解比赛,原因何在?Alan
Kay早已捕捉到了这一现象,称之为你的“观察能力就值80分智商指数”。
二、软件开发的道是什么?(借鉴大师的书,浅析一下,推荐大家看看)
分治、知识、抽象,这是软件架构所能提供的最有力的武器,它有利于分割软件系统,提供有助于设计出更优秀软件的知识,提供有助于理解软件的抽象。不过它仍需要经验丰富的软件开发者。它并不是要扼杀创造力,而是使得开发者可以用其创造力去构建规模更大、复杂度更高的系统。
如何进行软件架构的设计?
这里有一个框架思路:《恰如其分的软件架构-风险驱动的设计方法》
假如你实现的是一个非常简单的系统,那么,很可能不需要软件架构的设计。只需要凭借经验直接开始干就好了。
而如果你实现的是一个复杂的系统,那么就不能像之前那么干了,就需要做宏观、微观分析,要做软件架构。否则,这个系统你很可能完不成,甚至都实现不了。
(1)如何掌握架构设计的分寸???
架构的风险驱动模型将指导开发者把握架构活动的程度,及时开始编码。
首先需要识别风险,假如这套软件架构在通过重构以后不能降低某一方面的风险,那么,这块就需要再做设计,以降低风险!
如果这套架构能够通过重构来降低某一方面的风险,那么设计到这里就可以截止了,不用再做过度的设计。
(2)软件架构难道仅仅关注宏观方面吗?
软件架构关注宏观部分,但有时不仅仅是这样。
判断某些细节是否属于架构的范畴,就看这些细节是否会直接影响建筑物的整体质量。是,则属于,不是则不属于!
如果大家想看更多的内容,推荐大家看看《恰如其分的软件架构-风险驱动的设计方法》
下篇我们继续解决前面遇到的问题。
相关文章推荐
- 软件架构为何重要?---不可取代的专业能力系列(三)
- 宏观和微观的结合---不可取代的专业能力系列(一)
- OO系统设计师之路--设计模型系列(1)--软件架构和软件框架
- 面向模式的软件架构.第4卷,分布式计算的模式语言(经典POSA系列的第4卷)
- [软件架构:设计模式系列C#篇]系列教程汇总
- 软件工程系列教材:软件架构设计实践教程
- Android架构纵横谈之——软件自愈能力 (1)
- [软件架构师系列教程-1]白话软件架构与架构师
- 恰如其分的软件架构 - 读书心得
- 软件架构设计系列总结—10—表现层模式-MVC
- 软件架构设计系列总结
- 测试必备技能系列6:软件安装部署是最基本的能力!
- OO系统设计师之路--设计模型系列(1)--软件架构和软件框架[从老博客搬家至此]
- Android架构纵横谈之——软件自愈能力 (1) 推荐
- Android架构纵横谈之——软件自愈能力 (1)
- Android架构纵横谈之——软件自愈能力(转载)
- 软件架构设计系列课程(视频课程讲师:汤涛)
- 软件架构师必读书籍--------软件架构师推荐书籍系列
- Android架构纵横谈之——软件自愈能力 (2) 推荐
- STM-CortexM3系列微处理器软件体系的自动架构