读《软件架构师必须知道的97件事》

软件架构师是我们很多学习软件开发者的最初的梦想，于是拼命地学习各种编程语言，各种编程技巧、算法、框架，迷恋时髦的新技术等，乐此不疲。但是，我们却忽略了一个很重要的东西，那就是业务领域，忽略了和人打交道的技巧。

架构师是个二面神，一方面要和客户交流和谈判，理解业务需求，另一方面还要向开发人员传递理解后的需求，并制定整个系统的架构。但是，有时候客户都不知道他到底需要的是什么，或者他想要的并不一定是最好的。这个时候，就需要架构师凭借自己以往的经验去推荐一些解决方案，并同时提出一些建设性的意见。这个时候，一定要以客户的利益至上，要站在客户的角度想问题（有时候客户的客户才是我们真正的客户）。不要为了丰富自己的简历，推荐一些花哨的方案，要尽可能简单、稳定、高效。KISS原则非常重要，不管是解决方案的选择还是具体方案的实施，应该尽可能先保证其简单可行，即得到可以运行的软件，然后再考虑其通用性和移植性。现在大行其道的敏捷软件开发方法，先搭建一个可运行的骨架，然后不断地迭代开发，每次迭代都得到一个可以工作的软件，让用户使用，得到反馈后再不断调整需求和设计，这样才能生产出客户想要的软件。在和客户就一些软硬件的选择、是否购买服务器，买几台，哪些服务自己开发，哪里购买等方面，要注意自己是在谈判，而不是求妥协。要善于用财务分析等量化手段来说服客户。对于最终用户而言，最终界面就是系统，所以系统的界面要友好，用户体验一定要好，同时还要考虑到用户能够接受的程度。从项目开始的时候，就要综合考虑时间、成本、质量、风险，这些都是不可避免的话题。架构决定性能，一些实践准则说说不要尽早优化，它指的是局部代码的问题。但是架构的关注的是整个系统的性能，至少要在第3次迭代的时候加以关注，不然等到项目快完成的时候来追究问题，已经悔之晚矣。

接下谈谈架构师作为技术人员，该扮演的是什么角色呢？他应该助力开发团队，扮演一个管家而不是一个演员。一个好的架构师不应该在团队在炫耀自己的才能，去搞一些很复杂的技巧和模式。相反，应该调动开发人员的主动性和创造性，在团队里面营造一种积极主动向上的氛围。团队里每个人都可以自由地提出自己的问题而不用担心被指责。软件应该是培育起来的，而不是架构起来的。任何事前的设计都有可能随着时间而改变，要防止过度设计和模式病。同时还要抑制开发过程中出现的“好点子”与“奇思妙想”。这些都会间接的影响项目的开发进度。SCRUM方法提出了非常好的敏捷方法实践，他提出的每日站立会议和任务订单，冲刺订单（冲刺过程中冻结需求），不断调整计划，持续集成、交付等。非常适合小型团队的软件开发。软件是由人开发出来的，因此对于一个好的架构师来说，比聪明更重要的是灵动的心智，要善于在各种复杂因素之间做“折中”。懂得阴阳变化之道，方能游刃有余啊。

架构师应该向建筑师学习。

每次做架构设计时，提供两种以上的解决方案。

先考虑一些公理、原则和最佳实践，再考虑个人兴趣和爱好。

注意谈话的技巧。

记录每一次决策过程.