principle-foundational-thinking
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseFoundational Thinking
基础性思维
Structural decisions protect option value. Code-level decisions protect simplicity.
Data structures first. Get the data shape right before writing logic. Define core types early, trace every access pattern, and choose structures that match the dominant paths.
At code level, DRY the structure, not every line. Types and data models should converge. Three similar statements still beat a premature abstraction. Prefer explicit over clever. Test behavior and edge cases, not line counts.
Concurrency corollary. Before sharing state between actors, ask "what happens if another actor modifies this concurrently?" If not "nothing", isolate.
Scaffold first. If something helps every later phase, do it first. Ask "does every subsequent phase benefit from this existing?" CI, linting, test infrastructure, and shared types are scaffold. Sequence for option value: setup before features, tests before fixes. Keep commits small and single-purpose.
Each increment should land a coherent abstraction or deepen one that exists. Do not spread a new capability across callers as special-case coordination.
Subtraction comes before scaffolding. Remove dead code first, then lay foundations.
结构性决策保留选择空间。代码级决策保障简洁性。
数据结构优先。 在编写逻辑之前,先确定合适的数据形态。尽早定义核心类型,梳理每一种访问模式,并选择与主要访问路径相匹配的数据结构。
在代码层面,应当对结构进行 DRY,而不是对每一行代码进行 DRY。类型和数据模型应当逐步收敛。三条相似的语句仍然优于过早抽象。显式优于巧妙。测试应关注行为和边界情况,而不是代码行数。
并发方面的推论。 在多个执行者之间共享状态之前,先问:“如果另一个执行者并发修改它,会发生什么?”如果答案不是“什么都不会发生”,就应当进行隔离。
Scaffold 优先。 如果某项内容对之后的每个阶段都有帮助,就先完成它。问自己:“现有的这项内容是否能让每个后续阶段受益?”CI、linting、测试基础设施和共享类型都属于 scaffold。围绕选择空间安排工作顺序:先完成配置,再开发功能;先编写测试,再修复问题。保持提交小而职责单一。
每次增量都应落地一个连贯的抽象,或深化一个已有抽象。不要将新能力分散到各个调用方中,使其变成特殊用例之间的协调。
先做减法,再搭 scaffold。 先移除无用代码,再铺设基础。