How to get rid of the tangle of bad projects

Do you think that what you have done before, just finished, or is working on a project is nothing more than shit. you don't want to maintain it, you don't want to see the code you have written before? If so, we can proceed with the following content. To analyze the cause, why is the project Poor? from the perspective of pure technology, there are only two problems: poor project architecture and poor code quality.

Do you think that what you have done before, just finished, or is working on a project is nothing more than shit. you don't want to maintain it, you don't want to see the code you have written before? If so, we can proceed with the following content.

To analyze the cause, why is the project Poor? there are only two problems in pure technology:

• Poor Project Architecture
• Poor code quality

Let's break through each other and talk about some of my ignorance. The project architecture is often a good programmer in the project manager, architect, and team, or a programmer who stays in the company for a long time. due to the different understanding of the architecture, the way of doing things is different, and the project cycle is different, technology selection is different, so the architecture is also diverse, but in my opinion, the more distinctive, that is, the more conservative database first, and the more popular field-driven. There are obvious differences between the two. I think the latter has more advantages in architecture. The former has more advantages in the development cycle and does not require many preliminary designs, but its elegance is far lower than that of the latter, however, the former option is often selected for outsourcing companies or projects with a short budget.

The general process of database advanced architecture:

1. Requirement Analysis
2. Design Database
3. Write or use a tool to generate an object class (DTO)
4. Write logic

General process of domain model architecture:

1. Requirement Analysis
2. Analyze the business, organize domain objects, and divide the relationships between objects (extract the aggregation root)
3. Write behavior for domain objects

Both have one thing in common: AOP, object-oriented, and design patterns can be used to improve the maintainability of programs. However, the latter has a stronger object-oriented taste and has inherent advantages in architecture.

Problems brought by database first to the project

1. most people in the team prefer to write SQL because they rely on databases. writing SQL is not a bad thing, but too many SQL statements and even logic are processed by writing SQL statements, which will inevitably result in reduced maintainability. The reasons are as follows:

• SQL is inherently determined that SQL does not have the object-oriented concept, which means that it has a low abstraction level, and it is difficult to maintain the code of a stream program with high maintainability and closeness, many codes with the same logic need to be repeatedly written in different stored procedures. although they can be extracted into functions or other stored procedures, it is not easy.
• Since many logics are written to the data layer, such as time processing, data conversion, verification, and error processing, they all depend on the database to a large extent. Obviously, databases are not good at object-oriented languages. This almost minimizes the maintainability of the project.
• The lack or weakness of modern IDE's many encoding advantages, such as smart prompts and compilation error correction, greatly reduces testability and makes it even difficult for you to perform unit tests.

Of course, there are also advantages, that is, the ease of release and performance will be slightly higher.

2. a better way is to write the logic into the code. the database is only used to persist data. here there are two styles.

• Using ORM and SQL to generate the framework is common. the advantage is that mature ORM frameworks (such as EF and nhib.pdf) help us generate SQL, we do not need to write SQL statements in the code, such as low maintainability and risks of SQL injection. In addition, we can enjoy smart code prompts, compilation error correction, and other benefits.
• Writing a stored procedure is different from the previous one. this method only writes the CRUD operation into a stored procedure. in logic writing code, this method is conducive to publishing. The disadvantage is that you need to manually write entity classes and stored procedures, but we can use tools to generate them.

Advantages of database first

• The architecture is not complex and easy to understand and communicate with team members.
• Short development cycle and low cost

Speaking about the domain model, it is more like a way of thinking about problems. its appearance is to provide a practical guiding ideology for software development, which contains too many ideas, including software development principles, OO ideas, ideas for solving problems, how to easily test, AOP, etc. if you are interested, you can go to the system to learn it.

The above are architectural issues. if you have space and time, we suggest you consider the sequence as follows:

1. Domain-driven
2. Database-driven, using ORM and logic writing programs

Other methods should be used with caution.

Back to the beginning, let's talk about how to write elegant code. In fact, this is a cumulative process. The premise is that you are making progress, the progress is because you realize that the code you write is not elegant enough and intend to improve and take the results of learning and restructuring. So when you think the code is rotten, don't give up, don't break the jar, and refactor it. To refactor, you have to find the code to be restructured. The bad code that I can think of is:

1. too long method

This means that the method content is too long. in this case, it is often the result of poor encapsulation, and a business is often implemented in a method, in fact, this business is actually split into different objects, that is, this operation is not atomic enough. for example, if people need to drink cola, the business process should be like this: give a bottle of cola. people need to open the bottle and drink until they are not thirsty.

The pseudocode is as follows:

Public class Person {pubic void Drink (Bottle bottle) {if (bottle = null) bottle = new Bottle (); if (cola. capacity <= 0) throw new Exception ("No COLA"); if (! Bottle. isOpen) {this. leftHand (bottle); // The Left Hand hand to take the bottle this. rightHand (bottle. kou); // right-hand ring this. pull (); // Open} var needCapactity = xx + yy-zz; // while (cola. capacity <= needCapactity) {cola. capacity --; cola. refresh (); this. colaCapacity ++; this. refresh (); Thread. sleep (1000 );}}}

Of course, this piece of code is not long, just to illustrate the way, we can see that the problems here are: verification logic, get the capacity to drink, and write the open mode into it.

2. hard-coded strings and numbers

if(age>50)if(city.ToLower()=="shengzhen")

3. categories with different responsibilities

4. duplicate code

There are several ways to improve code reuse:

• Inheritance
• Tool methods
• Use delegation

The first two points are easy to understand. let's take a look at this point and give an example of a DataContext transaction.

using(var context = new DataContext()){     context .BeginTransaction();     try    {      context.User.GetUser();      context.User.add(new User{name="xian"});       context.User.add(new User{name="hong"});      context.Commit();   }  catch  {     context.Rollback();  } }

The above code is very common. do you need to write this code in every transaction place? in fact, we can use delegation to implement the code at this time.

public class DbInvoker{public void Transaction(Action
 
   aciton){using (var context = new DataContext()){context.BeginTransaction();try{aciton(context);context.Commit();}catch{context.Rollback();}}}}
 

In the future, the transaction will be called in this way.

DbInvoker.Transaction(context=>{      context.User.Add(new User{name="xian"});      context.User.Add(new User{name="hong"});});

Is it much easier?

5. inaccurate meaning naming

6. poor UI and logical isolation

I think this is the most typical one. for example, when using the MVC framework for WEB, js references are output in the frontend of the back-end network, or long js and client stuff.

I will not give an example at all. Finally, I would like to explain how to read excellent open-source projects. thank you for your reading.

This article is available at http://www.nowamagic.net/librarys/veda/detail/2305.