pragmatic-programmer

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

The Pragmatic Programmer Framework

《程序员修炼之道》框架

A systems-level approach to software craftsmanship from Hunt & Thomas' "The Pragmatic Programmer" (20th Anniversary Edition). Apply these principles when designing systems, reviewing architecture, writing code, or advising on engineering culture. This framework addresses the meta-level: how to think about software, not just how to write it.

这是基于Hunt & Thomas所著《程序员修炼之道》（20周年纪念版）提出的系统级软件工艺方法。在设计系统、评审架构、编写代码或指导工程文化时，均可应用这些原则。该框架聚焦元层面：即如何思考软件，而非仅关注如何编写代码。

Core Principle

核心原则

Care about your craft. Software development is a craft that demands continuous learning, disciplined practice, and personal responsibility. Pragmatic programmers think beyond the immediate problem -- they consider context, trade-offs, and long-term consequences of every technical decision.

The foundation: Great software comes from great habits. A pragmatic programmer maintains a broad knowledge portfolio, communicates clearly, avoids duplication ruthlessly, keeps components orthogonal, and treats every line of code as a living asset that must earn its place. The goal is not perfection -- it is building systems that are easy to change, easy to understand, and easy to trust.

重视你的手艺。 软件开发是一门需要持续学习、严谨实践和个人责任感的手艺。务实的程序员会超越眼前的问题——他们会考虑每个技术决策的背景、权衡因素和长期影响。

基础： 优秀的软件源于良好的习惯。务实的程序员会维护广泛的知识体系、清晰沟通、坚决避免重复、保持组件正交性，并将每一行代码视为必须证明其存在价值的鲜活资产。目标并非完美——而是构建易于变更、易于理解且值得信赖的系统。

Scoring

评分标准

Goal: 10/10. When reviewing or creating software designs, architecture, or code, rate it 0-10 based on adherence to the principles below. A 10/10 means full alignment with all guidelines; lower scores indicate gaps to address. Always provide the current score and specific improvements needed to reach 10/10.

目标：10/10分。 在评审或创建软件设计、架构或代码时，根据对以下原则的遵守程度从0-10分进行评级。10分表示完全符合所有准则；分数越低则说明存在需要解决的差距。需始终提供当前分数以及达到10分所需的具体改进措施。

The Pragmatic Programmer Framework

《程序员修炼之道》框架

Seven meta-principles for building software that lasts:

构建持久软件的七大元原则：

