“世界上本没有路，走的人多了，更无路可走了。” --《北京青年》

八月初的一天，在Redmond Campus做ADR；整整一个下午，大家对眼前的架构设计所涉及的复杂场景、复杂因素进行了逐轮脑力激荡。

中间休息，看大家讨论的这么辛苦，Lindsey分享了她的一个观点：架构设计一开始可以不必过于复杂，系统复杂度会随着发展而不断增加，也许将来某一天，系统已经复杂得无法掌控了。

在身边，有不少软件企业和开发者正面对这样的困境：新技术层出不穷、让人动心，但面对新技术却只能裹步不前，一方面担心采用新技术后对原来代码修改所带来的巨大工作量，另外一方面又担心新技术所带来的新的风险，真是“不做等死，做了找死”。这样一些产品团队可能被其他人所嘲笑，但回想起来他们最初也曾经是新技术创新的领导者、实践者。

大家都喜欢看马戏团小丑把越来越多的球抛到空中、接住再抛起，旁人看起来眼花缭乱，而演员则从容不迫。而做到这一点，却很不容易，一个必经之路是：从少的球开始练起来，正所谓do more from less, go big from small。道理很简单，却是大智慧。

OK, I’ll do more from less, fine, but what’s the next?

一个关键问题是架构的演化（evolution of architecture）。最早接触到软件架构这个理论是在1999年，当时一位朋友推荐读了Mary Shaw的一本书：《Software Architecture: Perspectives on an Emerging Discipline》。

http://www.amazon.com/Software-Architecture-Perspectives-Emerging-Discipline/dp/0131829572

后面见到书店有影印本，上面写的中文书名是《软件体系结构：一门初露端倪学科的展望》，可见当时对架构认识的状态；而后几年“架构师”这个职业如同雨后春笋，取代之前“系统分析员”成为众多开发者的职业发展规划的一个目标。差不多同一时间，《设计模式Design Pattern》也开始被越来越多的人所关注，并大行其道。

对于 “软件架构”的最新解释，不妨去维基百科看看：

http://en.wikipedia.org/wiki/Software_architecture

如何做好架构设计？方法和相关技术很多，网上随便搜一下，就可以看到很多，孰优孰劣，正所谓萝卜青菜，看架构师自己的喜爱了。

但进一步谈到架构演化，就需要更多的考虑，而关键一点应该是能够全面评估现有架构，而且当新的场景、新的技术、新的需求出现的时候，能够评估它们对现有架构的影响，做出正确的决策。同时，这也是避免架构变得越来越复杂的办法，换句话说，如果一个现有架构都复杂到无法准确评估的话，是否继续演化真就已经成为一个必须马上思考的问题。

按照墨菲定律（Murphy's Law）：Anything that can go wrong will go wrong（如果一件事可能变糟，那麽它一定会变得糟糕）。

个人推荐的一个方法是Carnegie Mellon大学Software Engineering Institute推动的ATAM（Architecture Tradeoff Analysis Method）方法：

(上图摘自CMU SEI网站，http://www.sei.cmu.edu/architecture/tools/evaluate/atam.cfm)

这个方法有效地将业务驱动、场景和架构属性（技术属性和非技术属性）有机地结合起来，通过螺旋方式不断推动演化。

与系统变得越来越复杂的同时，团队规模和复杂度也在增高：需要招更多的人来开发，需要增加更多地职能还进行管理，而组织规模则变得越来越大、组织结构变得越来越复杂，而这又无疑让事情变得更加难以掌控。

如何让一个团队更加有效的工作？同样，方法论很多，工具也很多。

在和TFS team交流的时候，Aaron展示了最新的Team Foundation Service和Team Foundation Server。

对于Team Foundation Service，可以访问http://tfspreview.com/ 来进行体验。这个平台不仅仅有效支撑团队的敏捷开发模式，而且还让整个团队全生命周期地掌控设计、开发和测试。尤其Aaron分享了Visual Studio团队自己使用这套工具的真实数据库及如何使用Scrum来进行开发的经验，让人振奋。

http://tfspreview.com/en-us/home/features/feature-tour/

Well, how to do more from less?

上面这个story可以归纳为：Do more from less, managing {architecture evolution} and {team} with {ATAM} & {TFS}。