沟通创造价值，分享带来快乐。这里是程序员周刊，分享个人阅读所得，欢迎您每周五和我一起做时间的朋友。

架构

有人问百度搜索引擎架构师谭待：

您从事架构相关工作多年，在您看来，架构的本质是什么？

谭待：

架构的本质是折中，作为架构师，你拥有的资源是有限，如人力资源、机器资源等，但你面对的需求是无限的，如工期的需求、稳定性的需求等，所以需要在不同的层面做出折中的选择。你不可能做出一个完美的解决方案，必然要牺牲一些东西来达成另一些需求。

解读：

谭待对架构的理解我觉得更多的是偏向商业方向，因为也有些人会觉得架构的本质就是为了解决业务膨胀带来的系统复杂性。我觉得也不能说谁对谁错，只是谭待的维度更高罢了。

谭待认为：

首先，作为架构师，要明确你设计系统最终还是为了产品和业务，所以，你要了解产品和业务的需求，并做出相应的预判，比如预判这个产品三年以后会是什么样的。这样你设计的系统，就有足够的预留空间和生命周期。

在百度，我们设计系统的时候，一般会去看业务三年以后的情况，这样做出来的系统，至少 在三年内能比较好地支撑业务发展。

解读：

这里讲的需求调研部分，一般的架构师可能都会存在这么一个问题，就是着眼于当下的业务需求，有些偏技术思维的架构师会排斥业务，觉得学习业务太Low了，从心态上就决定了他不可能全面深入的学习业务。最后做出来的架构可能就是一个通用架构，没有针对性。

谭待：

其次，作为架构师，在设计系统的时候，一定要找到关键点。折中不是平庸，而是为了更好 的在某些关键点上突出，为此，可以在别的地方做出牺牲。

我父亲小时候给我讲了一个故事，至今印象深刻。20 世纪初期，美国福特公司的一台电机 出现故障，很多人花了两三个月都修不好。在束手无策的情况下请来了专家斯坦门茨，斯坦 门茨在电机旁边仔细观察，又计算了两天后，就用粉笔在电机的外壳上画了一条线， 说：“打开电机，在这条线往里的线圈减少 16 圈。”结果证明，问题果真出在这里。

谭待总结到：

这个故事给我的感触很深，作为架构师，你一定要成为那个划线的人。一个架构会涉及方方 面面，不可能全都很好的顾及，所以，你需要找到那条线，找到问题的关键，并将其解决， 这才是最能体现架构师价值的地方。

解读：

因为资源有限，需求无限所以要折中；因为只能看到有限的业务，所以要折中；因为系统的瓶颈只有一个，所以要折中。

成长

做事情的时候可以分成两种角色：生产者和消费者。学习本身其实是一种消费，每天忙着去读书，看起来是在学习，但是学完以后你的生活和工作因此改变了吗？或者说有产出和输出吗？如果没有，每天的日子还是老样子，工作和生活也没有改变，这样的学习和玩一会手机、看一会抖音在本质上并没有太大的区别。——李智慧（同程艺龙CTO）

我平时喜欢看各种书籍，不限于技术，看多了就有一种憋在心里不得不吐的感觉，所以才有了程序员周刊，而且周刊也不仅是分享技术观，这么做是倒逼自己做一个消费者，同时也必须做一个生产者，是一份从自乐走向众乐的过程，个人还是很享受。

回到程序员的角色，从另外一个角度看，其实重复造轮子对程序员是很有用处的，消费一个开源框架，我都要告诫自己要融会贯通从头做出来，并且能在工作中进行运用，否则自己就不是真正的懂。

数据

数据是堪比石油，下面分享的是彭跃辉（Keep CTO）团队做数据中台过程中遇到的挑战和解决方案。

• 挑战：数据不准确，原因有：

1. 团队对目标定义不清楚。
2. 产品经理提的需求不够准确。
3. 开发人员技能不一样。
4. 数据分析时，每个部门对数据的理解不同。

解决手段：

1. 需求评审时更细致。
2. 开发过程中进行灰度测试、半自动化测试等。
3. 搭建数据仓库等基础设施。
4. 把公司内各部门对相关数据的定义统一起来，使数据的维护与管理在一个统一的系统中进行。

开源

• Phabricator（https://github.com/phacility/phabricator）

我们鼓励团队成员使用工具来提高效率，并给予一定的费用支持。我们现在用的是 Phabricator，这是 Facebook 的一个代码管理和项目管理的工具，通过Phabricator 我们进行敏捷迭代，基本保持每两周一个迭代的频率，给用户提供一个稳定的版本。

