Collaboration on code at Google
In the second chapter of the book “Coders at Work” , Brad Fitzpatrick is the author of the Live Journal, and now Google’s employee, in addition to interesting stories about creating a Live Journal, about learning and many other things, also tells about the principles of code ownership and about collaborating on it at Google.
As you know, Google has the ability to use twenty percent of their working time for purposes other than the goals of the current project (but in the goals and interests of the company as a whole). This phenomenon is called a grouplet (you can read about it in the wonderful article "The Google Way: Give Engineers Room" , or in the translation of this article here ), respectively, each developer may have a wild desire to dig into someone else's code and participate in what something project. And since, to put it mildly, there are many such projects, some formal rules are required that will allow keeping all code up to date and will not allow its quality to drop below a certain level.
')
In Google (according to Brad, I myself was not, I don’t know) all code is stored in a single repository, with one root of a huge tree and each person can get the source code of any project at any time. There are no restrictions on this, i.e. Every employee has access to reading, but this does not mean that anyone can upload this code back with their own corrections.
In order for the corrected code to go back to the repository, two requirements must be met. First, you must get “approval” from the code owner (code owner), and secondly, approval from a certified specialist in the programming language used in this project (readability approved person) (by the way, it’s not necessary to these were two different people, these two roles can quite get along in one person).
There should be at least two owners of the code (this reduces the likelihood that the code will not be commited to the repository due to the fact that the owner of the code is sick, retired or married), and the readability captain is responsible for readability in a specific programming language whose concern is to maintain a sufficient number of specialists in the appropriate programming language. If you or one of your direct reviewers is a readability expert, then everything is fine, otherwise you will have to find such a person and involve him as a reviewer. Each person can pass the corresponding exam and thus become a readability expert and either participate in the revision of the code of other employees, or else this will allow him to eliminate one of the steps while maintaining his own code in the repository.
Code analysis (readability review), which is carried out by an expert on the relevant language, is designed primarily to ensure a consistent style of writing code, because for any major project the unity of style and the minimum number of brain “switches” when reading from one style to another is more important. In this case, it’s not the absolute utility of a rule that comes to the forefront, but its consistent application (yes, I personally prefer a different indent format or variable naming format, but it’s much better that the formatting style of the code is the same, regardless of the hundreds of different preferences of different employees) .
Such an approach to working together on the code may seem complicated and bureaucratic, but, according to the employees themselves, this does not cause serious trouble.
By the way, how are things in your company with ownership of the code and joint work on it?
Additional information about readability review:
Code readability
Excellent article, from which I brazenly borrowed drawing:
Experience in implementing Web 2.0 services for managing information flows in a non-profit organization
As you know, Google has the ability to use twenty percent of their working time for purposes other than the goals of the current project (but in the goals and interests of the company as a whole). This phenomenon is called a grouplet (you can read about it in the wonderful article "The Google Way: Give Engineers Room" , or in the translation of this article here ), respectively, each developer may have a wild desire to dig into someone else's code and participate in what something project. And since, to put it mildly, there are many such projects, some formal rules are required that will allow keeping all code up to date and will not allow its quality to drop below a certain level.
')
In Google (according to Brad, I myself was not, I don’t know) all code is stored in a single repository, with one root of a huge tree and each person can get the source code of any project at any time. There are no restrictions on this, i.e. Every employee has access to reading, but this does not mean that anyone can upload this code back with their own corrections.
In order for the corrected code to go back to the repository, two requirements must be met. First, you must get “approval” from the code owner (code owner), and secondly, approval from a certified specialist in the programming language used in this project (readability approved person) (by the way, it’s not necessary to these were two different people, these two roles can quite get along in one person).
There should be at least two owners of the code (this reduces the likelihood that the code will not be commited to the repository due to the fact that the owner of the code is sick, retired or married), and the readability captain is responsible for readability in a specific programming language whose concern is to maintain a sufficient number of specialists in the appropriate programming language. If you or one of your direct reviewers is a readability expert, then everything is fine, otherwise you will have to find such a person and involve him as a reviewer. Each person can pass the corresponding exam and thus become a readability expert and either participate in the revision of the code of other employees, or else this will allow him to eliminate one of the steps while maintaining his own code in the repository.
Code analysis (readability review), which is carried out by an expert on the relevant language, is designed primarily to ensure a consistent style of writing code, because for any major project the unity of style and the minimum number of brain “switches” when reading from one style to another is more important. In this case, it’s not the absolute utility of a rule that comes to the forefront, but its consistent application (yes, I personally prefer a different indent format or variable naming format, but it’s much better that the formatting style of the code is the same, regardless of the hundreds of different preferences of different employees) .
Such an approach to working together on the code may seem complicated and bureaucratic, but, according to the employees themselves, this does not cause serious trouble.
By the way, how are things in your company with ownership of the code and joint work on it?
Additional information about readability review:
Code readability
Excellent article, from which I brazenly borrowed drawing:
Experience in implementing Web 2.0 services for managing information flows in a non-profit organization
Source: https://habr.com/ru/post/93465/
All Articles