Shulou(Shulou.com)06/02 Report--

This article mainly introduces "what are the basic elements of excellent software design". In daily operation, I believe many people have doubts about what are the basic elements of excellent software design. Xiaobian consulted all kinds of materials and sorted out simple and easy operation methods. I hope to help you answer the doubts about "what are the basic elements of excellent software design"! Next, please follow the small series to learn together!

Good design is simple.

Often, the code I encounter is perfectly structured, has the appropriate interfaces, and employs specific code patterns and code style tools that don't return a single error or warning. But I still think it sucks.

Every time you write something, it should be proportional. Many developers adopt patterns just for the sake of patterns. They are almost shouting,"Look how strong I am at adopting this pattern I just read," rather than really understanding why they chose a particular pattern.

Good design is usually simple. I mean proportional to the size of the solution they offer. If you provide your app with simple functionality that you use only once, should you use all sorts of fancy stuff? Consider whether the complexity of your code is proportional to the solution you provide. Will your functionality be the backbone of your application, or will it be the basis for extensions or inheritance in your application? You'd better make it reasonably structured. Is this just a solution to a minor problem in your application? It's best to keep it as simple as possible.

We tend to overcomplicate our function.

When we talk to the project lead for our application, we retrieve requirements. After first proposing an implementation idea, we often overcomplicate the initial design of the method. It is often beneficial to sit down with a few developers and dig into what is actually needed. There are several ways you can ensure a simpler solution.

the right questions

As developers, we are often asked to do something and we just do it. This on-demand behavior may be normal for junior developers, but as you move forward, try asking smart questions and make sure you answer them before estimating or designing a solution. When you ask certain questions over and over again, you also train your product owners or managers to consider them before requesting functionality. Questions like this:

What is the ultimate goal of this feature?

Who will use it?

Is there a simpler way to achieve the same goal?

Will it make the app bigger and more complex? Is it worth it?

Divide the solution into parts

The first thing I always do is stay away from apps that need functionality implemented in them. Then consider the smallest piece of code you can make and deliver, which brings you closer to the goal you set for this feature. Do this for all of them, reassessing whether all steps are necessary and estimating their development time separately. Also, try to develop these elements as independently as possible. Swap features, and the easier it is to change or remove features, the easier it is to write code.

If certain essential features are really important, challenge the Product Owner

When you divide your methods into smaller parts, it is usually easier to have discussions with non-technical people. This allows discussion with the team and product owners and re-evaluation of whether all parts are needed. Because you've estimated them, you can make better value-based decisions if the features are worth it.

Don't forget to estimate the complexity it adds and how it affects the cost of maintaining the application.

Good code is easy to change.

If the code is easy to change, it is less expensive to maintain, easy to understand, extended, deleted, and even changeable! As the Practical Programmer puts it: "If something adapts to the people who use it, it is carefully designed. "Essentially, all design principles are a way to make code easier to change. Decoupling, single responsibility principle, dry. These are principles that make your code better and easier to change.

Why I hate comments in code

When you need to comment code, it basically sucks. When you need to explain why you want to do something, the code isn't self-explanatory, so you should refactor it anyway. Code comments clearly indicate the error code, and there are many simple steps you can take to make your code more readable.

Comments don't make up for messy code. When code is confusing or makes dangerous assumptions, we tend to write extra comments.

The only comment that makes sense is:

law Review

Statement of purpose

improve readability

Warning of consequences

to-do

How to Write Better Code

There are many simple principles that can help you write code that is easier, and your colleagues will love and enjoy working with them. For each of these, you can write a completely separate article, so here's a simple checklist to start you on your way to better code.

class

Classes should be small. How small? As small as possible. A class should have only one responsibility, and its name should derive from that responsibility. If you can't think of a logical and descriptive class name, it's probably too big.

method/functions

Like classes, they should be small, do only one thing, and have explanatory and simple names. Pay attention to the logo. Many indentations are usually a sign of a messy approach. For Foreach and switch statements, make sure you write the actual code that executes in a separate function, which makes it more like an index of what the method actually does for different implementations.

meaningful name

Classes, functions, and variables should all have meaningful names. For example, do not use $ a = b;. Make your code a document of functionality and intent.

Format and code styles

Make sure your entire application and team uses exactly the same code style, and be very strict about it. Every IDE and language has tools for this purpose. Consistent spaces or newlines can go a long way. If not, it will drive you crazy. Being very strict in this respect will immediately improve the cleanliness of your application, especially in languages that are not very strict in this respect.

At this point, the study of "what are the basic elements of good software design" is over, hoping to solve everyone's doubts. Theory and practice can better match to help everyone learn, go and try it! If you want to continue learning more relevant knowledge, please continue to pay attention to the website, Xiaobian will continue to strive to bring more practical articles for everyone!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.