hacker-laws-zh
💻📖对开发人员有用的定律、理论、原则和模式。(Laws, Theories, Principles and Patterns that developers will find useful.)
A Chinese translation of hacker-laws, a curated reference of famous laws, principles, and patterns from software development like Brooks's Law, the CAP Theorem, and SOLID, each with plain explanations and links to Chinese Wikipedia.
hacker-laws-zh is a Chinese translation of the hacker-laws project, a curated reference of named laws, theories, principles, and patterns that come up frequently in software development discussions. The original English project was created by dwmkerr; this repository is a community-maintained translation into Simplified Chinese with added links to Chinese Wikipedia pages for each entry.
The collection covers a wide range of named concepts. Some describe how software projects behave in practice, such as Brooks'''s Law (adding engineers to a late project makes it later), the Broken Windows Theory (visible disorder invites more disorder, applied to code quality), and Hofstadter'''s Law (tasks always take longer than expected, even when you account for that). Others address computing systems directly, including Amdahl'''s Law (the limits of parallelization) and the CAP Theorem (distributed databases cannot simultaneously guarantee consistency, availability, and partition tolerance).
Many entries come from outside computing but apply to it: Dunbar'''s Number (a cognitive limit on social group sizes, relevant to team organization), the Pareto Principle (80% of effects from 20% of causes), Occam'''s Razor (prefer simpler explanations), and the Dunning-Kruger Effect (lower competence correlates with overconfidence). Engineering principles like SOLID, DRY, KISS, and YAGNI also have entries with plain explanations.
Each entry includes a brief explanation, a real-world example, and links to both English and Chinese Wikipedia pages for further reading. The repository carries a note that it presents these laws without endorsing any particular one, since their applicability depends on the specific situation.
This repository contains no code and is a reading reference only. The full README is longer than what was shown.
Where it fits
- Look up why adding engineers to a late project makes it later before your next team deadline discussion.
- Reference the CAP Theorem entry when evaluating trade-offs in a distributed database design.
- Use the SOLID, DRY, and KISS entries as a plain-language checklist during a code review.