Translation Quora is how to maintain high-quality code

Original link: Moving Fast with high Code quality
Translator: Jay Micro Magazine-Chenghui

A high-quality code base can speed up long-term development because it makes iterations, collaboration, and maintenance easier. At Quora, we attach great importance to the quality of our code base.

In addition to earning revenue, maintaining high-quality code can lead to a significant overhead and sacrifice to the actual development cycle. Many people find it hard to offset this overhead by actually generating revenue, when people face two choices: either to increase development speed with low-quality code or to maintain high-quality code at the expense of development speed. For startups, they want to develop faster, so they have to use low-quality code.

We have developed a range of tools and processes that can improve the speed of development while maintaining a high-quality code base. In this article, we will cover some of the ways to ensure the quality of the code, as well as some specific cases of balancing these two aspects.

the goal of maintaining high-quality code

The main benefit of maintaining high-quality code is the ability to drive development over the long term, which is the focus of our attention. Short-term costs generated by writing clear code can be used for long-term gains.

Keep this in mind, and then here are the four basic principles that we find very helpful in code quality:

Code Quality Fundamentals for Quara

1. The code is easy to read and understand-it is now more time to read the code than to write the code. In fact, you should reduce your reading time, even if it means spending more time writing code.

2. Different parts of the code need to have different quality standards-different lines of code need to have different use time, scope, risk of being destroyed, cost of being destroyed, and cost of repairing, etc. Overall, these have different effects on the long-term iteration speed, so it is unreasonable to enforce a uniform quality standard.

3. The indirect cost of code quality can be reduced-overhead costs for maintaining high-quality costs are generally savings, which can be achieved by using automation, better tools, better processes, and training for better quality developers.

4. Code base consistency is important-keeping the entire code base consistent is valuable, even if it means that some of the code is not optimal. An inconsistent codebase is difficult to read and understand (see 1th), it is difficult to write, and is difficult to optimize with automated tools.

Let me show you a few examples of how these principles are used for practical development.

Post-commit code review

Code changes in our code base need to be evaluated from six dimensions-correctness, privacy, performance, architecture, reusability, and style. Reading the code is a key part of coding review, so the code review plays a crucial role in improving readability.

But one thing that's bad is that code review also slows down the pace of development. For example, the pre-commit code review is now more common in the industry, where the code must be reviewed and modified before it is pushed. In this case, even if it takes only 2 days for each round of review to repeat the 2-3 rounds, it will also delay the developer for a week, which is a serious waste of time.

In Quora, our main thing is to commit code review after submission. In other words, the code first enters the production phase, and then someone is asked to do code review. To give you a sense of the scale of the job, for example, yesterday we had 48 people pushing 187 of codes. Post-review is a good idea because it frees up developers and can do other work. Code review staff can also better manage their time, can do code review at their convenience, rather than have to rush to complete the work, so as not to affect other people's work. If the process is reasonable, the code review is expected to be completed within a week, but in most cases it can be done in a day or a day. The reason for a week is also carefully considered, because the week is long enough to allow the censor to be flexible, and a week is a little short because it needs to minimize the impact of bad results, such as having someone read the code and spread the bad code across the code base. In fact, there is a layer of reason, many developers are weekly personal work arrangements.

We can do post code review because we believe in each of our developers, we choose the best talent, and we invest a lot of money in their code quality training/tools. This also pushes us to better test the code, and good testing can help detect the accuracy of the code, even before any code review work begins. In this respect, we are using phabricator, a robust, high-profile review tool. We've made a few improvements to it so that we can work better with our post-commit code review workflow. For example, we've built a command-line tool that pushes code to the production stage and makes code review requests. With this tool, Phabricator diff can continue to work without having to fix those commits.

All of these instructions, for different types of code issues, we have different code review criteria. If we have identified a potential error in advance, the problem is large and may have a significant impact, then we will instead perform the pre-submission review instead of the usual post-submission review. A few examples in this regard:

1. Code that involves user privacy and anonymity.

2. Abstract classes (abstraction) that involve the core, because many other code may depend on it.

3. Some parts of the infrastructure are involved, and some errors can lead to the risk of downtime.

It also depends on how developers make decisions-if they want to review some code before committing it, and then get more ideas from it, it's also possible without having to use the usual post-commit code review, but this is a rare situation.

Code Review Task Dispatch

In order to do code review, each change should be reviewed by a person with relevant experience. It would be even better if these code review personnel were responsible for "maintaining" the codes they had reviewed, so that they could get a certain amount of material reward and thus form a long-term trading relationship.

Before we implemented a simple system, the "ownership" of its modules and directory-level code needed to be specified by assigning a meta tag (meta tag) at the beginning of the file. Like what:

__reviewer__ = ' Vanessa, Kornel '

If a commit is to make some changes to the file, its reviewer is parsed according to the file (or tree "ancestor") and is automatically added to the commit as reviewer. We have some other rules for assigning or routing the Code Review task, for example, if there is no reviewer, a data scientist can automatically be added as a reviewer to a commit that launches A/b test. In fact, we've built some tools that will make it easier for us to make more of these custom "routing" rules. For example, if we want to do it, it is easy to add a rule that can route all commits of a new task to the appropriate person.

