principle-foundational-thinking

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Foundational Thinking

基础思维

Structural decisions protect option value. Code-level decisions protect simplicity. Over-engineering is often a premature decision that closes doors. The right foundational data structure keeps doors open.
Data structures first. Get the data shape right before writing logic. The right shape makes downstream code obvious. Define core types early, trace every access pattern, and choose structures that match the dominant paths. A data-structure change late is a rewrite. Early, it is often a one-line diff.
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.
Subtraction comes before scaffolding: remove dead weight first, then lay foundations.
结构性决策能保留选择空间。代码层面的决策能保障简洁性。过度设计往往是一种过早做出的决策,会限制后续的可能性。合理的基础数据结构则能为后续发展留有余地。
优先考虑数据结构。在编写逻辑之前先确定正确的数据形态。合适的数据形态会让下游代码的编写变得一目了然。尽早定义核心类型,追踪所有访问模式,选择与主要操作路径匹配的数据结构。后期修改数据结构相当于重写代码,而早期修改通常只需一行代码变更。
在代码层面,要对结构进行DRY(Don't Repeat Yourself,避免重复),而非逐行重复。类型与数据模型应保持一致。三个相似的语句仍优于过早的抽象化。优先选择明确的实现而非巧妙的技巧。测试行为与边缘情况,而非代码行数。
并发推论。在多个参与者之间共享状态前,先问自己:“如果另一个参与者同时修改该状态会发生什么?”如果答案不是“无影响”,则应进行隔离处理。
优先搭建脚手架。如果某项工作对后续所有阶段都有帮助,就先完成它。问问自己:“后续每个阶段是否都会因这项工作的存在而受益?”CI、代码检查、测试基础设施以及共享类型都属于脚手架范畴。按照保留选择空间的原则规划顺序:先搭建基础再开发功能,先编写测试再修复问题。保持提交的粒度小且单一。
搭建脚手架前先做减法:先移除无用代码,再奠定基础。