【转载】15年编程生涯，资深架构师总结的7条经验

前言： 这是一篇应InfoQ之邀写的文章， 首发在InfoQ微信公共号上。

大家有空可以多看看InfoQ 网站和公共号 , 是个很有深度的优秀社区。

我和很多人交流过一个有趣的现象，那就是刚毕业到30岁这段时间，会觉得时间过得很慢，总觉得自己还很年轻，但是一旦过了30岁，时间就如白驹过隙，一年又一年飞逝而过。

我自己也是，眼瞅着毕业快15年了，15年间从一个刚毕业的菜鸟，成长为技术骨干，做到架构师的职位，回头看看，当年听取亲戚的一句话，误入计算机行业，看来并没有走错，编程虽然枯燥辛苦，但是如果真的感兴趣，你就能体会到其中的乐趣，并且获得可观的回报。

刘慈欣在《朝闻道》中描绘过这么一个情节：在古老的非洲大陆上，有个原始人无意中抬头仰望星空，凝视的时间稍微长了一些，超过了外星人设置的阈值，立刻拉响了人类即将产生文明的警报。因为外星人认为，人类已经产生了对宇宙的好奇心，文明的产生，科技的发展不过是一瞬间的事情。

确实是这样，好奇心驱动人类不断向前，在短短的几千年（相对于长达几十万年的原始时代）里就登上了月球，并且努力向其他行星拓展。

对于程序员来说也是类似，如果你看到新技术，新产品没有像小孩看到新玩具那样两眼放光，没有想赶紧在自己电脑上玩玩的冲动，你就需要仔细考虑下是否真的对软件开发有兴趣？如果根本没兴趣，不要浪费时间，还是趁早转行，有更多有前（钱）途的职业在等着你。

没有好奇心，就不愿意追本溯源，追求技术的本质。

没有好奇心，就难于静下心来，耐得住寂寞，远离浮躁和代码奋斗，更难于跨过这个苦逼行业带来的种种挑战，走到架构师这个位置了。

没有好奇心，就不愿意学习新技术，一个架构师，如果没有对技术的敏感度和前瞻性，一直抱着一套技术架构不变，估计很快会被淘汰。

当然自制力强大的人除外，但话说回来，靠着自制力让自己做自己不喜欢的事情，岂不非常痛苦？

我在上公司的一个关于Leader的培训课的时候，老师一直在说Passion（激情），Passion，Passion，但我一直觉得没有好奇心，没有兴趣，怎么会产生Passion呢？

所以，对技术的好奇心/兴趣，是一切的基础。

之前在“码农翻身”公共号发过一篇文章，叫《学会编程，而不是学会Java》说的就是要能够以计算机的方式去思考。

现在的计算机还很“弱智”，你不能这么说：『电脑，我要创建一个像Java的ArrayList类似的类，有个get、add、remove方法，还有这个ArrayList的容量不是固定的，能够自增长，快点给我写出来！』

现在的电脑当然写不出来。

相反你只能用计算机能理解的方式，用非常非常低级的计算机语言去告诉它做事情：创建一个类，分配一个固定大小的数组用来存放数据，用一个数（size）来记录数组里存了多少数据。如果数组满了，就需要增大数组，并且把数据从老数组复制到新数组。

这里边有很多很多的烦人的细节需要你去处理，一不留神就会出错---计算机编程就是这样。

养成计算机的思维方式，流畅的把人类语言的需求转化成计算机语言，这是程序员的基本功。

很多人会语法，也懂框架，但是在基本功上却不过关，只能在初级程序员上踏步。

这个基本功的训练就是数据结构和算法，我的经验是多做习题（大学时我把数据结构后面的习题都做了一遍），让这个思维在脑子里固化，以后的编程就可以信手拈来了。

我很久之前参与过一点开源软件的开发，有幸看到了一个老程序员的简历，让我震惊的是他竟然在Altair这个最早的电脑上编过程序。

没错，Altair就是那个连显示器和键盘都没有，靠拨动开关来输入，靠指示灯来输出的所谓“个人电脑”，比尔盖茨和保罗艾伦在上面写了一个Baisc的解释器，从此开始微软之路。

如果有了在这样的机器上编程的经历，我相信这些老程序员对硬件，驱动，操作系统，应用软件的理解要远远超过我们现在这些人。

