三、架构经验的拿来主义
“架构师”这个职务名称，听起来比程序员或者开发，要高大上得多。这个名称也就成为我们软件技术人的重要追求之一。大家都希望自己被称呼为架构师，而不是程序员。不要小看这种力量，这种影响会让技术团队中的相当多人，以学习足够多的和架构技术相关的名词为荣。学习知识还能有错？这当然没有错，学海无涯，多学总是好事。但问题就出在“纸上谈兵的故事”。学成孔乙己可不是什么好事。软件架构这种东西，我始终不认为它是一种数理级别的定理级知识，我更倾向于它是经验型知识。就比如，骑自行车、游泳，这些技能都是经验型技能。这种技能有个特点，就是你没有办法通过阅读甚至背诵一本《游泳技巧大全》而实现游泳技能的提升。你必须自己下水去呛水，骑上车去摔跤，然后才可能真的学会。我曾经和一个合作团队的同事去讨论一套合作的技术方案，我提出了一套接口用法，可以相对比较容易得快速的达成双方的目标，然而我却受到了对方合作团队一个年轻同事的激烈反驳，他认为我的架构不满足架构上的某某什么原则什么理论，讲了一大串名词。最后，我们还要花费大量的时间和精力，和他逐条掰扯这样做的具体问题到底在哪里。如果真的按他说的做，除了架构上有一种莫名的数学上的美以外，没有在任何维护成本、开发速度、质量控制上的明显优势。这个就是典型的经验拿来主义。所以我在做技术招聘的面试的时候，不管面什么内容，哪怕是问 TCP 和 UDP 有什么差别，这样基础性的问题，我喜欢反复追问的都是，UDP 与 TCP 各自存在的价值分别是什么？为什么两种方法要同时存在？我要的是这个分析过程，要的不是背诵 TCP 的各种基础结构，各种理论定义。我要的是 TCP 的每一个结构为什么要长这样？而不是那样？它当初形成的推导过程有没有思考过？只有学会了推导过程，在你遇到问题的时候，才能够通过思考的方式去进行这个事情，应该怎么做？什么方法是可以拿来用的，对吧？
我们千万要警惕团队里有人把别人写的书、做的学问、编的文章，当做像三字经一样在你面前背诵，跟你说这是某某曰过，所以要按这样做。我并不是反对去学习别人的经验，反而我很提倡多学习别人的经验，但问题是说经验拿过来用的时候，我们用的方法一定是渔法，而非鱼本身。要了解这个经验它是怎么来的，经验创造出来的一个过程，推导这个经验的过程 如果和我们当前遇到的情况很契合，所以我们才用它，而不是说因为这个经验是一个牛人说的，是一个大佬写的，是来自于一个很成功的项目得出的，于是得出我们要用，这是完全没有逻辑的。辨别和理解这些经验的过程，或者说，自己创造属于自己经验的过程，是需要大量实践的练习与深度思考一起进行的。其实，这条误区的背后，是培养技术人才的核心技巧之一。如果有时间，我以后再写专门的文章详细讲解。
获取报价
销售热线
返回顶部
在线咨询
一键拨打