Programmer, efficiency and quality who do you choose?

The author of this article is the program ape Daniel F Pupius, this is a post he posted on medium, describing how he actually wrote the code in the process, found that the choice between efficiency and quality is actually a false proposition.

When a program development project is in progress, the confusion usually emerges: should we choose efficiency or quality? Many program apes will have lazy thinking, feel that some confused, do not know how to write the code fragments removed, you can save a lot of time, earlier to complete the project plan.

In fact, in the past few years, I have thought so, but recently I began to realize that the problem is not to choose difficulties, but the problem itself is a pseudo proposition.

What is "quality"? When the average programmer says "quality," they say it is possible to test pass rate, variable naming, code formatting, component, find bugs, program testing, and more. It may also be the extension of the program, the service delay, the integrity of the product function.

Often the problem arises when the two are treated as if they were unified and not differentiated. In fact, the former problem surrounding the code can be seen as a "code quality" problem, and the second can be seen as "quality of execution", or "degree of execution."

From the "code quality" to see, the process of the monkey shortcuts to the lazy thinking, in fact, is a very short-sighted approach. Ambiguity bypasses a problem, and you may find it easier for a while, but in the end, it's often found that it's confusing the system and takes more time to check the code, find bugs, and even readjust the overall logical framework. So sacrificing code quality in exchange for speed is usually a loss.

Conversely, high quality code can actually help you save time. Unified code specification and variable naming can help not only other program apes, it can also help you in the future, better understand the code you're writing, and a lightweight code architecture that's carefully designed to allow you to be more efficient at iterating over your products, and to know where to start. Instead of searching the database for places where they need to be replaced, the high test pass rate gives you plenty of confidence to tweak the product, reduce the number of bugs, and minimize QA time.

As for "quality of execution", this is another proposition. There are many ways to make the product development process compact without reducing product quality. For example, you can postpone some of the less anxious work, wait until the overall implementation of optimization, system robustness, and then do those things that are put on hold.

The specific approach is that the final desired product effect set, and then to fill the contents of the constantly modified, as for some irrelevant details can be finally optimized. For example, when you start to develop products, you can use RPC to simplify the application development process, bypassing the complex protocol transmission problem, first in the product application level quickly iterative, then replace RPC, add retry, error control, security inspection code, or simply replace the transmission protocol.

Write Mediun code, we are first to achieve results, and then adjust the refinement section, and finally deleted a lot of can not be integrated into the original set of the function of the frame, about 60,000 lines of code around.

So if we're not careful with the quality of the code at first, we're going to end up looking for all sorts of subtle problems. If we are not fully focused on the implementation of the effect, we will procrastinate to postpone the project progress. But as you can see, it is fortunate that we have done a good job in the early stages, so now the product is ready to iterate and experiment with new features.

In fact, in the Internet field, not only the program ape will face the above problems, many product managers will also for the project progress and quality fighting problems. So Daniel's blog provides a good point of view, and maybe the next time someone asks you if you can sacrifice a bit of code quality to catch up, you can tell them: you're asking a pseudo proposition.