image from http://blog.yalebooks.com/tag/paul-rudolph/
“天波易谢，寸暑难留”。转眼在软件行业摸爬滚打已经就近二十年，从事软件架构工作也快十年了。曾子曰：“吾日三省吾身”。人要提高自己，需要对自己犯过的错误进行反省，作为一个老软件工程师，我希望能通过这个平台，记录自己对软件架构的认识，犯过的错误以及我的思考都记录下来，分享给大家，和大家共同成长。
首先跟大家聊聊“刚哥”这个称（匪）号，08年我加入了某存储巨头在上海的研发中心，我们团队的小伙伴亲切的称呼我为“刚哥”。应该是我年纪比较大对我的尊称吧。另外一个原因大概是我没有给自己起英文名的原因。虽然在外企工作了这么久，我一直坚持使用自己的名字 ‘Gang’。我们团队的Tony同学就没有获得某哥的称号，当然他的中文名字叫Wei，Wei哥这个称号不是一般人能承担的。‘Gang’在英文的含义是指一帮匪徒（经典设计模式的书就是由Gang of Four 写的，想必大家都很熟悉），所以我想我的名字在老外眼里应该是那种霸气侧漏的那种把，和“刚哥”这个称号挺切合的吧。其实“刚哥”这个称号在我工作的第一家公司就出现过，只是没有被推广，某天，同事看了个Flash小笑话，讲的是嫦娥在月亮上很寂寞，看到伐木工吴刚雄壮的身影，兴奋不已，上去搭讪，询问您叫什么名字呀？吴刚一句：“刚哥（割）”让嫦娥悲痛欲绝。之后哪个同事就总是拿刚哥来取笑我。我呢其实也挺开心的，人生不过就是做些傻事，让别人笑笑，然后也笑笑别人。别人愿意取笑你，其实是当你为朋友。后来在新公司，同事们称我为‘指导’，大概我这人话比较多，喜欢指手画脚的教育别人把。这个时候，我经常脑子里会飘荡着那首柯受良的“我不做大哥好多年”。现在我在北美工作，很是想念以前国内团队的小伙伴们，那时的同事关系非常的融洽，大家一起工作，玩耍。北美的同事关系更像是君子之交淡如水，大家互相尊敬，但是生活和工作分的很开，除了中国人之间会有些交流，同事之间的线画的很清楚，基本工作之外就没什么交集了。
今天这个话题我们先讨论一下什么是软件架构？
对于软件架构并没有一个标准的定义，但是你和软件工程师谈到架构的时候，他们会知道这些都会是架构的内容，是不是要分层，如何处理事件，如果划分组件，组件和分层之间如果传递数据和控制信息，数据如何存储，计算如何并发，等等
我认为架构的本质是一个中心两个基本点，中心是要解决一个问题，两个基本点是要解决两个核心资源的问题：人和时间。
软件架构的核心是要解决问题，这个问题就是要提供软件需求所定义的功能。围绕这个核心，软件架构就是要能使你的软件更好的提供需求所定义的功能。
任何软件都是由若干人在一定时间内完成的，时间和人是软件开发最重要的资源。其中时间是不可重生的，而开发人员虽然不会说不干就不干，但是就怎么干这个问题，会是影响软件的重要因素。这里我要澄清一下，我确实是在讨论软件架构而不是项目管理。
首先我们看看第一个基本点人的因素。大部分的软件都是由一个团队来开发的，软件架构设计的一个目的就是能使的团队中所有的人能够有效的合作。软件架构和项目管理一致的地方就是都要化整为零。对系统分解成为若干子系统，定义每个子系统的职责，系统的边界和系统之间如何协作。通过这样的定义使得团队中的人可以专注的相对比较清楚的子系统工作上。
另外一个基本点是时间，通常我们开发软件都需要有一个时间约束，软件架构的设计使得软件能够在规定的时间内完成开发。通过定义子系统，我们可以定义那些组件可以重用，那些可以用开源，那些可以利用团队中已有的知识快速开发。如果没有这个时间限制，软件架构完全可以天马行空，反正有的是时间来换一个玩。
作为一个架构师，我们通常要面对的软件架构相关的问题有：
- 和我的软件利益相关的人都是谁？
- 软件的目标是什么？
- 软件使用什么技术？
- 软件有哪些风险？有没有应对方案？
- 软件有哪些限制条件？
- 如果可以重做，你会做哪些不同的选择？
围绕一个中心，两个基本点，我认为软件架构是：
- 软件架构是对问题域的划分，把大的问题划分成可管理，可控制，可实现的小问题。
- 软件架构使得团队可以高效的协同工作，
- 软件架构可以提升开发的效率
那么，你觉得什么才是软件架构呢？欢迎来和我讨论。