很多IT新人都对架构感兴趣，我的团队里打算往架构方向发展的同事也不少（我在一个二十人左右的软件团队里任部门经理），他们会问我要往哪个方向去努力，看什么书啊，积累什么技能啊，但怎么说呢，或许是我的见识有限，我觉得很难用几句话说清这件事情。
上网搜索“如何成为架构师”，大部分人都说得靠经验、得积累等等。去买架构的书看（比如《软件架构实践》），读了几个月发现除了一堆“需求场景、软件切面、架构评价公式”等学术性的东西，对如何用自己的双手敲出一个架构还是知之甚少。和认识的架构师聊，发现大家谈的要么是泛泛的东西，要么就是和他所设计的软件细节息息相关，没有通用性。所以我们很难找到一个所谓的“架构书”或者“架构课程”，更加没有所谓的“万能架构公式”。架构本身就是和应用场景紧密相关的东西，一个这软件里非常棒的架构，放在另一个场景可能没法满足哪怕最基本的要求。
但我们就没有一条学架构的“路”了吗？
不通过实战说不定还真没有，起码我说不出来。但每个架构师多少还是有一些心得，包括我这样的“小”架构师。所以我打算把我做架构的几年经验从头到尾分享出来，形成一个简单的系列，希望对我，对大家都有裨益。
先说架构的前置条件：编程相关知识、语言及工具的熟悉、逻辑思维等编程相关能力、功能实现的能力、模块实现的能力、网络数据库等工具的理解、业务场景的熟悉、小架构的能力、然后是真正的架构能力。
编程相关知识：包括数据结构、算法，也可以包括计算机体系结构、操作系统、计算机网络、计算机图形学等。这些知识在一些学校计算机相关课程里都会有教。有些同志可能会说，我不喜欢学术，喜欢工程，喜欢实实在在敲代码的感觉；再说，我的工作看起来也用不到什么复杂的图遍历啊、时空复杂度的计算啊等等，更用不到cpu构成、任务调度和路由算法；再退一步说，等到我需要这些知识，我去学就好了。
我本人是北京大学的本科和硕士，还差一点读了博士，但我曾经有点为了学而学，没有学出什么成绩。在我任部门经理前，我的想法和上述一样，并不觉得书读得多有好处，甚至比较赞同上面“知识用不到”的说法，也曾为自己没有抓紧时间做实际工程而在学校里“虚度时光”而后悔。
但随着工作的深入，随着自己从程序员成长为“程序设计师”，到架构师，到软件部经理。随着我和我的同学、前辈、同事、后辈交流的增多，从一个被指导的角色成长为一个指导的角色。我慢慢发现，在逻辑思维能力、沟通能力、努力程度等情况相当的时候，大部分在学校好好学了“学术”方面书的同学在技术潜力上确实比只关注工程的同学强。这种强更多的体现在一种架构师方向的发展瓶颈上。简单点说，一名经验丰富的同事我可能认为再成长几年也难以在架构方向上独当一面，但一名工作较短的研究生却能让我看到短中期培养成型的可能。
但这并不意味着擅长学术的人发展得一定更好。发展通常有两个方向，一个是纵向，一个是横向。部分经验丰富、沟通、努力、动手能力都较强，但学历比较低或者不关注学术的同事，我将他往横向的方向培养，成为项目管理人员、驻场项目经理或者大区的技术负责人，甚至还以销售、大项目经理为目标；我们公司是做指挥室、会议室、展览馆等情况下的视音频软硬件集成的，因此从公司和行业的角度，这些横向发展的人其价值甚至比单纯的架构师更大（因为短期来说，我们这个非互联网公司用不到复杂架构）。
那纵向发展为什么需要“多读书”呢。可能的理由有：1、书读得多，对软件工程的理解就深。这不是单纯敲代码能敲出来的。2、很多书里面，其实有很多好的架构知识，甚至架构的雏形，比如操作系统的任务调度就是一种架构思想；路由算法、TCPIP协议栈的思想也是。3、架构师，需要在网络、数据库、性能等各方面都具备知识，也就是要有思想和知识上的广度。
再说架构的第二个前置条件：语言及工具的熟悉，不用多说相信大部分都理解，并且具备能力。但从一些由运维、需求和测试人员转编程的情况看（我会提供三个月的内部尝试机会），语言和工具零基础的同志转编程还是有相当障碍的。也就是说比起大学四年多多少少敲过代码的人来说，他们要在实际工作中敲好代码会难上一个层次。其中最缺乏的并不是不认识语法，而是缺少一种“编程素养”。比如没法很好的理解为什么要写个函数，为什么要写个类来完成任务，而不是用代码从头到尾把功能实现完。而这些是真正的程序员们认为自然而然的事，我要教起来都有点不知从何说起。
编程相关能力：在有了学术和一点工程基础之后（基本大学里好好学的同学都会有），接下来最为重要的就是如下能力了，包括抽象能力、逻辑思维能力和大局观。做好架构师，这三方面都很重要。抽象能力，是把一个庞大的“任务”划分成一个个可理解可接受模块的基础，逻辑思维能力，是啃下任务中核心算法的基础，而大局观，是把架构优化好的基础。
功能实现的能力：新参加工作的同事大部分眼睛都盯着功能。他们想法很简单，给我一个任务，我把任务做完就行。这个阶段多百度相当重要。谁都知道不会敲代码要百度，但并不是每个人都能好好“百度”的。其实实现一个功能，需要学会查看qt啊、java啊等自带的API文档；学会准确的描述问题，学会从各个思路去描述问题等，也是门学问。
模块实现的能力：功能做好了之后怕的就是一直带着“功能”的思想，给任何任务都从功能的角度一路往下做。功能做得比较熟之后就要想着从码农转变为“设计师”了，这时候起码得有“做好一个模块”的意识。这阶段，学会写伪代码，学会抽象很重要。
网络数据库等工具的理解：“设计师”做了一阵，需要的就是熟悉软件工程里面的一些重要工具了。包括网络、数据库、Json、协议等。有了这些才有未来做架构的工具基础。
业务场景：想做架构，你要对软件的业务场景特别熟悉。很多同志认为技术是技术，业务是业务。站在架构师的角度其实不完全是对的。技术的目的是实现业务，如果你都不知道你要实现什么，那你用的技术可能是有问题的。
有了以上的诸多准备，你才能晋级为一个菜鸟架构师，做一些介于模块和架构之间的“小系统”。最后，在小系统上积累足够多思考，你就能开启架构之路了。
第一小节，也就是架构系列的前言就说到这儿吧。以后我会抽空根据我遇到的实际问题，把如何成为架构师尽量具体的描述出来。