Programmers should know that simplicity is beauty

We often hear such a sentence: simple is beautiful, or a variety of variants of this sentence, and this sentence is not limited to the industry, not just in the software industry, in a variety of fields involving design art, many master tasks will tell us,Simple is beautiful.

Here, of course, I only want to talk about the content related to software development. In fact, the problem we want to solve is --How simple is it?

For uidesign-can be used directly without training

I still remember several books that I have read about interactive design. They all mentioned that the simplest and most beautiful interface design is that users can understand how to use it directly, I don't need long-term training. I think so, and try to implement this in my own system. I once remembered that I helped my friend write a simple inventory management system. There was no menu on the interface and there were only a few necessary buttons, using the ribbon style of Office 2007, several distinctive icons are carefully selected. When a friend used it, he told me that this item is much better than the financial software he used before. It still won't be used after two months of training, and there are too many useless fields, it does not need to be entered, but it looks awkward. I didn't specifically tell him how to use this thing at the time. I just said, it's very simple. Just look at it. I was satisfied with the effect I achieved. It would be useful if I looked at it, haha.

In fact, think about successful products, such as the recently sold iPod, iPhone, iPad, and a series of Apple products. Every design is super simple, with no complicated interfaces and operations, I don't need to say that this kind of beauty has been recognized by countless people.

Complex interfaces are really a test. The most complex interfaces we have ever seen appear in Japanese projects, and the most complex reports are also in Japanese projects, the training and study of the basic knowledge of the Japanese, as well as the patience and perseverance of the complex situations, are indeed worth learning. If I face such a complex interface all day long, I may have crashed. (For example, it is terrible to put more than 40 controls on a single interface, and to enter a form that needs to be rolled three screens)

I can only say that I am a lazy and don't like complicated things. I like to use simple methods to solve problems. I am also willing to choose simple methods to use various things.

In fact, for people in the design field, or Interaction designers, designing the simplest interface allows users to use it by hand as soon as possible, and all the usage habits are consistent with the traditional habits of users.Respect for customersIn addition, in the market, whether a product can be successful or not often plays a very important role in the quality of the interface design, because the easy-to-use interface will make people really feel the beauty of it, and win more users.

What we are talking about above is what the end user needs to face.ProgramWhat employees need to face all dayCodeWhat should I do? I thinkThe simplicity of the Code lies in that the code can be understood directly.

In our work, we will inevitably need to maintain others' code, and the code we write will often be reviewed and maintained by others, the beauty of code is very important.

I think it is essential to directly understand the code:

Brief-- Every method should be as short as possible. Some people advocate that each method should not exceed four rows. For now, I don't think that standard can be met, but what we can at least achieve is, each method only does one thing. The terrible code I have ever seen is that there are more than five layers of if nesting, and the processing code in each nesting cannot be displayed on a single screen, so I directly crashed, haha.

Accurate name-- This should be the best way to understand the code during maintenance. The self-explanatory code advocated in the industry is also like this. If the names of variables, methods, classes, and so on can accurately express their meaning, then reading the code is the same as reading the manual, naturally, all work becomes simple.

Proper comment-- In some cases, annotations are quite necessary. Even for self-explanatory code, it is sometimes necessary to describe them with annotations. After all, there are some business logic that cannot be explained in computer languages. Of course, the more comments, the better. Some projects require 30% comments, which is still worth discussing.

Finally, let's talk about it.About database design,I think this must also be implemented simply by the principle of beauty.,What we should achieve is: directly understanding.

Good database design is very important for system development and maintenance. Especially for some management software such as MIS, ERP, and MRP, database design plays an important role in the system architecture.

I want to grasp the following principles:

Not too many fields in the table-- The number of fields in each table should be controlled within 30. This standard may vary with projects, but it is just a basic concept. Imagine, when a data table has more than 100 fields defined in a project, does it feel difficult to process it? I have encountered this many times during my work. This large and full table is often a problem-prone location.

Reasonable name-- In some projects, some standby fields are often used for prevention purposes, or some fields that do not necessarily represent any meaning are put. Their names may be numbers with numbers in the delimiter, for example, A1 A2 A3 ...... This field is really a nightmare for maintainers. They may represent different meanings under different circumstances, so we not only need a database statement, you also need to specify the specification for each field in different situations. If we can avoid this situation, and each name clearly represents its own meaning, the difficulty will be greatly reduced.

In fact, the principles here are basically the same as the encoding principles. After all, I am still looking at this issue from the programmer's perspective.

In short, simplicity is beauty, beauty is beauty. Do you think so? :)