This article is a summary of some of my thoughts and thoughts about my software development career. IT technology has evolved rapidly in recent decades, with the emergence of so-called “best practices” in various fields. What I want to talk about today is that these so-called best practices may not be the “best”, and sometimes they can even be the “worst”.

A stand

First of all, I have no intention of rejecting best practices. I am one of the many people who have benefited from a full-stack framework of Best practices for Web development, such as Ruby On Rails and Django. According to their own experience or community these framework developers put some convenient to a developer, for example, database operation, the directory structure, routing customization features for effective organization and integrated into the framework, although different community focus is different, but generally not from MVC the model base. Maybe I can argue that even though they “look” different, write differently, and belong to different communities, their core souls and concepts are the same.

However, it would be a bit of a rascality to differentiate between the basic concepts and pick a “best practice” from Rails, Django, etc. As mentioned earlier, each community has different priorities. I didn’t know about static resource compilation when I wrote Django, and Rails had AssetsPipline back then. In addition, Django is probably precompiled to make i18N more efficient, whereas Rails reads directly from yML files at runtime. So who did it better? It seems to be a matter of opinion.

To that end, let me briefly summarize the best practices as

Practice of the best ideas in a particular field.

The practice of “best frameworks” and “best grammars” seems to be in a different channel from what many people are looking for today. You’ll bash Ruby for not being fast enough, he’ll bash Java for being verbose, and someone else will bash C++ for having too complicated syntax. Who is the “best” at this level can really make a difference? What is appropriate is best.

I’ll talk about best practices in a few ways, and the negative impact some of them have on teams.

Shortest is “best”? The abuse of grammatical sugar

Development today is becoming more abstract. There seems to be a popular idea among people that shortest is best.

Think of the year the team released ES6 in order to “mask” the ugliness of the language itself. It did bring a lot of benefits, such as block-level scopes, the class keyword, generators, decorators, and so on. With these tools we can make code shorter and more elegant, which is not a problem in itself, but it also seems to open the door to excessive encapsulation.

A decorator, for example, is essentially a syntactic icing that does something like this

@ decorator class A {} / / is equivalent to A class A {} A = decorator (A) | | A;Copy the code

This is a nice improvement to be able to simplify the syntax. But once it’s used, the code gets a little weird, and I’ve seen it before

@a
@b
@c
class A {}
Copy the code

The sugar coating becomes saccharin – or syntactic syrup, which is the added syntax that fails to make programming easier. This seems to answer the question

Money makes shallow people shallower and deep people deeper.

One of my earliest encounters with decorators was when I was writing Python, and I remember someone saying, “Even if decorators are good, they can obscure your code, so limit the number of layers.” As a programmer, we should make our code more concise on the basis of legibility. Pursuing short code without legibility is pure showmanship. If we really write code for showmanship, why not just write binary? Then few people can really understand it, and it will look very high-end.

Is uniform writing equivalent to best practice?

These days many people are pursuing uniformity of writing

Write Once Run Everywhere

It’s called improving development efficiency and making programmers more productive. React Native makes it possible to write mobile apps with JavaScript, which seems like a good thing. I can write mobile apps just by learning React. What’s more, the rise of frameworks like MPVUE and Taro seems to mean that you can write small programs or apps just by learning React or Vue. Assuming you have a React team, perhaps using frameworks like Taro would be more fun than writing native applets with native syntax, which many consider best practice. But from what I can tell, the world is a lot rougher than you think.

After all, I haven’t been able to develop frameworks of this type, so I’m not in a position to comment on them, but I’ll just stick to the facts. I have the following considerations for uniform writing

1. Is uniform writing important?

I remember some of the proponents of such frameworks saying “wechat’s syntax is bad, so I want to use this framework”. “, “Focus on writing specific businesses using React or Vue, not the stupid syntax of small programs.” And so on.

I think the best way to answer these questions is in the words of Joe Dada, the inventor of Erlang

Erlang is not suitable for all scenarios, and if you find another language that is more suitable for a particular scenario, I will be the first to support you using another language to solve the problem.