我之前要写文章遇到了一个问题：一个进程要读取文件，在底层用的是DMA的方式，DMA完成文件读取以后要通过中断让CPU去处理，但是CPU和中断处理程序根本不知道进程的ID，它怎么去和进行关联，如何去唤醒那个等待的进程？这个问题让我意识到其实我对计算机的基础也并没有融汇贯通。

我们大学里都学过计算机组成原理、操作系统、编译原理、计算机网络、数据库、汇编语言，能不能把这些知识融会贯通，打通任督二脉，在我们的脑海里建立一个计算机运算的图景？

把这些知识融为一体，我相信能超越绝大多数程序员。

现在的软件开发封装的层次已经非常高了，只要学会Java就能做一个编程工作了，随着你做的越来越深，越来越专，这些基础的问题就会浮现出来。

更重要的是，计算机软硬件的基本思想在这几十年里其实变化不大，例如缓存，增加抽象层等，有了这么基本的思想的武装，去学习新的东西不但学的快，理解的会更透彻。

先举个Ant中的例子，大部分人学习Ant只是学会怎么使用，认识到Ant提供了很多内置的task来帮助我们方便的完成自动化的构建，例如命令。

<copytodir="../backup/dir"> 
<filesetdir="src_dir"/> 
<filterset> 
<filtertoken="TITLE"value="FooBar"/> 
</filterset> 
</copy>

很少人会思考为什么Ant的task是以XML来描述的？为什么Ant不提供一套Java类库/API来让程序员用，那样不是更自然吗？

这其中的一个重要原因就是XML可以自定义标签，所以表达力无与伦比；如果用java，它的语法不允许自定义一个像copy、fileset这样的关键字，只能定义一些类来模拟这些Copy、Fileset，就没有这么简单明了，不信你尝试一下。

Ant给我们的重要启示就是，用XML来描述任务，能极大的扩展语言的能力。但是Ant的问题就是需要程序员处理太多的细节，指定源代码路径，指定编译文件的路径，指定资源文件的路径，指定需要的jar包及其位置，很烦心。

于是Maven出来使用“约定优于配置”的方式解决了Ant的问题。

理解了技术的本质以后就能够触类旁通，就能够快速学习，这在技术更新很快的软件行业尤为重要。

只是学会使用是不行的，不但要知道how，还要知道why。

停下来，思考，才是进步的本质。

架构师不是高高在上，脱离代码只说不做的人。架构师首先是一个优秀的程序员，要能够编写项目或产品中的核心功能，随时能够卷起袖子去解决项目中的问题。

代码写的不漂亮怎么能拿得出手？怎么能够服人？

所谓漂亮代码不仅仅是清晰、易懂、优雅，更要实现功能，没有Bug或者极少Bug。

其实如果代码简单优雅，一般没什么问题。

写出漂亮代码并不容易，需要思路清晰，有良好的编程基础，有优秀的抽象能力，以及对一门语言的熟练掌握。

抽象思考的能力怎么强调都不为过。

现实的需求纷繁复杂，如果架构师不能够把这些乱无头绪的需求抽象成一些“概念”，在概念的层次进行思考，系统根本就无法设计。

但是抽象出概念以后还不够，还要看看这个概念是不是正交的，能不能独立变化，如果不能，考虑下新的概念抽象。

“正交”讲的是线性无关，非常重要，就像一个点(x,y)，在x轴的变化不会影响y，y轴的变化不会影响x，这就是正交。

“正交”威力巨大，(x,y)可以表达二维平面的所有的点，如果增加一个z轴，不但能表达三维空间中所有的点，并且每个轴都可以独立变化。

如果能做出正交的设计，这个系统的开发和维护会非常舒服，以为可以放心大胆的修改其中一个方面儿不会影响其他。

设计模式一直强调的『发现变化并且封装变化』其实就是这个意思。

抽象能力的训练没有捷径，就是经验的积累，勤于思考和学习。例如：学习Android的程序员可以思考下Android是怎么对未知的，纷繁复杂的应用程序进行抽象的？为什么有Activity、Service、BroadcastReceiver、ContentProvider这四大组件？

深入阅读：《抽象，程序员必备的能力》

我在IBM学到的重要一课就是：要用技术的影响力来领导人，而不是威权和职位。

换句大白话来说，就是要能让技术人员服你。有了技术影响力，你在团队发出的声音才会被倾听，被尊重。

但是影响力不是很快就建成的，这是个漫长的过程：你解决了一个技术难题，你提出的方案被证明可行....

这样的事情会一点一滴的积累起你在别人心目中的形象，建立你的个人品牌，最终大家会给你贴上一个标签：大牛。