preface

I just had a session with my colleagues where I shared some code design patterns.

I also reviewed some of the complex business scenarios in the project and why the design patterns were not well applied.

Although the business is definitely confidential, I looked back at my previous projects beyond the project and business level.

There are a few things worth writing about design patterns and code specifications.

The body of the

What exactly are design patterns?

The prevailing narrative goes something like this:

Design patterns are descriptions or templates for solving problems that can be used in many different situations, and are generally the best practice solution in OOP.

The term “best practice” has come up in several places where I have introduced design patterns. But are design patterns really the best practice for business development in OOP?

First of all, I would like to state my opinion on how I understand design patterns:

A design pattern is a code specification, different fromThe blank space.The indentationThis kind of introductory specification, which is easily detected by plug-ins, is oneIntermediate code specification, should not be understood by beginners, is not easy to be detected by plug-ins.

So I think design patterns are at the code specification level, and it’s up to the user to make them a best practice.

The presence of design patterns in normal business development

We can see many people share their “ancestral code”, “turtle qigong code”, “shǐ Mountain code” and so on.

Don’t we have design patterns? Isn’t there a code specification?

Survivor bias is partly to blame, and only bad code is put up for ridicule.

Comprehensive view this kind of situation is still a lot, so is how to cause this kind of situation, is this session programmer level not good?

Pain points for normative code or using design patterns

I first reviewed some of the reasons why design patterns do not work well in business development.

performance

At the extreme, as in the Java language, design patterns face more class files and more code.

The cost of class loading and memory usage is, of course, slightly higher than not using design patterns.

However, it can not be generalized, some design patterns (such as: singleton pattern, share pattern, etc.) is to improve performance or save resource costs.

And most of the time, the benefit of good code maintenance far outweighs the tiny performance overhead, so performance is strikeout.

Class blast

Although there are small Demo codes for various design patterns on the web, it is still possible to have design flaws, over-design, and so on.

Complex design patterns, which rely on business modeling, are not readily available or even “hard-copy”.

Both design flaws and overdesign are equally painful to developers, and an explosion of classes is inevitable when code “shouldn’t be used for design patterns” or simply “fits a flawed design pattern” by writing logically complex code.

Moreover, even with the normal use of design patterns in business complexity, class explosions are inevitable. For example, the policy pattern, if there are many business cases, you must also write out the implementation classes for each case.

This has a slight impact on the time cost of development.

I even know that some traditional companies, or Japanese projects, almost always have an Excel document for each class, detailing the purpose of the class and its elements.

You’re probably thinking what I’m thinking: just find a Javadoc API and generate Excel from comments backwards.

But in reality, most of these companies still rely on people to do the work, and the number of classes increases, which is also a huge challenge for the people who maintain the documents.

Team member coding level

In traditional software companies, it is difficult to achieve full “high staffing” and self-driven spirit for cost saving.

It’s also a bit embarrassing to expect underpaid junior engineers to have “high cohesion, low coupling, and the six principles of design patterns represented by the open closed principle”.

As an aside,

And many junior engineers are actually “adaptable” to the framework, but not really.

For example, if you don’t have uniform exception handling in your code, over time you’ll end up with your own try catch all over the place.

For example, if there is no utility class library in the project, then over time you will find strange Util classes everywhere on the web, and even duplicate utility methods in each class.

These are not the problems of junior engineers, but the technical leaders. For example, if they observe that there is no tool library in the project, should they first look for the two-party library in the company? If not, should they introduce excellent third-party libraries such as Commons-Lang3, Hutool and Guava?

Project environment

We live in a highly architecture-oriented traffic age. High concurrency, heavy traffic, various microservices, and middleware construction have become the mainstream trend.

So design patterns at the code level and the normative status of code are a little more subtle.

I’ve seen many projects where the architect only thinks about the “add machines, add middleware, add configuration” superstructure. As the team members are out of level, the requirements for the code are almost zero, and there are no rules such as review, which can be implemented.

Time cost and Agile development

In an agile development scenario, the business changes frequently and projects iterate quickly, which is certainly a factor.

For example, if you can optimize the if else strategy pattern, would you use design pattern if there was only one branch at the beginning? What about the change in demand plus one? What if I add another one?

When to tune code with design patterns, whether to tune it at all, and when to tune it at all, is a question.

Usually, experienced engineers don’t say things like, “It’s just one line of code, fix it in a minute.”

After all, when you change code, you need to think globally (whether other code has the same modification requirements), correctly, and branching (whether it affects the execution of other logic).

There are even companies that have requirements for coverage and testing classes, so typing speed is not the rule of thumb.

The cost of time is also a factor.

mobility

Mobility on the Internet is nothing new.

On the one hand, the reason is the company, with the reform spring breeze blowing everywhere, has come to the era of “boss” everywhere, some companies, unreasonable requirements, even the provisions are against fa behavior leading to brain drain. The second is personal reasons, the high level for the high salary, low level by low salary dissuade.

Whatever the reason, code quality is a management challenge in a world of high turnover.

After all, if you have a complex logic of turtle qigong code, the business logic is not completely clear, most people will honestly add if else to fulfill the requirements.

Analysis of the

Do code specifications & Design patterns Matter?

The above list lists some of the pain points of code specifications and using design patterns in project development.

The reason it’s called a pain point rather than a weakness is just like in some of the scenarios above, where the code isn’t important and the code specification isn’t worth mentioning.

Therefore, the importance of the above, in addition to subjective factors, team factors, and even the reasons of the team manager. After all, there are some scenarios that are just developer-friendly and useless for KPIs, leading to neglect.

How do you consistently do good code specification

If we are a geeky team, or if we are designing products for long maintenance, it is advisable to have code specifications and design patterns in place.

Then you might as well summarize the pain points from the author, combined with their own current scene analysis, to achieve a “balance” point.

The author also summarizes a few points to deal with the above measures, but everyone has their own situation, and the design pattern itself is the same, can not be “raw copy hard set”.

• In-depth understanding of the business, do a good job of business prediction, so as to lay a good foundation for the underlying design.
• Under the condition of protecting the human cost, there are not a few self-driven members today, so we should give confidence to do a good job in infrastructure construction together.
• At an early point in a complex business with frequent iterations, the technical lead needs to step in and measure the time spent analyzing the business in order to determine whether refactoring or code design is needed.
• Under the frequent flow of personnel, the work should be documented as far as possible, not based on “formality”, not only good handover code, but also good handover business.
• Traditional projects and Japanese projects should make full use of automated tools and replace manual document maintenance as much as possible.

Of course, the pain points mentioned in this article are most difficult to find in small and medium-sized companies, and can not be solved in a few words, so it is very good to try to balance.

If these pain points do not exist, the strong self-driven personnel, good infrastructure and so on. Large probability is good enough enterprises, if you are the employees of such enterprises, but also insist on seeing here, then when to understand the small problems of small and medium-sized enterprises.

At the end

At the beginning of my career, I also looked at the historical code and laughed, “Such a disorderly code, I am afraid to drink counterfeit wine in bulk.”

Time has changed, with the growth of years of work, the perspective of the problem is also constantly changing, now not only will not be laughed at, but also summed up the reason for the emergence of disorderly code.

I also have a new understanding of my thinking about design patterns and code specifications. As mentioned above, I happened to have a meeting with my colleagues, so I sorted it out.

The tag of this article is set to “code specification” under reading, because this article does not have technical dry goods, it is experience sharing, I hope to help you.