Every technology has something it’s good at. Trying to do everything may lead to doing nothing well. Even if teams continue to “polish” JavaScript syntax, JavaScript is not going to take over. It was nice to be able to write applets using the Vue and React syntax. But when you look back, is it hard to learn applets or React? The answer is obvious.

Don’t we need to learn small programs when we have a framework that is unified? Not likely. Even the relatively stable platform of mobile terminal is still unable to do this. According to the feedback of some of my mobile development colleagues, React Native can indeed complete many business scenarios, but you still need to write object-C or Java code to solve many problems (sorry, Our company is not on Swift and Kotlin yet.

This seems to be a cry for the mobile development community, before doing mobile development to understand object-C or Java, and then go into related fields, learn tuning, the salary is quite high, it is easy to find a job. Now that the so-called “best practices” of uniform writing are in vogue, you have to learn JavaScript, React Native, and a bunch of precompilation tools in addition to these. Wages seem to be falling and jobs are hard to find. But isn’t it a bit frustrating to think that the problem you’re essentially solving seems to be the same as before?

2. Does it really solve the problem?

We all know something called the 80/20 law

80% of the things you do take 20% of your time, and the other 20% will take 80% of your time.

Allow me to apply this theory to small programs. I personally have been fortunate enough not to have the opportunity to develop small programs that allow me to observe the work of my colleagues from the sidelines. From their development experience, the development of a small wechat program, as long as the customer is reasonable, the normal business logic actually does not take much time. Isn’t the value of small programs simply lightweight?

However, small procedures have a problem is that the platform is not stable, frequent updates. This process may fix some bugs, but it may also introduce new ones. Often, a small program with a relatively small business complexity can “hide” these problems for as long as the business development time. Can a more encapsulated framework “fix” this problem? I feel like I’m building a house on sand. In addition, business scenarios are different for everyone, so I don’t believe that an abstraction based on an unstable platform can automatically deal with the problems of the platform itself.

It reminds me of Gavin from Silicon Valley. Belson

Think of a revolutionary feature that, once integrated into the Nucleus platform, could fix any problems with the launch process.

He really is the most unrealistic, manipulator-driven tech executive of the 21st century, and there seems to be a lot of them. Sadly, this is also the original intention of many people in the last framework, thinking that the framework will help us fix some of the problems we don’t want to fix ourselves, forget it, the world is still cruel. On the other hand, using a framework developed based on an unstable platform, the probability of bugs is relatively large. When bugs occur, you may have to spend time to locate the bugs caused by wechat itself or the development framework, which are time-consuming work. What problem does the framework help you solve?

As for the problem of uniform writing method, a speaker named Terry (who is now the CEO of Nervos Network) said a sentence in RubyConf China in 2016, which greatly influenced me. The general idea is as follows

I find that Web development today is no different than it was ten years ago. Ten years ago we wrote the back end in Ruby and wrote the front end interaction in JavaScript. Why do we have to write the same way ten years later?

In retrospect, the best practices the industry foists on you may not be as “best” as you think. As programmers, we are hired to solve problems, so try not to complicate them.

Is it best practice to separate the front and back ends?

Is it a best practice to separate the front and back ends? Different people will have different views on it. In my opinion, solving the problem is the end, and separating is only the means. With React, Vue and other frameworks becoming popular, there’s a lot of criticism about the “best practice” of separating the front end from the front end. It’s true that separating the front end from the front end allows the front end to focus on its own development process, but sometimes when the front end is separated from the back end, the front end will run wild. It’s what Rei calls a front end split.

After make full use of Webpack is big, we can even use your favorite any grammar to write the front-end process, gradually may develop into a DSL only themselves to understand, people familiar with the nature with ease, however other engineers to learn, understand, and the question will spend some time each other, this is the cost. I’ve always felt that if a front end engineer writes code that requires a lot of effort on the back end to read, it might be worth a little introspecting. Is something being over-engineered?

Front and back separation is a double-edged sword that requires front and back people to coordinate projects so they don’t get out of control. You need to think about what is the benefit of separation, is it for easier form submission? Or is it for smoother page interaction? It’s not as if Facebook invented React and it rewrote Facebook and Instagram with this framework that we have to follow. Sometimes you have to think about how big companies like Facebook are. If we only need to improve the interaction effect of some pages, maybe Gitlab will be more suitable for us to separate the resources of only the key parts. Any separation just to get out of the back end without considering the actual situation seems to me to be a mess.

Best practices sometimes take you away from the root of the problem

This is a problem that companies have encountered recently with containers. Recently upgraded the official website service, want to do some container exploration based on this project. The initial vision was to move away from the original Capistrano deployment (which was not a good idea) and then

  • Containerize the official website project.
  • Container-based automated deployment.

OK, in theory I just need to learn how to container the whole project with Docker-related technologies, and then use auxiliary tools for automated deployment. At this time, my operation partner introduced Kubernetes(K8S), the “best practice” of containerization in the industry. It was a good thing, but it also caused me other problems

  • Following the best practices provided by K8S, we need to store the configuration files in Etcd (a configuration management service).
  • How can SSL certificates be managed, and should the more popular Caddy service be used?
  • Service is much how to do reverse proxy? K8S has something ready to use, and it is convenient to expand the capacity in the future.
  • Which services need to mount data volumes?

Well, it took a while for someone with little knowledge of K8S and little operational experience to digest these issues. I spent a week or two of my free time looking at the K8S documentation. It wasn’t difficult to get familiar with the K8S commands, but to sort out the relationships between the different services. Implementing the corresponding “best practices” can be a headache and time-consuming task. There were a number of other projects that interfered with the launch of the new website because the effort was taken up elsewhere.

It was as if we were all so immersed in the industry’s best practices that we lost track of what we needed to do and what we needed to solve in the first place. The essence of what we want to do is just deploy the project, preferably automate it. K8S and the associated best practices are optional, and we indulge in the best practices without tasting their benefits, and are further away from the root of the problem.

People tend to implement a 100-point solution without thinking about the time and effort it takes to get to that 100-point solution, and sometimes a less-than-perfect 60-point solution works better for them. So in the end we decided to just finish the basics of the container and deploy the project as soon as possible. Postpone the K8S thing and slowly optimize the solution with only 60 points in the future.

Best practices hold you back

It’s a chicken-and-egg problem. In the past, people generally rolled up their sleeves to do development, and after accumulating experience, they slowly reconstructed what they had and got the framework we had. In other words, people who solved problems first and then abstracted the general solution into a framework seem to be different now. Many developers today look for best practices when they have a problem, and don’t even dare to solve the problem without best practices. Perhaps that’s why Linus, the Linux kernel developer, once railed against best practices. He said

Best practices are often shit.

Is “best practice” even a best practice when it becomes a mental constraint and a huge threshold for solving problems? What is the point of a framework when a developer is so caught up in the idea of a framework that he can’t get anything done without it? Do you still remember what Zhang Sanfeng did when he taught Zhang Wuji taijiquan and tai Chi Sword? Forget all the moves. What is the use of these so-called moves if they are only shackles to a man?

In fact, many times the solution you can come up with is good enough. Ruby On Rails has been around for more than a decade, and there is still a lot of room for improvement. How many of those dazzling frameworks On the market have experienced this kind of precipitation over time?

Erlang’s creator, Joe, once made this comment about a language not being fast enough

Write the program right first, then refine it slowly, and after many years it will be faster.

Rather than focus on high performance, best practices in the first place, there may be times when you can think about “writing the program right,” even if the solution isn’t optimal, at least you’ve thought about the problem, rather than just trying to use it. If there is a better solution in the future, I believe it is not too late to optimize.

conclusion

Above is I in the process of software development “best practices” the idea of twitter, I personally is not completely exclude best practice, but I think the best practice is to have a scene limited, given the time cost and implementation difficulty, the factors of the personnel allocation, in some scenarios “best practice” in other scenarios may become the “worst practices”. It would be highly irresponsible to yourself and your team to just go along with the crowd and follow “best practices” without thinking about anything.