刚工作时，代码写得不太好，师兄每次 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 —— 这相当有趣，为什么？
在软件工程领域，复用与扩展性一直是开发者追求的目标，然而，这两者之间存在着天然的矛盾。本文探讨了复用的双面性——它既可能是提升效率的利器，也可能是引入复杂性和维护难题的根源。
技术与就业是一个古老话题。很长时间内，省力新技术往往被排斥、抵制、封禁。这方面的例子数不胜数，人们常常引用的有三个：公元一世纪，罗马皇帝韦巴芗拒绝采用新机器运输神庙石柱，因为这会抢了工人的饭碗；1589年，伊丽莎白一世以织袜机摧毁工作岗位为由，拒绝向发明家威廉·李授予专利许可；1811年，工业革命中的英国掀起了以捣毁机器为主要内容的卢德运动。 每次出现新的技术浪潮，总会引发人们对技术和就业的激烈争论。罗珊·凯许的歌名“This has happened before”和卡门·莱因哈特的书名“This time is different”，可以很好地说明人们的两种基本态度。一部分人认为“这在以前发生过”，是老问题的重复出现，没必要大惊小怪；另一部分人则大呼“这次不一样”，要变天了，经济学理论要重写。此次生成式人工智能兴起，大体也是以上两种基本态度。 技术和就业是一个“下限很低，上限很高”的话题。普通民众可以讨论原属专家的领域，能讲出道理，有自己的价值主张；专家们则极易受到民众的质疑和挑战，不管多么权威，不管研究多么扎实。
