对于团队来讲很重要的一点其实是担当，也就是你是否愿意为某个小项目整体来承担责任，当然这也意味着你需要再代码之外做很多事情，包括很多沟通、妥协和持续跟进的事宜。这一点对于那些有志于在管理或者产品方向有进一步发展的人尤其重要。如果你在很多事情上表现出不错的担当能力，相信你的上司一定不会埋没你这种人才。

如何做好架构？

从我自己来看，我觉得我把自己定位从开发转为架构的一个时间点在于，我不再是在寻找一个问题的答案，而是在从问题的一堆答案中评估哪个对我们更合适，这个时候我感觉到我已经能充分驾驭这个问题，而且也有信心来面对未来更多的挑战。

如果你要走架构这条路，我有如下的几个建议：

首先是要多读一些书，其中最基础的是类似于重构和设计模式这种书，你需要知道很多小尺度级别上的问题解决技巧（如果你要做导演，你首先要做得是能熟练地把一个句子翻译为一组镜头），以及这些作者梳理问题的方式，反过来问一下自己，如果让你来写设计模式这本书，你有哪些知识点可以写？你如何组织这些知识点？如何让大家接受你的观点。

看完这两本书之后，非常推荐你看一下 Martin Fowler 写的《企业应用架构模式》和 Eric Evans 的《领域驱动设计》这类书，他能扩大你的视野，专注于更有意义的问题，而不是设计模式究竟有多少种这种缺乏意义的问题。有一句话叫，“如果要成功，就要远离那些廉价的娱乐”。类似的，对于软件工程师来讲，要想让自己更强，就要远离那些廉价的争论（vim vs emacs, linux vs unix, redhat vs debian, 这些争论其实并没有太大的价值）。

其次，你要对大量开源软件的实际特性有深入的了解，容量究竟多大？高可用怎么做？如何扩容？是否易维护？这些知识部分来自网上的各种测试和经验文章，部分还要来自你的亲手测试。作为架构师，你的每一个技术选型都是在挖坑，给你的开发、测试、运维团队挖坑，而你的作用之一，就是保证你的团队能够在你的帮助下从坑里走出来。

另外，要解决很多大尺度的问题，你需要从很多同行去吸收经验，我个人的经验就是，阅读每年两次 QCon 和 ArchSummit 架构相关的幻灯片，先只看题目和问题部分，自己想一想解决方案是啥，然后再看一下演讲者给出的解答，通过这种方式来淬炼自己的思维，丰富自己的工具箱。我想提醒的一点是，由于软件行业还远不成熟，所以一个架构师会长期跟进一个项目，这就导致了一个架构师如果不主动去练习的话，一辈子也做不了几个架构，至少相对于建筑专业的结构工程师来讲，我们每年的项目缺少少很多。你做的架构越少，你就越容易自满。

最后，我希望你是一个终身学习者，不管多忙，一定要规划你的学习时间，一个星期也许不用太多，几个小时即可，但这几个小时一定要用在刀刃上，所以最好是哪些需要几十个小时甚至更多时间才能弄清楚的课题，而且一直要坚持到这个课题结束。千万不能是学一点这个概念，遇到新事物，就马上转移方向。如果你有这样的习惯，我建议你先把新想法放到一个池子里，等手边的课题学习完，再到池子里边捞一个新课题来继续学习。不过关于学习，这个是一个很大的话题，就不在这儿阐述了。

多谢各位。