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