本文系统性回顾了数据库技术的发展历程与现状，从层次数据库 IMS 到新兴的向量数据库 Milvus，每一类数据库的诞生都映射了特定时代的技术挑战与应用需求。
2024年9月25日，腾研读书举办了一场对谈，腾讯研究院资深专家袁晓辉对谈前OpenAI研究员，也是《为什么伟大不能被计划》一书的两位作者肯尼斯·斯坦利（Kenneth Stanley）和乔尔·雷曼（Joel Lehman）。2个小时的时间，讨论了10个问题，涉及目标悖论、创新激励、组织活力、OpenAI能否复制、未来AI社会的前景等问题，讨论具体而深入。以下是访谈实录，推荐阅读。
刚工作时，代码写得不太好，师兄每次 CR 代码，总是会指着屏幕里的一坨代码说 “把它抽成一个类或函数”；“为什么呢？写在一起不是挺好的吗？” 我反问道；师兄老道地回答 “为了方便复用”；我仿佛若有所得，回到工位上把那些很长的代码全部抽象成了类和函数，感觉今天又有所成长。 但是随着工作经验的增加，我对此又产生了困惑。随着业务发展得越来越复杂，我当初写的那个类被大量复用，为了适应不同的场景，里面充满了 if...else...；最能代表复用的业务中台，因为分支太多，发布和开发无比复杂，很小的一个改动却需要拉一堆团队讨论。 所以类和函数的存在究竟是为了什么？只有站在更高的视角才能解决我的困惑，这也是本文的内容。 根据奥卡姆剃刀原则，本文其实用一句话就能概括， 它也是 《复杂软件设计之道》 中我最喜欢的一句话 ：类和函数不是为了复用而存在，而是他们本来就 “应该” 在那里。 如果您对这句话已经意会了，可以直接跳到评论区聊一聊看法了。 下文中主要结合历史上各位软件泰斗的观点，分别从成本和效益角度聊聊 “应该” 一词的含义。
先简单介绍下内容创作业务概要。 UP主创作的视频内容最终会以"稿件"为载体进行打包投稿。 一个稿件从创作到最终用户能观看到，需要经过非常多的环节。 从UP主的创作灵感构思，到视频剪辑，到创作完成之后进行投稿，投稿之后再经过一系列内部的加工，最终C端用户能浏览观看。 这些创作工作，都可以通过B站的集成创作工具来闭环完成。
本文概述了携程机票在基础数据处理所做的中台化设计方案。第一部分阐述了中台化的背景和面临的挑战，第二部分介绍了中台化设计的原则以及目标，第三部分详细介绍了中台化架构的关键技术实践，涉及数据一致性、数据时效性、系统健壮性、系统自动化等方面的探索和尝试，最后是整体的技术架构概览以及线上运行效果。希望以上内容能够对大家有所帮助和启发。
最近我们团队开始进行一个新项目，需要基于 Google 的 Android 14 系统源码来定制 ROM。我们需要下载 AOSP（Android Open Source Project）的代码进行开发。AOSP 是一个提供了支持移动设备和嵌入式设备开发的完整技术栈，可以用来开发智能手机、平板电脑、车载系统、智能电视等各种设备。AOSP 项目源码规模很大，占用磁盘 124.44GB，超过 1400 仓库。
重型 JS 项目的性能问题一向很难，我们在 review 各大开源 js 仓库性能实践的时候注意到：ts 源码的 checker.ts 这个文件相当暴力，它将 TS 完整类型系统全部逻辑 5.2 万行全部写在一个 ts 文件里，而文件大小则达到了惊人的 2.92 MB —— 这相当有趣，为什么？
在软件工程领域，复用与扩展性一直是开发者追求的目标，然而，这两者之间存在着天然的矛盾。本文探讨了复用的双面性——它既可能是提升效率的利器，也可能是引入复杂性和维护难题的根源。
