写在前面
在假期中，系主任安排了任务让我们去阅读一下关于软件架构的书。在经过网上的一顿搜索中，我选择了这本《软件架构师应该知道的97件事》，这本书比起其他的软件架构书籍来说，更多的只是陈述了一些我们如何去做的事情，而不会过分的强调具体的实现。因为我毕竟在这方面是个小菜鸟，看书也应当是从最基础开始。
以下是该书的简介：
优秀的软件架构师应该既掌握业务知识又具备技术能力，做到这一点绝非易事，本书想要探讨的就是这个主题。这是一本真正的开源图书，我们邀请到50多位杰出的软件架构师参与写作。大家无偿地分享了各自的工作经验和心得，内容从规避风险的方法到组建团队的技巧，涵盖了架构设计的方方面面。衷心希望这97篇文章能激发您的思考，解决您工作中的困惑。
客户需求重于个人简历
解释
其实这句话很好理解，我们在解决一个具体的需求的时候，不要老想着去用最新最酷炫的技术以此来提升自己的简历，我们应当更加落实于问题，选择正确的解决方案，而不是过于追求技术。
个人理解
这一条放在本书的正文第一页，里面说的情况其实还是挺真实的。就连我现在在学习阶段，也是会犯下这样的错误。面对老师提出的问题，总是想着用多么多么酷炫牛批的技术去实现，但实际上更加应该注重的是对于问题的分析以及问题的解决能力。正如书中所说，作为一名架构师，职业操守不能忘，能够很好的完成任务才是自己首要该做的事。
关键问题可能不是出在技术上
解释
很多时候简单的系统都会翻车。这时候大家都会把矛头指向开发。但大部分项目都是由人完成的，人才是项目成败与否的基础。如果团队有人工作方式不正确进而拖了整个团队的后退怎么办？因此有一种非常古老的方式可以解决这类问题——对话，不要把对话当成对抗，不要带着情绪与人交流，尝试沟通设定共同的目标。这样每次沟通才能都有所收获。
个人理解
这点也很真实，有的时候一个项目的失败并不是技术选型出了问题，而是人出了问题。比如我大二的时候上的一门课，老师要求我们三人一组写一款简单的app，其实整个app一个人也能实现，但既然组队了肯定就要有组队的作用。此时如果本来就不熟的三个人在一块，连最基本的沟通讨论都做不到，更不要说写出一款软件了。如果项目中还有队友在划水，那更是加大了难度。因此正如书中所说，要好好的与人沟通，更好的与人交流。
分析客户需求背后的意义
解释
顾客和用户通常提出的所谓需求，只是他们心目中可行的解决方案。架构师要通过咨询客户，分析客户要求的功能和需求的真正意义，定位真正的问题，从而提出比客户的建议更好、成本更低的解决方案。总的来说，架构师应该通过与客户面对面的交流，关注客户的需求，引导客户回答“为什么”的问题。
个人理解
这点也深有体会。在实际的项目合作中，可能对于客户来说实现他的需求的方式是这样子的，但我们真的要做起来又是那样子的。因此要加强与客户（用户）的沟通，引导他们说出到底为什么要做这样子的东西，即真正的需求是什么，发掘出他们真正想要的东西。这样才能更好的为他们服务，做出更加令人满意的产品来。
故障终究会发生
解释
-
硬件会出错，于是我们增加冗余资源来提升可靠性，但这样虽然避免了单点故障引起的系统错误，同时也增加了至少有一台设备出错的概率。
-
软件会出错，由软件构成的应用程序自然也会出错，于是我们增加额外的监控程序，好在应用失效时报警。但监控程序也是程序，也照样会出错。
-
。。。。。。
由上述的很多例子可以得出结论，系统必然会出错。我们应当承认必然存在着不同形式的故障隐患，无论如何都无法彻底消灭。我们应该针对特定的故障设计对策，设计预防措施来限制故障，保护系统。
个人理解
这一条里面提到的很多情况也是我自己一直在思考的一点。我在学习大数据框架的时候了解到很多大数据框架为了提高自己的效率，也是为了降低故障的几率，都采用了分布式，且具有高可用（high available），即一台挂掉后可以迅速切换到另一台。但这么做的话我一直觉得可行性不强。因此架构师的作用也才体现了出来。
架构师应该针对这种情况做好提前的预备措施，防止事件发生后没有相应对策使得系统崩溃，进而全盘崩溃。
总结
总的来说，这本书就类似于我高中的时候背单词的小书一样，全是一些指导性的建议。但里面的每一点都是实实在在的，真实存在的实践之谈。还是可以学到很多知识的。