software-laws

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Software Laws

Use software laws as prompts for judgment, not as automatic verdicts. Read the complete reference when exact wording, context, attribution, or sources matter.

将软件法则作为判断的参考依据，而非绝对定论。当需要精确措辞、上下文背景、归属信息或来源资料时，请阅读完整参考文档。

Method

方法

State the outcome, project constraints, current evidence, and decision to make.
Select only laws that describe a relevant force. Translate each one into a concrete risk or prediction.
Identify competing forces. State which concern controls this decision and why.
Inspect the repository and actual usage. Measure or run the smallest useful test when a claim is uncertain.
Choose the simplest complete action supported by the evidence. Record the tradeoff and the signal that would justify revisiting it.

明确预期结果、项目约束条件、现有依据以及待做的决策。
仅选择描述相关影响因素的法则，并将每条法则转化为具体的风险或预测。
识别相互冲突的影响因素，说明哪项关注点主导本次决策及其原因。
检查代码仓库和实际使用情况。当某项主张存疑时，执行最小规模的有效测试或进行度量。
选择有依据支撑的最简单且完整的行动方案。记录本次权衡决策，以及后续需要重新审视该决策的触发信号。

Planning and Scope

规划与范围

Start with the smallest system that works, then add complexity only for observed needs. Protect the product's core purpose from feature creep.
Treat estimates as uncertain. Limit work in progress, shorten feedback loops, and include integration and coordination cost.
Do not assume that adding people will recover a late project. Reduce scope or unblock the critical path first.
Expect architecture to reflect communication paths. Align ownership and team boundaries with the desired system boundaries.
Use metrics as signals rather than targets. Pair them with the real outcome and watch for gaming, shifted definitions, and misleading denominators.
Prefer proven technology when stability is the main need. Prefer newer capability only when project evidence shows a material advantage.

从最小可用系统开始，仅根据实际观测到的需求增加复杂度。保护产品核心目标不受功能蔓延的影响。
将估算视为不确定性内容。限制在研工作项数量，缩短反馈周期，并将集成与协调成本纳入考量。
不要假设增加人员就能挽救进度滞后的项目。应首先缩减范围或打通关键路径。
架构应反映团队沟通路径。将职责归属和团队边界与预期的系统边界保持一致。
将指标视为信号而非目标。结合实际结果进行分析，警惕指标操纵、定义变更以及具有误导性的分母。
当稳定性为主要需求时，优先选用成熟技术。仅当项目证据表明新技术能带来实质性优势时，才考虑其新功能。

Design and Interfaces

设计与接口

Assume users can depend on every observable API behavior. Inspect real consumers before changing behavior, and make compatibility decisions explicit.
Keep abstractions small and understandable. Plan for the implementation details that leak through performance, failures, or operations.
Choose languages and tools that provide the needed concepts directly. Avoid rebuilding higher-level facilities inside an unsuitable foundation.
Make frequent interface targets easy to reach and use. Apply target size and distance to screens, commands, and API ergonomics.
Design security to hold when the implementation is known. Keep secrets in keys or protected data, not in hidden design details.
Balance tolerant input handling against ambiguity, maintenance, and attack surface. Use the protocol, threat model, and interoperability needs to decide strictness.

假设用户会依赖API的所有可观测行为。在变更行为前检查实际使用者情况，并明确兼容性决策。
保持抽象简洁易懂。针对因性能、故障或运维问题而暴露的实现细节做好预案。
选择能直接提供所需概念的语言和工具。避免在不合适的基础架构上重新构建高层功能。
让常用的接口目标易于访问和使用。将目标大小与距离的设计原则应用于界面、命令和API的人机工程学设计中。
设计安全机制时，需确保即使实现细节被公开仍能保障安全。将机密信息存储在密钥或受保护的数据中，而非隐藏的设计细节里。
在容错输入处理与歧义性、维护成本及攻击面之间取得平衡。根据协议、威胁模型和互操作性需求决定输入校验的严格程度。

Implementation and Performance

实现与性能

Prefer code that is easy to debug over clever code that is merely easy to write.
Avoid speculative micro-optimization, but do not ignore known load or architectural limits. Benchmark representative behavior before and after a performance choice.
Treat cheaper compute and improved hardware as capacity that software and demand can consume. Set explicit performance budgets instead of assuming hardware gains will compensate.
For AI systems, compare scalable search, learning, data, and compute with domain-specific methods using task evidence. Check data limits, cost, and evaluation quality before relying on scale.
Treat generated or automated output as the result of inputs, objectives, tools, and checks. Verify its behavior rather than assuming originality or correctness.

优先选择易于调试的代码，而非仅易于编写的巧妙代码。
避免投机性的微优化，但也不要忽视已知的负载或架构限制。在做出性能优化决策前后，对代表性行为进行基准测试。
将更廉价的计算资源和性能提升的硬件视为软件与需求会消耗的容量。设定明确的性能预算，而非假设硬件升级能弥补软件性能不足。
针对AI系统，结合任务证据对比可扩展的搜索、学习、数据和计算方案与领域特定方法。在依赖规模化方案前，检查数据限制、成本及评估质量。
将生成式或自动化输出视为输入、目标、工具和校验机制共同作用的结果。需验证其行为，而非假设其原创性或正确性。

Delivery and Review

交付与评审

Add reviewers for relevant knowledge and independent diagnosis, not as a substitute for clear ownership. Separate the value of more eyes from the coordination cost of more contributors.
Invite correction with a concrete proposal, failing example, or falsifiable claim. Do not confuse argument volume with evidence.
Give teams a clear mission and useful autonomy. Check incentives, communication paths, and role capability instead of assuming motivation or hierarchy guarantees results.
Examine whether a process, team, or product benefits from preserving the problem it claims to solve. Judge success by the user outcome.

邀请具备相关知识的人员参与评审以提供独立诊断，而非用评审替代明确的职责归属。区分多视角评审的价值与多参与者带来的协调成本。
提出修正意见时需附带具体方案、失败案例或可证伪的主张。不要将争论的激烈程度等同于证据的有效性。
为团队设定明确的使命并赋予有效的自主权。检查激励机制、沟通路径和角色能力，而非假设积极性或层级结构能保证结果。
审视流程、团队或产品是否从保留其声称要解决的问题中获益。以用户成果来评判成功与否。

Constraints

约束条件

Never use a law's name or slogan as sufficient justification.
Distinguish descriptive trends from prescriptive rules.
State important conflicts, especially simplicity versus scale, compatibility versus change, tolerance versus security, optimization versus maintainability, and added review versus coordination cost.
Ground recommendations in current project context, observed behavior, measured data, or a small benchmark.
Apply the laws only within the conditions that make their underlying mechanism relevant.

切勿仅以法则的名称或口号作为充分的决策依据。
区分描述性趋势与规范性规则。
明确重要的冲突点，尤其是简洁性与规模化、兼容性与变更、容错性与安全性、优化与可维护性，以及额外评审与协调成本之间的冲突。
建议需基于当前项目上下文、观测到的行为、度量数据或小型基准测试。
仅在法则的底层机制适用的场景下应用这些法则。