When it comes to development, people talk about laws. But for most of us, there’s always something you don’t know, and that’s a problem that needs to be solved using a programmer’s favorite method: a recent GitHub “Laws Collection” project, which summarizes some of the most common laws, recently shot to number two on the trend list with a Star number in the thousands. See below.

GitHub by Dave Kerr, Heart of the Machine.

We are all experienced programmers, do not always repeat the “true fragrance law”.

  • Project link: github.com/dwmkerr/hac…

This article contains explanations of some laws, principles, and patterns, but does not claim any of them. Whether or not to apply which law is always a matter of debate, and largely depends on what you’re doing.

The list of rules is as follows:

The laws of

  • Amdar’s law

  • Brooks’ rule

  • Conway’s law

  • Hofstadter’s law

  • Hype cycle & Amara’s Law

  • Hiram’s rule

  • Moore’s law

  • Parkinson’s law

  • Putt’s Law

  • Conservation law of complexity (Tessler’s Law)

  • Abstract loophole law

  • Parkinson’s law of triviality

  • The Unix philosophy

  • The Spotify Model

  • Wadler’s Law

The principle of

  • Conservatism principle

  • SOLID

  • Single function principle

  • The open closed principle

  • Richter’s substitution principle

  • Interface Isolation Principle

  • Dependency inversion principle

With so many laws and principles above, we have compiled some of them and all of them. Now, let’s take a quick look at the law

The laws of

Amdar’s law

Wikipedia: The rule of thumb in computer science, named after Gene Amdahl. It represents the ability of the processor to increase its efficiency by performing parallel operations. Amdar’s law is the quantitative standard for a fixed load (when the total amount of calculation is constant).

For example, if A program consists of two parts (A and B), where A must be executed by A single processor and B can be executed in parallel, the benefit of adding more processors to the system on which the program is executed is limited. It may increase B’s speed A lot, but A’s speed will remain the same. As follows:

As can be seen from the figure, if only 50% of a program can be processed in parallel, the processing speed will not improve greatly when it uses more than 10 processing units. A program with 95% parallelism, even if more than 1000 processing units are used, is significantly faster.

Hofstadter’s law

Wikipedia: Things always take longer than you expect, even if you factor in Hofstadter’s law.

This law may come to mind when you estimate how long it will take to do something. One of the truisms of software development is that it is often difficult to estimate the exact time it will take to deliver something.

Hype cycle & Amara’s Law

Wikipedia: We tend to overestimate the short-term benefits of a technology and underestimate its long-term effects.

This law has been described as a statement that encourages people to think about the long-term impact of technology. Amara’s Law has also been described as the best illustration of the “hype cycle” (technology maturity curve). As shown below:

In short, this cycle shows that new technologies and their potential impact usually generate a flurry of excitement. Then many teams jump into the technology quickly, and are sometimes disappointed with the results. This may be because the technology is not mature enough, or because real-world applications are not yet fully realized.

Over time, the capabilities of the technology increase, so do the actual opportunities to use it, and the teams involved eventually start to benefit.

Hiram’s rule

Network definition: When an API has enough users, it doesn’t matter what you promise in the contract that all observed behavior in your system will be directly dependent on some users.

Hiram’s law states that when you have a very large number of users in your API, all the behavior in your API will eventually be dependent on someone. A simple example: non-functional elements, such as the response time of an API. A slightly more complex example: rely on users who apply regular expressions to error messages to determine the type of API error.

Moore’s law

The law states that the number of transistors in an integrated circuit doubles roughly every two years.

This law is usually used to describe the absolute speed at which semiconductor and chip technology develops. From the 1970s through the late 1990s, Moore’s predictions were remarkably accurate. But that trend has changed slightly in recent years, partly because of physical limits on how small components can be. However, the development of parallelism and potentially revolutionary changes in semiconductor technology and quantum computing could mean that Moore’s Law will still hold true for decades to come.

Conservation law of complexity (Tessler’s Law)

The law states that within every system there is a certain amount of complexity that cannot be reduced.

Some of the complexity in the system is “unintended.” It may be the result of poor structure, error, or simply poor modeling. These unintended complexities can be reduced (or eliminated). But some complexity is “inherent,” caused by the inherent complexity of the problems to be solved. That complexity can be moved, but not eliminated.

The interesting thing about this law is that simplifying the whole system doesn’t reduce the inherent complexity. This approach simply shifts complexity to the user, who must then act in a more complex way.

Parkinson’s law of triviality

The law states that large organizations spend a lot of time and energy discussing trivial things that don’t really matter, but really important decisions can be easily passed.

This is because, in the discussion of very professional and large amount of money, the average person due to lack of professional knowledge, dare not speak freely, so as not to make a slip of the tongue, so that most people will affirm (or avoid) the major plan, and mention some irrelevant trifles. On the other hand, there are so many opinions about simple trivialities, which Parkinson calls the law of triviality.

The Unix philosophy

The Unix philosophy says that software components should be small and focused on specific events. Grouping small, simple, well-defined units together, rather than using large, complex, multipurpose programs, makes it easier to build systems.

Modern practices like “microservices Architecture” apply this philosophy. In this architecture, services are small and do one thing centrally, allowing complex behavior to be made up of simple artifacts.

Wadler’s law

The law states that the total time spent discussing a feature in this list is proportional to the power of its position in any language design.

1. The semantic

2. Grammar

3. Vocabulary grammar

4. Lexical grammar of annotations

In short, if you spend an hour talking about semantics, you’ll spend eight hours talking about annotation syntax.

Similar to Parkinson’s law of pettiness, Wadler’s Law states that when designing a language, the amount of time spent on language structures is disproportionate to the importance of those features.

