互联网信息化咨询/技术开发/整合营销
请通过以下方式免费咨询
提交
误区三：架构经验的拿来主义
“架构师”这个职务名称，听起来比程序员或者开发，要高大上得多。这个名称也就成为我们软件技术人的重要追求之一。大家都希望自己被称呼为架构师，而不是程序员。
不要小看这种力量，这种影响会让技术团队中的相当多人，以学习足够多的和架构技术相关的名词为荣。
学习知识还能有错？这当然没有错，学海无涯，多学总是好事。但问题就出在“纸上谈兵的故事”。学成孔乙己可不是什么好事。软件架构这种东西，我始终不认为它是一种数理级别的定理级知识，我更倾向于它是经验型知识。
怎么理解经验型知识呢？
就比如，骑自行车、游泳，这些技能都是经验型技能。这种技能有个特点，就是你没有办法通过阅读甚至背诵一本《游泳技巧大全》而实现游泳技能的提升。你必须自己下水去呛水，骑上车去摔跤，然后才可能真的学会。
我曾经和一个合作团队的同事去讨论一套合作的技术方案，我提出了一套接口用法，可以相对比较容易得快速的达成双方的目标，然而我却受到了对方合作团队一个年轻同事的激烈反驳，他认为我的架构不满足架构上的某某什么原则什么理论，讲了一大串名词。最后，我们还要花费大量的时间和精力，和他逐条掰扯这样做的具体问题到底在哪里。如果真的按他说的做，除了架构上有一种莫名的数学上的美以外，没有在任何维护成本、开发速度、质量控制上的明显优势。这个就是典型的经验拿来主义。
所以我在做技术招聘的面试的时候，不管面什么内容，哪怕是问 TCP 和 UDP 有什么差别，这样基础性的问题，我喜欢反复追问的都是，UDP 与 TCP 各自存在的价值分别是什么？为什么两种方法要同时存在？我要的是这个分析过程，要的不是背诵 TCP 的各种基础结构，各种理论定义。我要的是 TCP 的每一个结构为什么要长这样？而不是那样？它当初形成的推导过程有没有思考过？只有学会了推导过程，在你遇到问题的时候，才能够通过思考的方式去进行这个事情，应该怎么做？什么方法是可以拿来用的，对吧？
我们千万要警惕团队里有人把别人写的书、做的学问、编的文章，当做像三字经一样在你面前背诵，跟你说这是某某曰过，所以要按这样做。我并不是反对去学习别人的经验，反而我很提倡多学习别人的经验，但问题是说经验拿过来用的时候，我们用的方法一定是渔法，而非鱼本身。要了解这个经验它是怎么来的，经验创造出来的一个过程，推导这个经验的过程 如果和我们当前遇到的情况很契合，所以我们才用它，而不是说因为这个经验是一个牛人说的，是一个大佬写的，是来自于一个很成功的项目得出的，于是得出我们要用，这是完全没有逻辑的。
辨别和理解这些经验的过程，或者说，自己创造属于自己经验的过程，是需要大量实践的练习与深度思考一起进行的。其实，这条误区的背后，是培养技术人才的核心技巧之一。如果有时间，我以后再写专门的文章详细讲解。
误区四：性能洁癖主义
这个误区貌似比较容易理解，只是有时候，它的存在像一个阳谋，我们知道不对劲，但却无能为力。
一般技术团队，在人多了之后，队伍里面会出现各种各样角色的人，一定会有一些完美主义倾向的，有洁癖症的一些人，他们会掺杂在里面，就会导致我们在做事情的时候容易偏离核心目的。
当然，写到这里，有些读者可能会误解我的意思——会理解为“做性能要适可而止”。但这不是我想表达的！
做性能，我是倾向于能尽可能地做到现有条件下的极致化。只有极致化的性能才能在竞争中脱颖而出，这个非常关键的，如果我们做不到，往往是资源不够，或者能力不够，而不是决心不够，这个不是什么误区。我要讲的误区是：“我们往往因为追求常规的性能参数，而丧失更重要的体验级性能” ，这才是很多人，难以跳脱出来的误区。
继续举一个例子：大家都在传微信诞生之初，腾讯内部有三个团队都在做微信，最后是张小龙的团队胜出。这个故事不是完全真实，但是确实也是有故事的原型的。我就是当时其中一个团队的技术负责人，也确实有在和张小龙的团队竞争（当然，龙哥现在已经是我的老板了）。我们当时的产品叫做 Q 信，用 Q 信来发 IM 消息、语音消息、图片消息。过程中，要解决一个问题“移动端信号不如有线网稳定的情况下，如何做到像系统短信一样极高的发送成功率？”那时候，3G 时代还在巅峰，4G 尚未完全普及，一部分用户还依然在使用网络极差的 2G。基于当时的条件下，我们对信号弱，发送失败的情况设计了大量的重试策略、动态化的重试步长、网络探测策略，等等各种复杂规则。
但是，我们发现，无论怎么做，发送消息失败的概率，以及发送成功的速度，都还是明显弱于微信。我们始终无法正确预测用户什么时候突然进入电梯没有信号了，什么时候又出了电梯，什么时候又进入隧道没有信号了， 而微信却仿佛能够预测未来一样，总是在用户走出电梯的一瞬间，把消息发送成功。
我们的问题出在哪？
我在反复琢磨了很久并对微信抓包分析之后，才后知后觉。其实一切都很简单，是我们自己错误的性能追求框死了自己。因为我们做了多年的移动端 App，对移动端 App 省电的经验深入骨髓，这样的经验前提下，我们所有的重试策略都会制定时间间隔、重试次数，我们像洁癖症患者一样，不允许任何无畏的耗电。压根不会跨出省电的大前提去设计技术方案。而微信的做法，简单粗暴，在消息发送不成功的时候，快速、多次不断地重试。当然可以在用户打开电梯门，网络恢复的一瞬间，马上发送消息成功！我们犯了一个致命的错误，就是我们并没有去计算我们通过这套复杂的省电规则，到底节省了多少电？节省的这点有限的电量（后来证明，由于异端场景的概率问题，节省的电量极少），能否比得上一个发消息速度极快且极其稳定不惧网络波动的软件，带来用户的信心的价值？一款产品的成功，掺杂着无数条类似这样能勘破常规误区，能直击靶心的思维尖刀！而在当时欠缺这套能力的 Q 信，显然差距还比较明显。
更多新闻
