Rigid thinking in software development and rigid thinking in software development

Rigid thinking in software development and rigid thinking in software development

In the J2EE field, SSH/SSI is a good thing and a result of the painstaking efforts of masters. But he is also a bad thing.

 

On the good side, I believe you don't have to say much about it. A large number of design patterns are used to greatly reduce the entry barrier for programmers, standardize enterprise application development, and improve production efficiency. Both enterprise costs and personal technological development are the essence.

 

Now let's discuss its bad side:

1. Lower the programmer's entry threshold

You only need a copy of "xx days to learn xx" to join the job and win the envy of other industries. But is that really good ?! We do not talk about the combination of algorithms and data structures. We are ordinary people without talking about high theories and technologies. From the perspective of urgent job needs, it is good that you can quickly learn a technology. However, when many ordinary people taste the sweetness of quick success, they feel that the technology is like this. When will I use it and then hold it off temporarily? So I don't want to be aggressive, so I am waiting for nothing. More and more enterprise application developers enter this status. Some people know that this is not correct, but they will not change as they see others.

2. Standardize enterprise application development

From the perspective of enterprise production, it is very good to form a standardized and streamlined production process based on what cannot be standardized. This can greatly reduce production costs and improve product quality. However, the by-products of the process are rigid!

As mentioned above, the entry threshold is lowered, and the personnel level is uneven. Some people understand this kind of specification as a standard and a reference object, while others understand that it is a provision and a criterion that must be observed. In addition, they do not know why, this type of rigidity is more serious.

3. A large number of design patterns

Some developers see that the framework is in this design mode, so everything is like a nail. This is not related to this topic, and we will not discuss it here.

 

Let's take a look at the specific example.

I believe many people will write jsp, action, service, and dao modules when developing SSH/SSI applications. So why do I need to write these modules to develop a function? Why can't I use other methods?

Some people say that this follows the MVC pattern and is a hierarchical business model, which facilitates development and maintenance and communicates with other developers.

 

Then, let's start with MVC to see why development is required.

V: View layer, which is the layer that interacts directly with users. It is the data presentation layer.

C: Controller scheduling layer, which refers to forwarding requests from the view layer to the service layer. The service layer is combined to schedule requests from the view layer and return data from the service layer to the view layer.

M: Model data Model refers to the Service layer + data layer, also known as Service + Dao, which is mainly used to implement business logic and return business data.

The above theory is believed that every J2EE developer has read the related introduction. We will not discuss the View layer much. No matter which View technology is used, it has a single purpose and is relatively easy to understand.

 

C and M.

The general practice is to create an Action, create a Service interface, create a Dao interface, create a ServiceImpl to implement the Service interface, and create a DaoImpl to implement the Dao interface.

Here we go back to the topic. Why do we need to create so many classes and interfaces like this?

Many junior developers do not care about the requirements of November 21 and superiors, so they write and do not understand the flexibility. Over time, they think that the web should be like this .....

Alternatively, obfuscation of C and M's responsibilities leads to confusion in business logic and a large amount of code redundancy.

 

So what is the correct approach?

 

1. Single responsibilities and focus

As small as a method, a class, a module, and a system, what it does should be single. It should only focus on one thing and one field.

Controller scheduler. Since it is called a scheduler, there should be no complicated business logic. Its responsibilities should be single. It is responsible for the combined arrangement of lower-layer service modules, implement data requests at the view layer.

The Service layer, known as the Service layer, should focus on services, implement all business logic, call and combine Dao layer query methods, and there should be no scheduling or direct DB requests.

Dao, Database access Object, Database access layer, focusing on Database access, should not have business logic.

Ii. Modularization

As mentioned above, Controller is responsible for scheduling. If I write all the services to a service method, action calls a method and does nothing else, is this scheduling useless? (The same is true for services. If there is no business logic, simply call the Dao method ).

The requirement is like a strange building. You have two options:

1. directly create a building in this shape to meet the needs. Next time, directly create a building.

2. Split the strange building into blocks in a regular shape and splice them together. The next time you continue to split the blocks, you will gradually get more and more rules in your hands, and your code will get better and better written. For every new requirement, you just need to use the existing blocks and add a bit of glue to stick them together. At this time, the real functions of the service can be reflected.

The building block here is a module. This module can be a method, a class, and a complete encapsulation function.

I believe it can be seen that this method is good, but why do most people use the first method to write code?

3. Big and simplified

After discussing the responsibilities and modules clearly, let's consider whether view/action/service/dao can be written in another way. When we are looking at them from a layered perspective, in fact, they are just a type of hierarchy. The upper layer depends on the lower layer, and the lower layer provides services for the upper layer. The Framework defines that we need to write data in N layers. Then I can define four layers and five layers by myself. As long as the business needs are met, this forms your own programming idea.

 

The above three steps need to be solid step by step. Of course, it must be relatively difficult at the beginning. It may be more difficult or slower than writing code. At this time, you need a quality: VIRGO (pursuit of perfection )! :)

 

We all know that there are a lot of tool frameworks in the java World. For Engineering Development, it is good to focus on the business without making wheels! But for developers themselves, it is easy to create rigid thinking, easy entry, poor foundation, and difficult to improve!

This should also be part of the reason why C programmers are easy to switch to java and java programmers are difficult to switch to C! After all, many old C programmers maintain their own tool libraries, which are coded by themselves. From the ground up, Bao Jianfeng often suffers from poor foundation in the external environment.

 

It is often said that laziness is an excellent quality for programmers, because computers themselves are the product of laziness. However, when laying a solid foundation, you must work hard, be stupid, and pursue the ultimate. If you want to think more about why, you can have a lazy capital.

 

Everything has two sides. It is too late. The mean is not mediocre!