• 可视化平台dooringx（github.com/H5-Dooring/dooringx）

GitHub 上开源的可视化平台搭建方案：dooringx，通过提供一套数据流事件机制、弹窗等解决方案，让你可以快速定制一个可视化拖拽平台。

• ulid（https://github.com/ulid/spec）

一个独特 ID 的生成库，对 uuid 进行了多方面的改进。

• SolidJS（https://www.solidjs.com/）

一个前端框架，完全借鉴了 React，但是把数据通信改成了基于事件的响应式（reactivity）。

• 初学者的 Web 开发教程（https://microsoft.github.io/Web-Dev-For-Beginners/#/）

微软提供的是一个初级教程，讲授 JavaScript、CSS 和 HTML 的基本知识。

• Kubernetes 纪录片（https://www.bilibili.com/video/BV13q4y1h7QR）

这个纪录片是关于 Kubernetes 项目的介绍，包括起源、命名、logo以及很多背后的故事。这里是 B 站的中文字幕版。

管理

下面分享彭跃辉（Keep CTO）的技术管理思想。

1.人员成长

从两个方面做好技术人员的成长路线

首先，打造技术人员的专业定级体系。

• 级别：从多个维度定义一个工程师的级别，很多工程师选择走专业路线，那他得知道自己当前的位置在哪，要到下一个级别还有哪些欠缺。
• 答辩：每一个小级别的晋升都需要进行答辩。答辩规则是 5 到 7 人评审，两票否决制，一旦有两个人否决，则答辩失败。
• 薪资：根据定好的级别来调整他们的薪水、奖金，逐步打造了一个相对完善的技术职级体系。

其次，组织内部分享和外部交流。

• 分享：内部每个小组，都会有半年到一年的分享计划。

• 交流：经常跟一些其他行业的人沟通、交流，每年都会挑选优秀的员工去参加 Google IO、WDDC 等大型会议，由公司承担机票、酒店等费用。参加腾讯举办的各种培训。

一般团队的架构都是三角形的，级别越高的人越少，处在三角形底边的人更多，但我们现在正在通过以上提到的这些方法，慢慢让这个三角形的底部变窄，相当于将初级技术能力者的比例减少，增加中层级别甚至高级别的技术专家，将整个团队往精英化方向打造。

2.技术管理

问：“技术人员如果想走上管理路线，该如何打开边界提升自己的管理能力呢？”

彭跃辉认为对技术管理者的要求分为三部分：

第一部分是技术能力，需要具备把某功能或某业务实现并实现好的能力，我们会通过质量、效率等维度评估。

第二部分是业务能力，需要知道业务未来的方向，以及你的技术架构如何为这个业务服务，包括在当前阶段，应该做什么事情，不应该做什么事情。

针对技术管理者的业务理解能力，会定期组织大家针对业务中存在的问题进行开放性讨论，从实践结果来看，这个方法比较有效。

第三部分是创新能力，看重技术 leader 的创新能力。鼓励技术 leader 去做一些有挑战的事情，比如最近要上线的游泳记录硬件，它可以记录游泳的姿势、游泳的距离等。

以上三点仅供参考。

人文

谁都不喜欢行李重啊。但不知不觉行李就变重了。这就是人生啊！——村上春树

有时候真实比小说更加荒诞，因为虚构是在一定逻辑下进行的，而现实往往毫无逻辑可言。——马克吐温

惟沉默是最高的轻蔑。——鲁迅

我最崇拜的人是我，只有我才会帮自己度过一山又一山，克服一次又一次难关。—— 亦舒

解读：我想说的是，我命由我不由天，你要做自己的主人，要对自己负责。举个反例，我小的时候一直都是比较乖宝宝类型的，小时候听父母的，上学听老师的，工作听领导的。突然有一天，就是一瞬间惊醒：我这么听你们的，你们会对我负责吗，父母会养我一辈子吗，老师能保证我的将来吗，领导会让我在公司干一辈子吗？你如果不能对我负责，我都听你的有什么用。谁能对我负责？只有自己对自己负责。天生我才必有用。

这短短的一生，我们最终都会失去。你不妨大胆一些，爱一个人，攀一座山，追一个梦。——《大鱼海棠》

以上引用或言论如果有不当，侵害到你的权利，请你联系我进行删除，谢谢!