The principle of

In this article, the author states that principles are guidelines for programmers to develop new applications. In the process of coding, we often encounter all kinds of difficulties, of course, there are also all kinds of conventional rules. For example, some of the simplest naming conventions default to underscores, small hump, or big hump. You need to know these rules to write good code.

Conservatism principle

The Robustness Principle is described in Wikipedia as “write code conservatively and accept information from other sources.”

This principle is usually applied to the development of server applications, and it states that as little content should be sent as possible. But if you can handle input that doesn’t meet your requirements, then your goal should want to allow a variety of inconsistencies.

The goal of this principle is to build a robust system where input should be handled in non-standard formats as long as the intent of the other side remains understandable. However, accepting malformed input has potential security implications, especially if the processing of such input has not been well tested.

SOLID

The principle is an acronym, namely:

  • S: The single function principle

  • O: Open close principle

  • L: Richter’s substitution principle

  • I: interface isolation principle

  • D: Dependency inversion principle

As shown above, SOLID refers to the five basic principles of object-oriented programming and object-oriented design. When applied together, these principles enable programmers to develop systems that are easier to maintain and extend. SOLID is often used in test-driven development and is an important part of the basic principles of agile development and adaptive software development. Let’s take a look at these five basic principles.

Single function principle

In wikipedia’s description, the Single responsibility principle states that each class should have a Single function, and that function should be fully encapsulated by that class. All of its services should be strictly parallel to the functionality (functionality parallel, meaning no dependencies).

This principle states that a module or class should only do one thing. This means that a single minor modification to a program feature should only need to be changed in one component. For example, changing the way passwords are validated should only require changing one module specific to the program.

An important reason for keeping a class focused on a single function point is that it makes the class more robust. If we know that the component we are modifying has only one function, testing becomes simpler and new changes are easier to handle. For example, changing password authentication should only affect features related to password authentication, which would be much more complicated if we were to make changes to a multifunctional module.

The open closed principle

In object-oriented programming, the open closed principle states that objects in software (classes, modules, functions, and so on) should be open for extension, but closed for modification of existing behavior. This means that an entity needs to be allowed to change its behavior without changing the source code.

This feature is particularly valuable in a Productization environment, where changing source code in productization requires code review, such as unit testing, to ensure the quality of product use. Code that follows this principle does not change when it is extended, so this process is not required.

For example, suppose a module can convert Markdown text to HTML. If a module can extend new features, that is, handle the newly proposed Markdown features without modifying the module interior, then it is open to extension.

This principle is particularly relevant to object-oriented programming, where we can design objects that are easy to extend, but also avoid designing objects that are unstable because their existing behavior can change in unexpected ways.

Richter’s substitution principle

The Liskov Substitution principle is a specific definition of subtypes. Richter’s substitution principle can be described as follows: derived (subclass) objects can replace their base (superclass) objects in a program. That is, if a module depends on a class, the module needs a derived class that can use that class without system error.

For example, if we had a way to read XML text from the structure of the representation file. If the method’s base class is “file”, it can call any class derived from “file”.

This principle is very important for object-oriented programming, and we must carefully model the hierarchy of classes to avoid confusing system users.

Interface Isolation Principle

Interface-segregation Principles state that a user (client) should not rely on methods it does not use. The interface isolation principle breaks down bloated interfaces into smaller and more specific interfaces, so that users will only need to know the methods they are interested in. These reduced interfaces are also known as role interfaces. The purpose of the interface isolation principle is to decouple systems so they can be easily refactored, changed, and redeployed.

For example, suppose we have a way to read an XML document from the structure that represents the file. This method simply reads the bytes and moves forward or backward in the file. This principle is invalid if the method needs to be updated (such as updating the permission model used to represent file security) because of a change in an unrelated feature of the file structure. The file is best implemented as a ‘seeking-stream’ interface and used by XML readers.

This principle has particular relevance to object-oriented programming, where interfaces, hierarchies, and abstract types are used to minimize coupling between different components. Duck typing enforces this principle by eliminating explicit interfaces.

Dependency inversion principle

In traditional application architectures, lower-level components are designed for higher-level components, which makes it possible to build a complex system step by step. In this structure, higher-level components directly depend on lower-level components to perform some tasks. This reliance on lower-level components limits the possibility of higher-level components being reused.

The purpose of the dependency inversion principle is to decouple high-level components from their dependencies on lower-level components, making it possible to reuse component implementations at different levels. This decoupling is also facilitated by separating high-level and low-level components into separate packages/libraries. Because low-level components are concrete implementations of high-level component interfaces, the compilation of low-level component packages is dependent on high-level components, reversing the traditional dependencies. Numerous design patterns, such as plug-ins, service locators, or dependency inversion, are used to provide specified low-level component implementations to high-level components at run time.

Specifically, the dependency inversion principle states that:

  • High-level modules should not depend on low-level modules; both should depend on abstract interfaces.

  • Abstract interfaces should not depend on concrete implementations. Concrete implementations should rely on abstract interfaces.

For example, if we have a program that reads metadata from a web site, and the main component contains a component that downloads web site content and a component that reads metadata. If we consider the dependency inversion principle, the main component can only depend on some abstract component, one of which can only fetch bits of data and another can only read metadata from the bit stream. The main component does not know anything about protocols or formats such as TCP/IP, HTTP, or HTML.

This principle is complicated because it seems to reverse system dependencies. In practice, this principle means that separate choreography modules must ensure that the correct abstract type implementation is used. For example, in the example above, the metadata reading module still requires some abstract types of implementations, namely HTTP file downloaders and HTML meta tag readers.