1. DRY (Don't Repeat Yourself)

1. DRY（Don't Repeat Yourself，不要重复自己）

Core concept: Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. DRY is about knowledge, not code -- duplicated logic, business rules, or configuration are far more dangerous than duplicated syntax.

Why it works: When knowledge is duplicated, changes must be made in multiple places. Eventually one gets missed, introducing inconsistency. DRY reduces the surface area for bugs and makes systems easier to change.

Key insights:

DRY applies to knowledge and intent, not textual similarity -- two identical code blocks serving different business rules are NOT duplication
Four types of duplication: imposed (environment forces it), inadvertent (developers don't realize), impatient (too lazy to abstract), inter-developer (multiple people duplicate)
Code comments that restate the code violate DRY -- comments should explain why, not what
Database schemas, API specs, and documentation are all sources of duplication if not generated from a single source
The opposite of DRY is WET: "Write Everything Twice" or "We Enjoy Typing"

Code applications:

Context	Pattern	Example
Config values	Single source of truth	Define DB connection in one env file, reference everywhere
Validation rules	Shared schema	Use JSON Schema or Zod schema for both client and server validation
API contracts	Generate from spec	OpenAPI spec generates types, docs, and client code
Business logic	Domain module	Tax calculation in one module, not scattered across controllers
Database schema	Migration-driven	Schema defined in migrations, ORM models generated from DB

See: references/dry-orthogonality.md

核心概念： 系统中的每一项知识都必须有单一、明确且权威的表示。DRY关注的是知识，而非代码——重复的逻辑、业务规则或配置比重复的语法危险得多。

为何有效： 当知识存在重复时，变更必须在多个地方进行。最终总会有一处被遗漏，导致不一致性。DRY减少了bug的产生范围，让系统更易于变更。

关键见解：

DRY适用于知识和意图，而非文本相似性——两个服务于不同业务规则的相同代码块不属于重复
四种重复类型：强制型（环境所迫）、无意型（开发者未意识到）、急躁型（懒得抽象）、跨开发者型（多人重复编写）
重述代码的注释违反DRY原则——注释应解释「为什么」，而非「是什么」
数据库 schema、API 规范和文档如果不是从单一源生成，都会成为重复的来源
DRY的对立面是WET：「Write Everything Twice（重复编写所有内容）」或「We Enjoy Typing（我们喜欢打字）」

代码应用场景：

场景	模式	示例
配置值	单一可信源	在一个环境文件中定义数据库连接信息，在所有地方引用
验证规则	共享 schema	使用JSON Schema或Zod schema同时用于客户端和服务端验证
API 契约	从规范生成	OpenAPI 规范用于生成类型、文档和客户端代码
业务逻辑	领域模块	税务计算逻辑集中在一个模块中，而非分散在各个控制器
数据库 schema	迁移驱动	schema在迁移中定义，ORM模型从数据库生成

参考：references/dry-orthogonality.md

2. Orthogonality

2. 正交性

Core concept: Two components are orthogonal if changes in one do not affect the other. Design systems where components are self-contained, independent, and have a single, well-defined purpose.

Why it works: Orthogonal systems are easier to test, easier to change, and produce fewer side effects. When you change the database layer, the UI should not break. When you change the auth provider, the business logic should not care.

Key insights:

Ask: "If I dramatically change the requirements behind a particular function, how many modules are affected?" The answer should be one
Eliminate effects between unrelated things -- a logging change should never break billing
Layered architectures promote orthogonality: presentation, domain logic, data access
Avoid global data -- every consumer of global state is coupled to it
Toolkits and libraries that force you to inherit from framework classes reduce orthogonality

Code applications:

Context	Pattern	Example
Architecture	Layered separation	Controller -> Service -> Repository, each replaceable
Dependencies	Dependency injection	Pass a `Notifier` interface, not a `SlackClient` concrete class
Testing	Isolated unit tests	Test business logic without database, network, or filesystem
Configuration	Environment-driven	Feature flags in config, not `if` branches in business logic
Deployment	Independent services	Deploy auth service without redeploying payment service

See: references/dry-orthogonality.md

核心概念： 若两个组件的变更互不影响，则它们是正交的。设计系统时应让组件具备自包含、独立且单一明确的用途。

为何有效： 正交系统更易于测试、变更，且产生的副作用更少。当你修改数据库层时，UI不应崩溃；当你更换认证提供商时，业务逻辑不应受到影响。

关键见解：

自问：「如果我大幅改变某个功能的需求，会影响多少个模块？」答案应该是1个
消除无关事物之间的影响——日志变更绝不应该破坏计费功能
分层架构有助于实现正交性：表现层、领域逻辑层、数据访问层
避免全局数据——每个全局状态的使用者都会与其耦合
强制要求继承框架类的工具包和库会降低正交性

代码应用场景：

场景	模式	示例
架构	分层分离	控制器 -> 服务 -> 仓库，每个层均可替换
依赖	依赖注入	传递 `Notifier` 接口，而非 `SlackClient` 具体类
测试	独立单元测试	在不依赖数据库、网络或文件系统的情况下测试业务逻辑
配置	环境驱动	功能标志在配置中设置，而非业务逻辑中的 `if` 分支
部署	独立服务	部署认证服务时无需重新部署支付服务

参考：references/dry-orthogonality.md

3. Tracer Bullets and Prototypes

3. 追踪代码与原型

Core concept: Tracer bullets are end-to-end implementations that connect all layers of the system with minimal functionality. Unlike prototypes (which are throwaway), tracer bullet code is production code -- thin but real.

Why it works: Tracer bullets give immediate feedback. You see what the system looks like end-to-end before investing in filling out every feature. Users can see something real, developers have a framework to build on, and integration issues surface early.

Key insights:

Tracer bullet: thin but complete path through the system (UI -> API -> DB) -- you keep it
Prototype: focused exploration of a single risky aspect -- you throw it away
Tracer bullets work when you're "shooting in the dark" -- requirements are vague, architecture is unproven
If a tracer misses, adjust and fire again -- the cost of iteration is low
Prototypes should be clearly labeled as throwaway -- never let a prototype become production code

Code applications:

Context	Pattern	Example
New project	Vertical slice	Build one feature end-to-end: button -> API -> DB -> response
Uncertain tech	Spike prototype	Test if WebSocket performance is sufficient before committing
Framework eval	Tracer through stack	Build login flow through the full framework before choosing it
Microservice	Walking skeleton	Deploy a hello-world service through the full CI/CD pipeline
Data pipeline	End-to-end flow	One record from ingestion through transformation to output

See: references/tracer-bullets.md

核心概念： 追踪代码是连接系统所有层级的端到端实现，功能极简。与原型（可丢弃）不同，追踪代码是生产代码——虽精简但真实可用。

为何有效： 追踪代码能提供即时反馈。在投入大量精力完善所有功能之前，你就能看到系统的端到端效果。用户能看到真实的产品，开发者有了构建的框架，集成问题也能提前暴露。

关键见解：

追踪代码：贯穿系统的精简但完整路径（UI -> API -> 数据库）——会被保留下来
原型：聚焦探索单一风险点——会被丢弃
当你「在黑暗中摸索」时（需求模糊、架构未经验证），追踪代码非常有用
如果一次追踪未达预期，调整后再尝试——迭代成本很低
原型应明确标记为可丢弃——绝不能让原型成为生产代码

代码应用场景：

场景	模式	示例
新项目	垂直切片	端到端构建一个功能：按钮 -> API -> 数据库 -> 响应
不确定技术	探索型原型	在投入之前测试WebSocket性能是否达标
框架评估	全栈追踪	在选择框架之前，通过完整框架构建登录流程
微服务	行走骨架	通过完整CI/CD管道部署一个hello-world服务
数据管道	端到端流程	一条记录从 ingestion 到转换再到输出的完整流程

参考：references/tracer-bullets.md

4. Design by Contract and Assertive Programming

4. 契约式设计与断言式编程

Core concept: Define and enforce the rights and responsibilities of software modules through preconditions (what must be true before), postconditions (what is guaranteed after), and class invariants (what is always true). When a contract is violated, fail immediately and loudly.

Why it works: Contracts make assumptions explicit. Instead of silently corrupting data or limping along in an invalid state, the system crashes at the point of the problem -- making bugs visible and traceable. Dead programs tell no lies.

Key insights:

Preconditions: caller's responsibility -- "I accept only positive integers"
Postconditions: routine's guarantee -- "I will return a sorted list"
Invariants: always true -- "Account balance never goes negative"
Crash early: a dead program does far less damage than a crippled one
Use assertions for things that should never happen; use error handling for things that might
In dynamic languages, implement contracts through runtime checks and guard clauses

Code applications:

Context	Pattern	Example
Function entry	Precondition guard	`assert age >= 0, "Age cannot be negative"` at function start
Function exit	Postcondition check	Verify returned list is sorted before returning
Class state	Invariant validation	`validate!` method called after every state mutation
API boundary	Schema validation	Validate request body against schema before processing
Data pipeline	Stage assertions	Assert row count after ETL transform matches expectation

See: references/contracts-assertions.md

核心概念： 通过前置条件（执行前必须满足的条件）、后置条件（执行后保证满足的条件）和类不变量（始终满足的条件）来定义并强制执行软件模块的权利与责任。当契约被违反时，立即且明确地终止程序。

为何有效： 契约让假设变得明确。系统不会默默损坏数据或在无效状态下勉强运行，而是在问题发生点崩溃——让bug可见且可追踪。崩溃的程序不会说谎。

关键见解：

前置条件：调用方的责任——「我只接受正整数」
后置条件：程序的保证——「我会返回一个排序后的列表」
不变量：始终成立——「账户余额永远不会为负」
尽早崩溃：崩溃的程序造成的损害远小于瘫痪的程序
断言用于处理绝不可能发生的情况；错误处理用于处理可能发生的情况
在动态语言中，通过运行时检查和守卫子句实现契约

代码应用场景：

场景	模式	示例
函数入口	前置条件守卫	函数开始处使用 `assert age >= 0, "Age cannot be negative"`
函数出口	后置条件检查	返回前验证返回的列表已排序
类状态	不变量验证	每次状态变更后调用 `validate!` 方法
API 边界	Schema 验证	处理前验证请求体符合schema
数据管道	阶段断言	ETL转换后断言行数符合预期

参考：references/contracts-assertions.md

5. The Broken Window Theory

5. 破窗理论

Core concept: One broken window -- a badly designed piece of code, a poor management decision, a hack that "we'll fix later" -- starts the rot. Once a system shows neglect, entropy accelerates and discipline collapses.

Why it works: Psychology. When code is clean and well-maintained, developers feel social pressure to keep it that way. When code is already messy, the threshold for adding more mess drops to zero. Quality is a team habit, not an individual heroic effort.

Key insights:

Don't leave broken windows (bad designs, wrong decisions, poor code) unrepaired
If you can't fix it now, board it up: add a TODO with a ticket, disable the feature, replace with a stub
Be a catalyst for change: show people a working glimpse of the future (stone soup)
Watch for slow degradation (boiled frog) -- monitor tech debt metrics over time
The first hack is the most expensive because it gives permission for all subsequent hacks

Code applications:

Context	Pattern	Example
Legacy code	Board up windows	Wrap bad code in a clean interface before adding features
Code review	Zero-tolerance for new debt	Reject PRs that add `// TODO: fix later` without a ticket
Tech debt	Debt budget	Allocate 20% of each sprint to fixing broken windows
New team member	Clean onboarding path	First task: fix a broken window to learn the codebase
Monitoring	Entropy metrics	Track linting violations, test coverage trends over time

See: references/broken-windows.md

核心概念： 一扇破窗——一段设计糟糕的代码、一个错误的管理决策、一个「以后再修」的临时方案——会引发衰败。一旦系统显示出被忽视的迹象，熵增会加速，纪律会瓦解。

为何有效： 这源于心理学。当代码干净且维护良好时，开发者会有社会压力保持其整洁；当代码已经混乱时，添加更多混乱的门槛会降为零。质量是团队的习惯，而非个人的英雄主义努力。

关键见解：

不要放任破窗（糟糕的设计、错误的决策、劣质代码）不修复
如果现在无法修复，就先「封起来」：添加带工单的TODO、禁用功能、用存根替换
成为变革的催化剂：向人们展示未来的可行雏形（石头汤策略）
警惕缓慢退化（温水煮青蛙）——随时间监控技术债务指标
第一个临时方案代价最高，因为它为后续所有临时方案开了绿灯

代码应用场景：

场景	模式	示例
遗留代码	封装破窗	在添加功能之前，用干净的接口包裹糟糕的代码
代码评审	零容忍新增债务	拒绝添加无工单的 `// TODO: fix later` 的PR
技术债务	债务预算	每个 sprint 分配20%的时间用于修复破窗
新团队成员	整洁入职路径	第一个任务：修复一个破窗以熟悉代码库
监控	熵指标	随时间跟踪lint违规、测试覆盖率趋势

参考：references/broken-windows.md

6. Reversibility and Flexibility

6. 可逆转性与灵活性

Core concept: There are no final decisions. Build systems that make it easy to change your mind about databases, frameworks, vendors, architecture, and deployment targets. The cost of change should be proportional to the scope of change.

Why it works: Requirements change. Vendors get acquired. Technologies fall out of favor. If your architecture has hard-coded assumptions about any of these, every change becomes a rewrite. Flexible architecture treats decisions as configuration, not structure.

Key insights:

Abstract third-party dependencies behind your own interfaces -- never let vendor APIs leak into business logic
Use the "forking road" test: could you switch from Postgres to DynamoDB in a week? If not, you're coupled
Metadata-driven systems (config files, feature flags) are more flexible than hard-coded logic
YAGNI applies to premature abstraction too -- don't build flexibility you don't need yet
Reversibility is not about predicting the future; it's about not painting yourself into a corner

Code applications:

Context	Pattern	Example
Database	Repository pattern	Business logic calls `repo.save(user)` , not `pg.query(...)`
External API	Adapter/wrapper	`PaymentGateway` interface wraps Stripe; swap to Braintree later
Feature flags	Runtime toggles	New checkout flow behind a flag, rollback in seconds
Architecture	Event-driven decoupling	Services communicate via events, not direct HTTP calls
Deployment	Container abstraction	Dockerized app runs on AWS, GCP, or bare metal unchanged

See: references/reversibility.md

核心概念： 没有最终的决策。构建易于变更的系统，支持更换数据库、框架、供应商、架构和部署目标。变更的成本应与变更的范围成正比。

为何有效： 需求会变化，供应商会被收购，技术会过时。如果你的架构对这些因素有硬编码假设，每次变更都会变成重写。灵活的架构将决策视为配置，而非结构。

关键见解：

用自己的接口抽象第三方依赖——绝不让供应商API渗透到业务逻辑中
用「岔路口测试」：你能在一周内从Postgres切换到DynamoDB吗？如果不能，说明存在耦合
元数据驱动的系统（配置文件、功能标志）比硬编码逻辑更灵活
YAGNI原则也适用于过早抽象——不要构建目前不需要的灵活性
可逆转性不是预测未来，而是不让自己陷入绝境

代码应用场景：

场景	模式	示例
数据库	仓库模式	业务逻辑调用 `repo.save(user)` ，而非 `pg.query(...)`
外部API	适配器/包装器	`PaymentGateway` 接口封装Stripe；后续可切换到Braintree
功能标志	运行时切换	新结账流程在标志后，可在几秒内回滚
架构	事件驱动解耦	服务通过事件通信，而非直接HTTP调用
部署	容器抽象	容器化应用可在AWS、GCP或裸金属上无修改运行

参考：references/reversibility.md

7. Estimation and Knowledge Portfolio

7. 估算与知识体系

Core concept: Learn to estimate reliably by understanding scope, building models, decomposing into components, and assigning ranges. Manage your learning like a financial portfolio: invest regularly, diversify, and rebalance.

Why it works: Estimation builds trust with stakeholders when done honestly ("1-3 weeks" is better than "2 weeks exactly"). A knowledge portfolio ensures you stay relevant as technologies shift -- the programmer who stops learning stops being effective.

Key insights:

Ask "what is this estimate for?" -- context determines precision (budget planning vs. sprint planning)
Use PERT: Optimistic + 4x Most Likely + Pessimistic, divided by 6
Break estimates into components and estimate each; the total is more accurate than a single guess
Keep an estimation log: compare estimates to actuals and calibrate
Knowledge portfolio rules: invest regularly (learn something every week), diversify (don't only learn your stack), manage risk (mix safe and speculative bets), buy low/sell high (learn emerging tech early)

Code applications:

Context	Pattern	Example
Sprint planning	Range estimates	"3-5 days" with confidence level, not a single number
New technology	Time-boxed spike	"I'll spend 2 days evaluating; then I can estimate properly"
Large project	Bottom-up decomposition	Break into tasks < 1 day, sum with buffer for integration
Learning	Weekly investment	1 hour/week on a new language, tool, or domain
Career growth	Portfolio diversification	Mix of depth (expertise) and breadth (adjacent skills)

See: references/estimation-portfolio.md

核心概念： 通过理解范围、构建模型、分解组件和分配范围区间，学会可靠估算。像管理金融投资组合一样管理你的学习：定期投资、分散布局、动态再平衡。

为何有效： 当估算诚实时（「1-3周」比「正好2周」更好），能与利益相关者建立信任。知识体系确保你在技术变革中保持竞争力——停止学习的程序员会失去效力。

关键见解：

问自己「这个估算用于什么场景？」——场景决定精度（预算规划 vs sprint规划）
使用PERT方法：（乐观值 + 4×最可能值 + 悲观值）÷6
将估算分解为组件并分别估算；总和比单一猜测更准确
保留估算日志：比较估算值与实际值并校准
知识体系规则：定期投资（每周学习新内容）、分散布局（不要只学习当前技术栈）、管理风险（混合安全和投机性学习）、低买高卖（尽早学习新兴技术）

代码应用场景：

场景	模式	示例
Sprint规划	范围估算	给出「3-5天」及置信度，而非单一数字
新技术	时间盒探索	「我会花2天评估；之后就能给出准确估算」
大型项目	自底向上分解	分解为小于1天的任务，总和加上集成缓冲时间
学习	每周投资	每周花1小时学习新语言、工具或领域
职业发展	投资组合多元化	混合深度（专业技能）和广度（相邻技能）

参考：references/estimation-portfolio.md

Common Mistakes

常见错误

Mistake	Why It Fails	Fix
DRY-ing similar-looking code that serves different purposes	Creates coupling between unrelated concepts; changes to one break the other	Only DRY knowledge, not coincidental code similarity
Skipping tracer bullets and building layer-by-layer	Integration issues surface late; no end-to-end feedback until the end	Build one thin vertical slice first
Ignoring broken windows "because we'll refactor later"	Entropy accelerates; later never comes; team morale drops	Fix immediately or board up with a tracked ticket
Estimates as single-point commitments	Creates false precision; erodes trust when missed	Always give ranges with confidence levels
Making everything "flexible" upfront	Over-engineering; YAGNI; abstraction without evidence of need	Add flexibility when you have concrete evidence you'll need it
Assertions in production removed "for performance"	Bugs that assertions would catch now silently corrupt data	Keep critical assertions; benchmark before removing any
Global state "for convenience"	Destroys orthogonality; every module coupled to everything	Use dependency injection and explicit parameters

错误	失败原因	修复方案
对服务于不同目的的相似代码应用DRY原则	会在不相关概念之间创建耦合；变更其中一个会破坏另一个	仅对知识应用DRY，而非巧合的代码相似性
跳过追踪代码，逐层构建	集成问题很晚才暴露；直到最后才得到端到端反馈	先构建一个垂直切片再扩展
忽视破窗「因为以后会重构」	熵增加速；「以后」永远不会到来；团队士气下降	立即修复或用跟踪工单封起来
估算作为单点承诺	造成虚假精度；未达标时会损害信任	始终给出带置信度的范围
提前让所有内容「灵活」	过度设计；违反YAGNI；无需求依据的抽象	当有明确证据需要时再添加灵活性
为了「性能」在生产环境移除断言	断言本可以捕获的bug现在会默默损坏数据	保留关键断言；在移除前先做基准测试
为了「方便」使用全局状态	破坏正交性；每个模块都与所有内容耦合	使用依赖注入和显式参数

Quick Diagnostic

快速诊断

Question	If No	Action
Can I change the database without touching business logic?	Orthogonality violation	Introduce repository/adapter pattern
Do I have an end-to-end slice working?	Missing tracer bullet	Build one vertical slice before expanding
Is every business rule defined in exactly one place?	DRY violation	Identify the authoritative source and remove duplicates
Would a new developer call this codebase "clean"?	Broken windows present	Schedule a dedicated cleanup sprint
Do my estimates include ranges and confidence levels?	Estimation problem	Switch to PERT or range-based estimates
Can I roll back this deployment in under 5 minutes?	Reversibility gap	Add feature flags and blue-green deploys
Am I learning something new every week?	Knowledge portfolio stagnant	Schedule weekly learning time and track it

问题	如果答案为否	行动
我可以在不修改业务逻辑的情况下更换数据库吗？	违反正交性	引入仓库/适配器模式
我有一个可用的端到端切片吗？	缺少追踪代码	在扩展之前构建一个垂直切片
每个业务规则都只在一个地方定义吗？	违反DRY原则	确定权威源并移除重复
新开发者会认为这个代码库「干净」吗？	存在破窗	安排专门的清理sprint
我的估算包含范围和置信度吗？	估算问题	切换到PERT或基于范围的估算
我能在5分钟内回滚这个部署吗？	可逆转性不足	添加功能标志和蓝绿部署
我每周都在学习新东西吗？	知识体系停滞	安排每周学习时间并跟踪

Reference Files

参考文件

references/dry-orthogonality.md -- DRY knowledge vs. code duplication, four types of duplication, orthogonality in design and testing
references/tracer-bullets.md -- Tracer bullet vs. prototype development, building walking skeletons, iterating on tracer code
references/contracts-assertions.md -- Design by Contract, preconditions/postconditions/invariants, assertive programming patterns
references/broken-windows.md -- Software entropy, broken window theory, stone soup strategy, fighting degradation
references/reversibility.md -- Flexible architecture, decoupling strategies, avoiding vendor lock-in, forking road decisions
references/estimation-portfolio.md -- PERT estimation, decomposition techniques, knowledge portfolio management

references/dry-orthogonality.md -- DRY知识vs代码重复、四种重复类型、设计与测试中的正交性
references/tracer-bullets.md -- 追踪代码vs原型开发、构建行走骨架、迭代追踪代码
references/contracts-assertions.md -- 契约式设计、前置条件/后置条件/不变量、断言式编程模式
references/broken-windows.md -- 软件熵、破窗理论、石头汤策略、对抗退化
references/reversibility.md -- 灵活架构、解耦策略、避免供应商锁定、岔路口决策
references/estimation-portfolio.md -- PERT估算、分解技巧、知识体系管理

About the Authors

关于作者

Andrew Hunt is a programmer, author, and publisher. He co-founded the Pragmatic Bookshelf and was one of the 17 original authors of the Agile Manifesto. His work focuses on the human side of software development -- how teams learn, communicate, and maintain quality over time.

David Thomas is a programmer and author who co-founded the Pragmatic Bookshelf. He coined the term "DRY" (Don't Repeat Yourself) and "Code Kata." A pioneer in Ruby adoption outside Japan, he co-authored "Programming Ruby" (the Pickaxe book) and has spent decades advocating for developer pragmatism over dogma.

Andrew Hunt 是程序员、作家和出版商。他共同创立了Pragmatic Bookshelf，是敏捷宣言的17位原始作者之一。他的研究聚焦于软件开发的人文层面——团队如何学习、沟通并长期保持质量。

David Thomas 是程序员和作家，共同创立了Pragmatic Bookshelf。他提出了「DRY（Don't Repeat Yourself）」和「Code Kata」的概念。他是日本以外Ruby推广的先驱，合著了《Programming Ruby》（Pickaxe书），数十年来一直倡导开发者务实而非教条。

pragmatic-programmer

Original

Translation

The Pragmatic Programmer Framework

《程序员修炼之道》框架

Core Principle

核心原则

Scoring

评分标准

The Pragmatic Programmer Framework

《程序员修炼之道》框架

1. DRY (Don't Repeat Yourself)

1. DRY（Don't Repeat Yourself，不要重复自己）

2. Orthogonality

2. 正交性

3. Tracer Bullets and Prototypes

3. 追踪代码与原型

4. Design by Contract and Assertive Programming

4. 契约式设计与断言式编程

5. The Broken Window Theory

5. 破窗理论

6. Reversibility and Flexibility

6. 可逆转性与灵活性

7. Estimation and Knowledge Portfolio

7. 估算与知识体系

Common Mistakes

常见错误

Quick Diagnostic

快速诊断

Reference Files

参考文件

Further Reading

延伸阅读

About the Authors

关于作者