敏捷和瀑布开发模式有何不同？
How do agile and waterfall development differ?
瀑布是线性分阶段、前期完整规划再依次执行，变更成本高；敏捷以短迭代增量交付、持续反馈与调整，更适应需求不确定的项目。
Waterfall is linear staged delivery with upfront planning and high change cost; agile delivers in short iterations with continuous feedback, fitting uncertain requirements.
难度 专业 · 适合 大众
CC BY 4.0 · 已核验 · Verified 2026-10-04
来源 · Source
Cohn《Succeeding with Agile》第13章 (Prentice Hall), 2009
M. Cohn, Succeeding with Agile: Software Development Using Scrum, Chapter 13, Prentice Hall, 2009
独立核验依据 · Independent verification: 核验依据 1 ISBN 9780321579362 (2009)
#工程 #方法
Git 这类版本控制有什么用？
What is version control like Git used for?
版本控制记录文件的每一次改动历史，支持多人协作、分支开发与回滚，Git 用分布式仓库让每个开发者都拥有完整历史，便于并行与离线工作。
Version control records every change, enabling collaboration, branching and rollback; Git is distributed so each developer has the full history, aiding parallel and offline work.
难度 专业 · 适合 高中(15-18)
CC BY 4.0 · 已核验 · Verified 2026-11-06
来源 · Source
Chacon《Pro Git》第1章 (Apress)
S. Chacon, B. Straub, Pro Git, 2nd ed., Chapter 1, Apress
独立核验依据 · Independent verification: 核验依据 1 Pro Git 2nd ed. 官方全文（Apress / CC BY-NC-SA 3.0）
#工程 #工具
什么是可观测性（Observability）的三大支柱？
What are the three pillars of observability?
通常指日志（Log）、指标（Metric）和链路追踪（Trace）：日志记录离散事件，指标反映系统聚合状态，追踪还原一次请求跨服务的完整路径，三者结合快速定位线上问题。
The three pillars are logs, metrics and traces: logs record discrete events, metrics show aggregated system state, and traces reconstruct a request's path across services—together they pinpoint production issues.
难度 进阶 · 适合 小学低段(6-8)
CC BY 4.0 · 已核验 · Verified 2026-11-03
来源 · Source
B. Beyer 等（编），《SRE：Google 运维解密》，O'Reilly Media，2016
B. Beyer et al. (eds.), Site Reliability Engineering: How Google Runs Production Systems, O'Reilly Media, 2016
独立核验依据 · Independent verification: 核验依据 1 ARCHIVE 标识 sitereliabilitye0000unse：Site reliability eng
#工程 #运维
什么是 CI/CD？
What is CI/CD?
CI（持续集成）指频繁把代码合并到主干并自动构建测试；CD（持续交付/部署）把通过测试的产物自动发布到环境，减少人工、加快可靠上线。
CI merges code to trunk frequently with automated build/test; CD automatically releases passing artifacts to environments, reducing manual work and speeding reliable delivery.
难度 进阶 · 适合 初中(12-15)
CC BY 4.0 · 已核验 · Verified 2026-08-23 · 2 条独立证据
来源 · Source
Robert C. Martin,《Clean Code》Prentice Hall,2008;中译《代码整洁之道》人民邮电出版社
R. C. Martin, Clean Code, Prentice Hall, 2008; Chinese ed.
独立核验依据 · Independent verification: 核验依据 2 OPENLIBRARY 标识 /works/OL17618370W：Clean Code（按标题+作者/年份比对
#工程 #流程
代码重构的目的是什么？
What is the purpose of refactoring?
重构是在不改变外部行为的前提下改进内部结构，提升可读性与可维护性，常与测试配合，避免代码腐化和功能退化。
Refactoring improves internal structure without changing external behavior to boost readability and maintainability, usually with tests to prevent regressions.
难度 进阶 · 适合 大众
CC BY 4.0 · 来源待核验 · Source pending review
来源 · Source
出处备注：此条未指向带版次的可引用著作（通识性内容、机构文件或未展开的英文书名），本库不提供独立书目出处；如需精确引用，需由编辑补全具体篇目与版次。
Martin Fowler
Martin Fowler
#工程 #质量
技术债是什么意思？
What does technical debt mean?
技术债是为赶进度而采取的权宜实现，会在未来增加维护与修改成本；适度的债可换速度，但长期不偿还会拖慢开发与引入缺陷。
Technical debt is a quick-and-dirty implementation that speeds delivery now but raises future maintenance cost; some is acceptable, but unmanaged debt slows development and breeds bugs.
难度 进阶 · 适合 高中(15-18)
CC BY 4.0 · 来源待核验 · Source pending review
来源 · Source
出处备注：此条未指向带版次的可引用著作（通识性内容、机构文件或未展开的英文书名），本库不提供独立书目出处；如需精确引用，需由编辑补全具体篇目与版次。
Cunningham 1992
Cunningham 1992
#工程 #维护
游戏引擎里的 ECS(实体—组件—系统)架构比传统面向对象继承树好在哪里?为什么说它对 CPU 缓存更友好?
What makes the Entity-Component-System architecture better than classic OOP inheritance trees in game engines, and why is it friendlier to CPU caches?
深层继承树让不同类型实体的数据在堆上交错分布,每帧遍历更新时缓存行命中率很低;ECS 把同一种组件塞进连续数组,由 System 批量线性扫描,顺序访存能被硬件预取器充分利用。语义上它用组合代替继承,加新能力只是挂组件,不用重构类层级。Unity DOTS 与开源库 EnTT 都是该模式的代表实现,后者靠稀疏集把组件存取做到接近数组速度。
Deep inheritance trees scatter heterogeneous entities across the heap, so per-frame update loops suffer poor cache-line hit rates; ECS packs each component type into contiguous arrays scanned linearly by systems, letting sequential access fully exploit hardware prefetchers. Semantically it favors composition over inheritance: adding a capability means attaching a component instead of refactoring class hierarchies. Unity DOTS and the open-source library EnTT are representative implementations, with EnTT using sparse sets to approach array-speed component access.
难度 进阶 · 适合 初中(12-15)
CC BY 4.0 · 已核验 · Verified 2026-11-03
来源 · Source
Jason Gregory《Game Engine Architecture》(CRC Press)第三版第 15 章运行时对象模型;Unity 官方技术文档 Entity Component System(DOTS)
Jason Gregory, Game Engine Architecture, 3rd ed. (CRC Press), Chapter 15 on runtime object models; Unity official technical documentation, Entity Component System (DOTS)
独立核验依据 · Independent verification: 核验依据 1 CROSSREF 标识 10.1201/b10681：Game Engine Architecture（2009
#游戏引擎 #架构模式
开源社区常说「只要眼睛足够多,所有缺陷都很浅显」,集市模式凭什么更快抓虫?
Open source quips that given enough eyeballs, all bugs are shallow — what makes the bazaar model surface defects faster?
直答:它把调试从少数开发者的串行任务变成海量异质用户的并行同行评审。大教堂模式封闭开发、发布周期漫长,测试者背景相近、盲区也相近,缺陷潜伏期自然长;集市模式公开每行源码并压低贡献门槛,不同场景、硬件与关注点的眼睛各自扫描自己最熟悉的部分,一人眼中浅显的缺陷恰好补上他人的盲区,发现时间随参与者增多明显缩短。Raymond将此提炼为林纳斯定律,Linux内核庞大的提交者群体与快速补丁循环即其著名实证。
It turns debugging from a serial chore for a handful of developers into parallel peer review by thousands of heterogeneous users. Cathedral-style code evolves behind closed doors on long release cycles; its testers share backgrounds and therefore blind spots, so bugs incubate for ages. Bazaar projects expose every source line and slash contribution friction, letting eyes with different usage scenarios, hardware and priorities scan whatever they know best — a defect shallow to one person plugs another's blind spot, and discovery time shrinks markedly as participants multiply. Raymond distilled this into Linus's Law, with the Linux kernel's vast contributor base and rapid patch cycles as the canonical evidence.
难度 进阶 · 适合 初中(12-15)
CC BY 4.0 · 已核验 · Verified 2026-10-04
来源 · Source
Eric S. Raymond,《The Cathedral and the Bazaar》,O'Reilly Media,1999
E. S. Raymond, The Cathedral and the Bazaar, O'Reilly Media, 1999
独立核验依据 · Independent verification: 核验依据 1 ISBN 9781565928756 (1999)
#林纳斯定律 #开源协作 #同行评审
测试金字塔是什么？
What is the test pyramid?
测试金字塔建议底层大量廉价快速的单元测试，中层少量集成测试，顶层少量昂贵的端到端测试，以最低成本获得高信心。
The test pyramid suggests many cheap fast unit tests at the base, fewer integration tests in the middle, and few expensive end-to-end tests at top, maximizing confidence per cost.
难度 入门 · 适合 大众
CC BY 4.0 · 已核验 · Verified 2026-10-04
来源 · Source
Cohn《Succeeding with Agile》第13章 (Prentice Hall), 2009
M. Cohn, Succeeding with Agile: Software Development Using Scrum, Chapter 13, Prentice Hall, 2009
独立核验依据 · Independent verification: 核验依据 1 ISBN 9780321579362 (2009)
#工程 #测试