很久之前有一部电影叫黑鹰坠落，里边有一个场景是一个打字员在那儿说，因为我会打字，所以我不用上前线。这事放在现在看就比较搞笑了，毕竟现在绝大部分人都会打字。

我觉得在未来，编程会像英语、电脑一样是一个很通用的技能。首先是编程的门槛越来越低，从 Fortran, Pascal, C  到 Java, Python，编程语言其实是越来越简单的，即使你不是专业的软件工程师，学会用 Python 写一些简单实用的脚本其实也是一个很轻松的事情，更何况还有 Excel, IFTTT, VBA 这类更简单的工具。

另外，未来的工作对编程的需求也越来越强，你需要做更多自动化的工作，你需要把大量的不同来源的数据串起来完成你的工作，编程会成为你最趁手的一门工具。最后，我觉得编程是一种很好的逻辑思维训练方式，毕竟任何诡辩、欺骗和逃避这种非理性的手段，在编程面前都是走不通的。

软件是一门很特殊的学科，首先是学习编程的成本很低，你只需花两三千元买一台电脑就够了，如果你要自学物理、化学、生物的话你就得有一个价值不菲的实验室。其次是软件的反馈很快，你有一个新的想法，快则半个小时，慢则一周就能验证你的想法是否有效。而在化学领域，你能在一个月内验证完一个想法就已经谢天谢地了。

这个学科另外一个好的风气是分享交流极度地开放，各个软件公司都非常乐于分享自己的技术、自己遇到的问题和解决方案。这对于传统行业是很难想象的。

这样带来最大的好处是只要你想学，你愿意投入你的时间、精力和意志，那么你就很有希望在这个领域做出你自己的成就。

对于我来讲，我是因为高中时化学竞赛保送上了大学，就直接选了化学系。其实我在高中的时候就开始接触编程，也对它很有兴趣，只是苦于没有电脑，也没有足够的时间能花在上面。到了大学之后，我就把自己的大部分业余时间都扑在上面了，只是因为不舍得保研的名额，又继续上了学校的研究生，不过根据自己的兴趣，选了计算化学方向，研究的课题应该可以归到计算机辅助药物设计这个领域。

在研究生阶段，我比较自豪的一个成就就是教会了几乎所有同学用 Python 来编程，加速了很多日常工作。不过有点可惜的是，我最后没有拿到学位，就离开了学校，开始了自己在软件行业的第一份工作：金山实验室。

我一般会把程序员分为初级、中级和高级。他们的区别在哪儿呢？初级可以在别人的指导下完成工作，中级可以独立地完成工作，高级不仅仅可以指导别人的工作，而且可以很好地提炼自己的方法论，用这些方法论去影响别人，帮助他们成长。而架构师，他更多的职责则应该是确保一个项目不会因为技术的问题而失败，比如是不是伸缩性不足导致大量用户涌入时支撑不住、灵活性差导致功能很难添加，设计过于复杂导致开发持续延期，技术选型错误导致成本和稳定性出现问题，等等。

我们公司采用了 buddy 制度，简单来说就是任何一个新员工入职，都会指定一个 buddy ，在入职的前三个月，你不管什么事情都可以问他，这个制度对新员工快速平滑地融入团队帮助很大。如果你的公司没有这个制度，你可以考虑跟你的上级申请一个 buddy, 你的 buddy 也许很忙，那么你可以考虑一下定期（比如每天中午花半个小时）跟 buddy 核对一下之前遇到的问题。这些都是可以让你快速融入团队的办法。

一般过了 2 年左右，很多人就不再能直接从项目或者周围的同事身上获得成长了，这个时候一个比较好的手段是跳出现在的圈子，多参加一些本地社区的活动，多参加 QCon 这类的技术会议（当然看直播或者视频也行），看看这个也就的标杆长什么样，他们在解决什么问题，他的知识体系有哪些是你缺少的。我很认同的一句话是“参加会议的目的不是为了学到什么，而是为了知道要学习什么”。找到一个好的标杆，相信你在职业生涯的前面 5 年会一直快速成长。

方法其实很多，每个人都可能有不同的选择，甚至说在不同的团队，你的做法也可能会不一样，下面仅就个人的经验讲讲我自己的看法：

首先一点是要把手边的活做扎实，如果这点做不到，你的意见比较容易被人轻视和质疑。

其次是要经常参与项目中的设计与技术相关的讨论，勇于发表自己的意见，但这个时候要学习一些讨论问题的常识，比如说对于别人的方案，要先去接受而不是拒绝，然后从两个方面去考虑，一方面是这个方案有什么漏洞，礼貌地提出潜在的漏洞，等待对方抛出他的观点。另外一方面这个方案有什么可以延伸或者扩展的地方，是否可以根据对方的方案抛出一个更好的方案。对于自己的方案，不要过于强势，毕竟很多事情一个问题有超过一个正确答案，自己的方案没选上也要有平常心。

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

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

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

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

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

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

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

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