软件工程定律
Laws of Software Engineering

原始链接: https://lawsofsoftwareengineering.com

## 软件工程定律:摘要 本资源汇集了56条“定律”——影响软件开发的原则和模式,涵盖架构到团队动态等领域。这些并非严格的规则,而是关于软件系统、团队和决策*倾向于*表现方式的观察。 关键概念包括**康威定律**(系统反映组织结构)、**布鲁克斯定律**(向延期项目增加人手会进一步延误)、和**海陆姆定律**(所有系统行为都会被依赖)。它强调了简单性的重要性(**KISS, DRY, YAGNI**)和持续改进(**童子军规则**)。 该集合还涉及常见的陷阱,如**过早优化**、**抽象**的局限性,以及**分布式系统**的现实(CAP定理)。它深入探讨团队动态,例如**邓巴数**,并承认**邓宁-克鲁格效应**和**确认偏误**等人类因素对决策的影响。最后,它涉及扩展挑战(**阿姆达尔定律**)和项目管理现实(**帕金森定律,霍夫斯塔德定律**)。 最终,“定律”为应对软件工程的复杂性提供了宝贵的见解。

相关文章

原文

Laws of Software Engineering

A collection of principles and patterns that shape software systems, teams, and decisions.

56 laws Click any card to learn more
Laws of Software Engineering Book Cover
Teams

Conway's Law

Organizations design systems that mirror their own communication structure.

Planning

Premature Optimization (Knuth's Optimization Principle)

Premature optimization is the root of all evil.

Architecture

Hyrum's Law

With a sufficient number of API users, all observable behaviors of your system will be depended on by somebody.

Quality

The Boy Scout Rule

Leave the code better than you found it.

Design

YAGNI (You Aren't Gonna Need It)

Don't add functionality until it is necessary.

Teams

Brooks's Law

Adding manpower to a late software project makes it later.

Architecture

Gall's Law

A complex system that works is invariably found to have evolved from a simple system that worked.

Architecture

The Law of Leaky Abstractions

All non-trivial abstractions, to some degree, are leaky.

Architecture

Tesler's Law (Conservation of Complexity)

Every application has an inherent amount of irreducible complexity that can only be shifted, not eliminated.

CAP
Architecture

CAP Theorem

A distributed system can guarantee only two of: consistency, availability, and partition tolerance.

Architecture

Second-System Effect

Small, successful systems tend to be followed by overengineered, bloated replacements.

Architecture

Fallacies of Distributed Computing

A set of eight false assumptions that new distributed system designers often make.

Architecture

Law of Unintended Consequences

Whenever you change a complex system, expect surprise.

+++++
Architecture

Zawinski's Law

Every program attempts to expand until it can read mail.

150
Teams

Dunbar's Number

There is a cognitive limit of about 150 stable relationships one person can maintain.

Teams

The Ringelmann Effect

Individual productivity decreases as group size increases.

N
Teams

Price's Law

The square root of the total number of participants does 50% of the work.

?
Teams

Putt's Law

Those who understand technology don't manage it, and those who manage it don't understand it.

Teams

Peter Principle

In a hierarchy, every employee tends to rise to their level of incompetence.

1
Teams

Bus Factor

The minimum number of team members whose loss would put the project in serious trouble.

?
Teams

Dilbert Principle

Companies tend to promote incompetent employees to management to limit the damage they can do.

Planning

Parkinson's Law

Work expands to fill the time available for its completion.

90%+90%
Planning

The Ninety-Ninety Rule

The first 90% of the code accounts for the first 90% of development time; the remaining 10% accounts for the other 90%.

+
Planning

Hofstadter's Law

It always takes longer than you expect, even when you take into account Hofstadter's Law.

Planning

Goodhart's Law

When a measure becomes a target, it ceases to be a good measure.

Planning

Gilb's Law

Anything you need to quantify can be measured in some way better than not measuring it.

Quality

Murphy's Law / Sod's Law

Anything that can go wrong will go wrong.

Quality

Postel's Law

Be conservative in what you do, be liberal in what you accept from others.

Quality

Broken Windows Theory

Don't leave broken windows (bad designs, wrong decisions, or poor code) unrepaired.

$%
Quality

Technical Debt

Technical Debt is everything that slows us down when developing software.

Quality

Linus's Law

Given enough eyeballs, all bugs are shallow.

Quality

Kernighan's Law

Debugging is twice as hard as writing the code in the first place.

Quality

Testing Pyramid

A project should have many fast unit tests, fewer integration tests, and only a small number of UI tests.

Quality

Pesticide Paradox

Repeatedly running the same tests becomes less effective over time.

Quality

Lehman's Laws of Software Evolution

Software that reflects the real world must evolve, and that evolution has predictable limits.

Quality

Sturgeon's Law

90% of everything is crap.

Scale

Amdahl's Law

The speedup from parallelization is limited by the fraction of work that cannot be parallelized.

Scale

Gustafson's Law

It is possible to achieve significant speedup in parallel processing by increasing the problem size.

Scale

Metcalfe's Law

The value of a network is proportional to the square of the number of users.

1
Design

DRY (Don't Repeat Yourself)

Every piece of knowledge must have a single, unambiguous, authoritative representation.

Design

KISS (Keep It Simple, Stupid)

Designs and systems should be as simple as possible.

Design

SOLID Principles

Five main guidelines that enhance software design, making code more maintainable and scalable.

ABC
Design

Law of Demeter

An object should only interact with its immediate friends, not strangers.

Design

Principle of Least Astonishment

Software and interfaces should behave in a way that least surprises users and other developers.

Decisions

Dunning-Kruger Effect

The less you know about something, the more confident you tend to be.

Decisions

Hanlon's Razor

Never attribute to malice that which is adequately explained by stupidity or carelessness.

Decisions

Occam's Razor

The simplest explanation is often the most accurate one.

Decisions

Sunk Cost Fallacy

Sticking with a choice because you've invested time or energy in it, even when walking away helps you.

MAPREAL
Decisions

The Map Is Not the Territory

Our representations of reality are not the same as reality itself.

Decisions

Confirmation Bias

A tendency to favor information that supports our existing beliefs or ideas.

Decisions

The Hype Cycle & Amara's Law

We tend to overestimate the effect of a technology in the short run and underestimate the impact in the long run.

+
Decisions

The Lindy Effect

The longer something has been in use, the more likely it is to continue being used.

?
Decisions

First Principles Thinking

Breaking a complex problem into its most basic blocks and then building up from there.

Decisions

Inversion

Solving a problem by considering the opposite outcome and working backward from it.

80%20%
Decisions

Pareto Principle (80/20 Rule)

80% of the problems result from 20% of the causes.

Decisions

Cunningham's Law

The best way to get the correct answer on the Internet is not to ask a question, it's to post the wrong answer.

联系我们 contact @ memedata.com