Effective Software Development-common mistakes

Last Saturday, the company conducted a technical training. The training content was nothing more than some common refactoring and agile development ideas. At that time, I didn't listen to some things, however, after hearing from my colleagues about the training content, I also looked at the general handouts of the training. In fact, I simply summarized the restructuring and other typical books and talked about some common sense, principle.

So here, I am not opposed to his point of view. Of course, I have no such right to oppose it, but language is the most likely to cause misunderstanding, I just corrected the misunderstanding that the same sentence has brought to people.

1.CodeRelationship with annotations

In terms of training, it should be said that good code does not need to be commented out.

Here I will talk about my comments. Note generation has three purposes:

A. the opponent's legal name cannot be compromised too long.

B. compromise on the reader's English Ability

C. Marking complex business logic

In general, for readability and rules, we will not write the method name into a complete sentence, so we can only replace it with some simple words, if a method is a relatively complex business logic method, your method name cannot fully and accurately express the meaning of the entire method, then you can only rely on annotations. So I said, the comment first is that the other party's legal name cannot be too long to compromise.

ProgramPersonnel levels are uneven, especially in English. Some people pass GRE, and some may just be able to understand junior high school words, so to improve work efficiency, to meet the needs of most enterprises, to take care of the current situation in China, every programmer cannot go to Google for unfamiliar words. Therefore, annotations are a compromise on the reader's English ability.

The third should be the biggest use of comments. No matter how detailed the responsibilities of a method are, it is impossible to avoid complicated business logic such as for, while, and recursion in a method.AlgorithmWhen the code needs to be maintained, it may be a waste of time to understand this business logic. Therefore, the simplest way is to add comments.

I have talked about the existence value of many annotations. Do annotations exist? Are I challenging this famous software theory? No.

There should be less comments. Do not write unnecessary comments.When you add comments to each line of your method, it means that your method itself fails.

This requires us to do the following:

A. method and class name. See the name and meaning.

B. Do not use meaningless variable names, Which is the simplest and most frequently written code.

For (INT I = 0; I <arr. length; I ++); I is a meaningless variable name. If we change I to loop, is it more significant. (Note: As we are all talking about this sentence, let me change it. In fact, I just want to express myself not to use meaningless variable names. The example is inappropriate, you can ignore it. I just want to explain some abnormal XXX, YYY, gddb and other variable names in the program.) 

C. Eliminate junk code in the bud. Spam code is bound to lead to logic that is confusing. It is very likely that a logical variable is introduced here, where an auxiliary parameter is introduced. How can this code be uncommented.

In conclusion, there is a need for comments. Remember to say that a perfect life does not need to be explained, and a perfect code does not need to be commented out. This is a little too powerful. A perfect code without comments can only show that the business logic of this project is too simple.

2. What is good software design?

A perfect design cannot be increased, but reduced. This is the most appropriate sentence for defining excessive design. In my opinion, add the following sentence: "and cannot be modified ". This is the most appropriate, otherwise it will be stuck in the illusion of no design.The complete sentence is: "A perfect design cannot be increased, but reduced. It cannot be expanded, but cannot be modified ."

As more and more people talk about design patterns (I am talking about design patterns, not the 23 Design Patterns of gof), it is useless and I feel especially helpless. It may be the transformation from ASP to Asp.net, and many people are used to stacking up many database operations in one method. Every time you modify a bug, you need to find the button first, read the method from the beginning to the end, and check which sentence has a problem.

For a small system, this is understandable, and the code logic is simple. A programmer can make such a complete system, at most for a long time. But is this really a method for developing a software?

First, we have two principles:OCP and dry (don't repeat yourself ).If you even deny these two principles, Well, you suspect that the entire software history, even all the software masters in history cannot convince you, And I will naturally be powerless.

The simplest dry ensures the necessity of your encapsulation, while the OCP ensures the importance of your design and subcontracting.

Many people are afraid of encapsulation. They always want you to write everything on the page. All logic is the simplest SQL statement, which means that the encapsulated content cannot be understood, SQL is the easiest to understand. Well, let me simply describe the encapsulation.

Encapsulation has two advantages:

A.You can reuse encapsulated methods in the outside world without worrying about internal business logic, which is convenient for users.Separation of duties is not only reflected in software design, but also in software engineering and project management. Wen Dao has successively specialized skills and few are both SQL experts and CSS experts. Similarly, few people are both technical experts and business experts. The division of the Three-layer architecture, one of the most important purposes is separation of duties. In this case, I encapsulate all the complicated business logic into BLL. Can I focus on the display of the interface at the user interface layer? What do you fear when the logic is wrong?

B.Encapsulation is secure.Encapsulation hides some methods that should not be made public to the outside, making them inaccessible and called, so as to prevent users from destroying the system (or data) due to misoperations ).

In other words, I encapsulate the method to make the called method simpler and shorter, so that the code looks clearer. In this case, do you still hate encapsulation?

Next we will talk about the subcontracting and design issues. Here we will talk about the OCP principle: open to expansion and close to modification. So how can we most easily understand this sentence? When we want to add requirements to the original system, we don't need to change the original code, instead of changing the DLL of the original code.With the development of the design model, the ultimate goal is to build a fully configurable software project.In this way, we can achieve our perfect OCP.

Do you really understand the layered architecture? -- This article is written to friends who are "poisoned" by petshop.ArticleIn the preceding section, xbishi pointed out that many of us have misunderstandings about the layer-3 architecture as BLL + Dal + website. In fact, when we build configurable software projects step by step, when we propose "component-oriented programming", or even when we propose "SOA", we should think of it,A software should be composed of countless components (. dll). In the configuration file, we can freely choose these components. Each. dll should be a separate change point.When we see in the design pattern that "each class should not exceed one reason for its change", we should think that for today's software, this idea should be changed to:"Each dll should not have more than one reason for its change".

In this case, do you still say that there are many. DLL files in a project that are terrible?

3. Summary

I just want to explain that every programmer can doubt the theory. But first, we need to understand the software theory and understand the essence of the theory.

Winter-CN said a word to me, which has a great impact on Me. "It is better to believe in books without books, but when you suspect that books have books ". Sometimes I only advise my friends, and believe that most programmers are still ordinary people. Most of us have not reached the level of foreign software masters. Why should we doubt the opinions of others for decades, the software theory has been wrong for decades. Is it useless?

When you say that RUP is useless, when you say that design patterns are useless, when you say that software engineering processes are useless, when you say that hierarchy is useless, when you say that a software theory is useless, when you say that a technology is useless, close your eyes and wait for a moment, am I better than him?

Can you compete alone with the entire software academic community?