Such an intelligent system, which assigns all commits to the right People for code review, can effectively reduce the burden on developers, or they will need to look around for the right censors, and ensure that most censors are able to scrutinize every commit.

Test

Testing is a very important step in our development process, and we have written a lot of unit tests, functional tests, and UI test code, covering a wide range of tests. A comprehensive test allows developers to work in parallel and work faster without worrying about breaking existing functionality. We have invested a lot of time in developing test frameworks (built on nosetests) that make them easy to use and fast to apply, thus reducing the overhead of writing test code.

We have also developed several tools to automate testing. We have previously published an article on "Continuous Integration Systems" that describes a central server that can run all tests before any new code is deployed. The test server can run in parallel so that it takes less than 5 minutes to run all the tests. This rapid operation can motivate people to write and execute test procedures regularly. We have a tool called "test-local" that can only identify and execute test files related to the test changes of the working copy of the Code. To be able to do better, our tests also need to be modular (which can help us quickly debug when the test fails). To ensure that good test code can achieve the desired performance, we maintain a shared document that describes best practices related to writing test code. These guidelines are strictly enforced during the code review process.

As with code review, we have different testing standards for different types of changes, with higher requirements for the scope of testing, especially where the cost of change is high.

All of these systems allow us to get the most out of the process of writing test code, and we can save a lot of development cycles with very small overhead costs.

Code Quality Guidelines

We are very passionate about the guidelines for sharing code quality standards, which can help us do a lot of things:

① is a great tool for training new developers.

② shares everyone's wisdom and best practices with the entire team.

③ reduces overhead costs for development and code review processes. For example, if we discuss it once to get some valuable conclusions, then it is meaningless to discuss whether the line should be 80 strings or 100 strings each time code review.

In addition to the grammar style guidelines for different languages, we have some guidance for abstract transactions, such as how to write a good test case, or how to make a better modular architecture to improve productivity. These guidelines are not immutable and evolve as we have a deeper understanding of the different processes. We also have a lot of refactoring tools (some open source tools such as Codemod, and some internally developed tools) that we need to re-"modify" all of our historical code when we change our guide.

Cleanup of old code

A fast-growing team will try many different tools, of course, some of which are usable and some are not. At the end of the day, any fast-growing company with its code base will develop a lot of superfluous stuff over time, and these may never be used again, and it will only make a lot of things confusing. Cleaning up these obsolete code can make the code base run more healthily, and it can increase the speed of development.

We regularly organize "cleanup weeks" to clean up these extra code. During the cleanup week, some teams may sometimes launch the entire company to clean up the old code. This regular cleanup mode reduces the cost of switching back and forth between "normal work" and "clean work", and makes the cleanup work more social and fun.

Some parts of the codebase are better cleaned up than others. Similarly, cleaning up different parts of the codebase can have a different impact on development speed. In order to make better use of the old code cleanup time, we have optimized the relevant modules on the basis of cost, to clean up the work, and to measure the impact of cleanup on the future development speed.

linting

We are likely to underestimate the cost of not complying with the above code quality guidelines (for example, docstring format or line length) in an instance, but in fact the cost is actually increased. At the same time, it is annoying to remember all kinds of rules and apply them, especially the rules are increasing. The end result is that many people choose not to follow these guidelines.

We have developed an internal linter, called Qlint, that can alleviate some of these problems accordingly. Qlint is a very intelligent linter, can read the text structure as well as the AST, is based on Flake8 and Pylint. It is designed to make it easier to add custom lint rules in the future. For example, one of our practices is that any "private" variable in Python needs to be highlighted, so we have added a new rule in qlint that can detect any unreasonable place in such a private variable.

We also integrate Qlint with many systems to provide a seamless development environment so that people do not have to stare at the lint errors themselves. For beginners, Qlint is a fully integrated tool with our common text editor--vim,emacs and sublime--, which provides visual feedback (red flags) in the event of a broken rule. It's also integrated with our push process, where anyone can run Qlint (in an interactive way) when it comes to code push. In fact, if a rule is broken by a commit, it can potentially affect the deployment effort. We also integrate our style guides with qlint so that for every lint error, Qlint can give a hyperlink that points to the appropriate rules for the relevant style guidance. Our phabricator can also be used qlint. In this way, all errors found by Qlint are clearly marked, so that their code review work becomes quite easy.

All of this has helped us to improve the consistency and quality of our code at a very small cost.

Conclusion

As the article says, Quora's emphasis on code is high. We emphasize pragmatism and build up a lot of good systems, tools and processes to help us enhance and maintain our long-term development productivity. Today we strive to maintain a good balance, our team is also growing and growing, so we believe that in the future we will also produce more tools and systems.

If you want to help us build such a system, or want to be part of our strong development team, to help us improve our code quality in such a pragmatic and profound way, then welcome to join us.

----------------------------------------------

Believe that love reading you, has recently noticed us.
We will be launching a series of good content on business design and technical architecture.

You are also welcome to comment, recommend articles, in order to let others understand the world, make their own contribution.

Contact for any purpose is welcome.
My e-mail:[email protected].
My qq:3272840549.

Original link: Http://www.jointforce.com/jfperiodical/article/942?f=jf_tg_bky

Translation Quora is how to maintain high-quality code