<h1 class="pgc-h-center-line" > written on the front</h1>
The whole content is still from the hacker-laws library on Github, thinking of sorting it out in a bang, the original title is "Laws, Theories, Principles and Patterns Useful to Developers", the English version has collected 56 items, and the Chinese version has been translated by Steve Xu (less than 2, this article has many citations, thank you here).
In fact, relevant articles can be searched for on the Internet, but there are some problems, first of all, there are only a few parts of the content, and secondly, there is a lack of further collation and analysis, I hope this article can make up for this piece.
<h1 class= "pgc-h-center-line" > technical regularity class</h1>
Moore's Law
The number of transistors in integrated circuits doubles approximately every two years.
Until the late 21st century, the predictions of Moore's Law proved to be very accurate. Later, this trend changed slightly as component miniaturization encountered physical limitations. In recent years, with the development of parallelism, and the potentially revolutionary changes in semiconductor technology and quantum computing, this law is likely to continue to hold true for decades to come.
The Hype Cycle or Amara's Law
We tend to overestimate the impact of technology in the short term and underestimate the long-term effects.
The law is an overview of the curve of technology hype, describing people's attitudes toward a certain new technology at different stages.
Wadler's Law
In any language design, the total time spent discussing a feature in the following list is proportional to its location.
1. Semantics
2. Syntax
Lexical syntax
4. Lexical syntax of comments
For example, 1 hour on semantics is spent on annotation syntax.
This law mainly expresses that people spend more time on non-important matters.
The Pareto Principle or The 80/20 Rule
Most things in life are not evenly distributed.
The famous 80/20 rule, most of the results come from a few inputs, which can be used at least in areas such as quality management.
The Shirky Principle
Agencies will strive to preserve the problems to which they have a solution.
Sherkey's principle suggests that institutions with solutions to complex problems may intentionally or unintentionally perpetuate problems.
Murphy's Law (Sod's Law)
Anything that could go wrong is bound to go wrong.
It can be used in many places such as code quality.
<h1 class="pgc-h-center-line" data-track="273" > team organization class</h1>
Conway's Law
This law illustrates that the technical boundaries of a system can reflect the structure of an organization, which is usually mentioned when improving the organization.
Conway's law states that if an organization is dispersed into many small, unrelated units, then the software it develops is also small and decentralized. If the organization is more around a function- or service-oriented vertical structure, then software systems reflect this as well.
[Breeze] The Spotify Model
The Spotify model is a method of team and organizational structure that has been popularized by Spotify. In this model, teams are organized around functionality rather than technology.
Note that the model is a dynamic process, not a fixed one.
The Two Pizza Rule
If you can't feed a team with two pizzas, then it's too big.
The rule, which originated from Amazon, suggests that no matter how big the company is, the team should be small enough to eat two pizzas (about 6-10 people). The reason behind this is that larger teams are less efficient due to exponential increases in communication costs.
Wheaton's Law
Don't act like a fool.
This quote was made in Will · Wheaton (who starred in Star Trek: The Next Generation, The Big Bang Theory) became popular after a speech on sportsmanship (probably due to individual words, pure fun), advocating not to be a person who does not care about the feelings of others, but to be kind to others, this simple and powerful law aims to create a harmonious and respectful environment within professional organizations. It can come in handy when talking to colleagues, reviewing code, refuting opinions, and criticizing. And often, professional interactions between people also apply.
The Dead Sea Effect
"... It engineers who are more talented and efficient are most likely to leave – disappear ... The "rest" who stay —the least talented and efficient IT engineers. "
The Dead Sea effect shows that in any organization, the skills, talent, and effectiveness of engineers tend to be inversely proportional to the time they spend in the company.
Putt's Law
Technology is dominated by two types of people, one is a proficient but not managed person (purely technical person) and the other is a person who manages but is not proficient (pure manager).
The law describes a technocratic phenomenon in some organizations in which over time people with strong technical abilities continue to be responsible for actual technology, while those who do not understand technology move towards technical management positions.
The Dilbert Principle
Companies tend to systematically promote employees with poor work ability to management to get them out of the workflow.
[Breeze] The Peter Principle
In hierarchies, people tend to be elevated to their "incompetent level."
Parkinson's The Law of Triviality
Groups spend more time and attention on trivial or superficial issues than on serious and substantive issues.
Without a lot of expertise or preparation, it is difficult to provide valuable input to very large and complex topic discussions. However, one would like to see more comments. As a result, they tend to spend a lot of time focusing on small details that are easy to scrutinize, but not necessarily valued.
Goodhart's Law
When pressure is applied to it for control, any observed statistical constancy tends to dissipate.
--Charles Goodhart
When a measure becomes a goal in itself, it is no longer a good measure.
Marilyn Strathern
It has been used to critique the number of lines of code and the number of comments as performance appraisals.
<h1 class="pgc-h-center-line" data-track="285" > product design category</h1>
[Breeze] 90-9-1 Rule (90–9–1 Principle or 1% Rule)
The 90-9-1 rule shows that in an Internet community such as a wiki, 90% of users only read content and do not participate in interaction, 9% of users participate in discussions, and only 1% of users create content.
Dunbar's Number
Dunbar numbers are the cognitive limits of the number of people who can maintain stable social relationships. In this relationship, one knows who each person is and how each person relates to other people. There are some disagreements about the exact value of this figure. Dunbar points out that one can easily maintain only 150 stable relationships. Such relationships are in a more social context, where you don't get embarrassed to join these people when you happen to run into them in a bar. Dunbar numbers are generally estimated between 100 and 250.
Like a stable relationship between people, the relationship between developers and the code base needs to be maintained. When faced with large, complex projects, or ownership of many projects, we rely on conventions, strategies, and modeling processes to scale. Dunbar numbers are important not only in the process of office size expansion, but also in setting the scope of a team's work, or deciding when the system should focus on tools that assist modeling and automate organizational overhead. Put Dunbar numbers into project content for an analogy, which is the number of projects you can join and have the confidence to rotate on call (or the normalized complexity of individual projects).
Fitts' Law
The time required to move to the target area is a function of dividing the distance to the target by the target width.
Fitz's Law dictates that when designing a UX or UI, the interaction elements should be as large as possible, and the distance between the user's attention area and the interaction elements should be as small as possible. This can have an impact on the design, such as grouping similar tasks.
It also formalizes the concept of "Magic Corners," where key UI elements are placed in corners so that users can easily click on them by moving the mouse. Windows' start button is located at the magic corner for easy selection, and interestingly, MacOS is just the opposite, its "close window" button is not at the magic corner, which can effectively reduce the probability of being clicked by mistake.
Hick's Law or Hick-Hyman Law
Decision times and the number of options available grow logarithmically.
Metcalfe's Law
In network theory, the value of a system is approximately equal to the square of the number of users of the system.
Reed's Law
The utility of large networks, especially social networks, expands exponentially with the size of the network.
This law is based on graph theory, where utility is proportional to the number of possible subgroups, and this growth rate is faster than the number of participants and the number of possible pairs of connections. Odlyzko and others argue that Reed's laws exaggerate the value of the system itself because they don't take into account the limitations of human cognition in network effects.
<h1 class="pgc-h-center-line" data-track="293" > project management class</h1>
Brooks's Law
Later in software development, adding manpower will only make the project develop more slowly.
This law states that in many cases, trying to accelerate the delivery of deferred projects by increasing manpower will result in project delivery later. Brooks also understands that this is an oversimplification. But the general argument is that the increased time and communication overhead of new resources will slow down development in the short term. Moreover, many tasks are inextricably linked, in other words, this allows more resources to be easily distributed among themselves, which also means that the potential growth rate is also lower.
[Breeze] Hofstadter's Law
Even considering Hosta's Law, it's always longer than you might expect.
The paradox of duration estimation
Parkinson's Theorem (Parkinson's Law)
The workload increases during the time frame within which the work can be completed until all available time is filled.
<h1 class="pgc-h-center-line" > system design class</h1>
Amdahl's Law
Amdahl's law is a formula that shows the potential acceleration capabilities of computational tasks. This capability can be achieved by increasing system resources, often used in parallel computing. It can predict the actual benefits of increasing the number of processors, however increasing the number of processors is limited by program parallelism.
Parallelism is also limited.
[Breeze] CAP 定理 (CAP Theorem or Brewer's Theorem)
The CAP justification, as defined by Eric Brewer, states that for distributed data storage, it is not possible to meet the following three points at the same time:
1. Consistency: When reading data, each request will receive the latest data or return an error.
2. Availability: When reading data, each request will receive a non-error response, but there is no guarantee that the data is the latest data.
3. Partition Tolerance: When any number of network requests between nodes fail, the system can continue to run as expected.
The Dunning-Kruger Effect
Incompetent people often don't realize their own incompetence. The skills you need to come up with the right answers are the skills you need to recognize what the right answers are.
As their understanding and experience of a particular field grows, people are likely to experience another effect—illusory superiority, in which experience in a particular field makes it easier for them to overestimate the abilities of others, or to underestimate their own abilities. Taken together, these effects are all blamed on cognitive biases. When we are aware that deviations exist, we can try to make an opinion to eliminate these deviations, which often avoids objections.
Gall's Law
A practical complex system is bound to develop from a practical and simple system. A complex system designed from scratch is simply not feasible, and it is impossible to tinker to make it feasible. You have to start over with a simple system that works realistically.
Occam's Razor
Do not add entities if not necessary.
Occam Razor points out that of several possible solutions, the most likely one is the one with the fewest concepts and assumptions. Because this solution is the simplest, it only solves the problem, and does not introduce additional complexity and possible negative consequences.
The Law of Leaky Abstractions
In a way, all non-trivial abstractions are leaky.
Articles describing this law suggest that over-reliance on abstraction, coupled with a lack of understanding of the underlying processes, actually complicates the problem in some cases.
All Models Are Wrong or George Box's Law
All the models are wrong, but some are useful.
This principle suggests that all system models are flawed, but as long as they don't have too many flaws, it can be useful. This principle has its roots in statistics, but also applies to scientific and computational models.
A basic requirement for most software is to model a particular system. Whether it's a computer network, repository, social relationship diagram, or any other type of system, designers must model it with the appropriate level of detail. Too much detail can lead to too much complexity, and too little detail can make the model not work properly.
The Law of Demeter
Don't talk to strangers.
Demeter's law, also known as the least knowledge principle, is a software design principle related to object-oriented languages.
The law states that a unit of software should only talk to its direct collaborators. For example, if object A references object B and object B references object C, A can directly call B's methods, but should not directly call C's methods. So if C has a dothing() method, A should not call it directly, but use B.getC().doThis().
Following this law limits the scope of code changes, making them easier to maintain and safer later.
[Breeze] The Unix Philosophy
The Unix philosophy states that software components should be small and focused on doing one specific thing. Combining small, simple, and well-defined units, rather than using large, complex, multi-purpose programs, makes it easier to build systems.
[Breeze] SOLID
This is an abbreviation that refers to:
The Single Responsibility Principle
Each module or class should have only one function.
O: The Open/Closed Principle
Entities should open extensions and turn off modifications.
L: The Liskov Substitution Principle
You can replace types with subtypes without breaking the system.
I: The Interface Segregation Principle
You should not force any client to rely on methods that it does not use.
D: The Dependency Inversion Principle
High-level modules should not rely on low-level implementations.
[Breeze] The KISS Principle
Keep it simple and straightforward.
The KISS principle states that if most systems can remain simple rather than complex, then they can work optimally. Therefore, simplicity should be a key indicator at design time, while also avoiding unnecessary complexity. The phrase originally came from the 1960 U.S. Navy aircraft engineer Kelly Thompson. Kelly Johnson.
[Breeze] Don't repeat Your Own Principle (The DRY Principle)
In the system, each piece of knowledge must be single, clear and authoritative.
DRY is an abbreviation for Do not Repeat Yourself. This principle is designed to help developers reduce the repetitiveness of code and keep public code in one place. Originally cited by Andrew Hunt and Dave Thomas in the 1999 book The Programmer's Way of Cultivation.
<h1 class="pgc-h-center-line" data-track="311" > product quality class</h1>
The Broken Windows Theory
In the broken window theory, it is believed that some visible signs of crime (or lack of environmental awareness) can lead to further, more serious crime (or further deterioration of the environment).
Broken window theory has been applied to software development, suggesting that inferior code (or Technical Debt) may affect the efficiency of subsequent optimizations, further degrading the code; over time, this effect will lead to a significant decline in code quality.
Hanlon's Razor
What can be interpreted as stupid, should not be interpreted as malicious.
The consequences are usually the result of underconsideration, not malice.
The Law of Conservation of Complexity or Tesler's Law
This law indicates that there is a certain degree of complexity in the system and cannot be reduced.
Some of the complexity in the system is unintentional. This is due to poor structure, errors, or poor modeling. This unintentional complexity can be reduced or eliminated. However, some complexities are inherent due to the complexity inherent in the problem to be solved. This complexity can be transferred, but not eliminated.
One of the interesting things about this law is that even if the entire system is simplified, the inherent complexity will not be reduced. It will move to the user, and the user will have to act in a more complex way.
Hutber's Law
To improve is to deteriorate.
这个定律说明了对一个系统的改进会导致其他部分的恶化；或者它会将其他的恶化隐藏起来，并导致系统整体状态的退化。
Premature Optimization Effect
Premature optimization is the root of all evil.
In his paper On Structured Programming of Goto Statements, Gartner writes: "Programmers waste a lot of time thinking about or worrying about the speed of non-critical parts of their programs. When considering commissioning and maintenance, these so-called efficiency practices are actually quite inappropriate. We should let go of small efficiency points and remind ourselves 97% of the time that premature optimization is the root of all evil. And even that crucial 3 percent can't be spared. ”
However, premature optimization (in short) can be defined as optimizing before we know what we need to do.
Chesterson's Fence
Improvements should not be made until we understand the reasons behind the existing situation.
This principle is related to the elimination of technical debt in software engineering. Every line of the program was originally written for some reason, so according to the Chesterson fence principle, before changing or deleting the code, even if it seems superfluous or incorrect, you should try to fully understand the context and meaning of the code.
Linus's Law
Enough eyes to allow all problems to surface.
Code reviews, case reviews... Wait a minute
<h1 class="pgc-h-center-line" > code development class</h1>
The Scout Rule
Always make the code better than when you start seeing it.
Refactor in a timely manner.
Cunningham's Law
The best way to get the right answer on the web is not to ask a question, but to post an incorrect answer.
Hyrum's Law or The Law of Implicit Interfaces
When the API has enough users, your commitments in the contract are no longer important: all the observable behavior of your system will be relied upon by some people.
Pay attention to the rigor of interface definition to avoid being kidnapped.
Kernighan's Law
Debugging is twice as difficult as writing a program in the first place. So, by definition, if your code is very cleverly written, then you don't have enough ability to debug it.
Simple code is easy to debug.
[Breeze] You Don't Need It Principle (YAGNI)
Implement certain things only when you need them, not when you foresee them.
Avoid over-designing and over-designing.
The Robustness Principle or Postel's Law
Be conservative in what you do, and be free in accepting other people's things.
Typically applied in server application development, this principle states that the content you send to others should be as small and compliant as possible, and handle non-compliant input.
The goal of this principle is to build robust systems. If the intent can be understood, they can handle bad input. However, accepting incorrectly formatted input can be a safety hazard, especially if such input is not adequately tested.
The Fallacies of Distributed Computing
Also known as the fallacy of network computing, this is a series of conjectures (or perceptions) about distributed computing that can cause failure in software development. These assumptions are:
1. Reliable network
2. The delay is zero
3. Unlimited bandwidth
4. Network security
5. The topology is constant
6. Single administrator
7. The transportation cost is zero
8. The network is isomorphic
When designing resilient code, you should carefully consider these fallacies and assume that any one of them may cause logical flaws in dealing with the complexity and realism of distributed systems.
Many bugs are caused by not being aware of these problems.
<h1 class="pgc-h-center-line" data-track="328" > written at the end</h1>
Well, these are all the contents, with the picture scrawled, please do not have to be too entangled, some items of classification may not be appropriate, some items may be suitable for many scenes, some are more obscure, some may be more extreme, anyway, hope to bring us some enlightenment and vigilance just fine, thanks for reading !!!