May 13, 2010 at 14:27Google Code Collaboration
In the second chapter of Coders at Work , Brad Fitzpatrick is the author of Live Journal, and now a Google employee, in addition to any interesting stories about creating a Live Journal, learning and much more, talks about the principles of code ownership and about collaborating on it at Google.
As you know, Google has the opportunity to use twenty percent of its working time for purposes other than the objectives of the current project (but for the purposes and interests of the company as a whole). This phenomenon is called grouplet (you can read about it in the wonderful article “The Google Way: Give Engineers Room” , or in the translation of this article here), accordingly, each developer may have a wild desire to rummage through someone else's code and participate in some kind of project. And since there are a lot of such projects, to put it mildly, some formal rules are required that will keep the entire code up to date and will not allow its quality to fall below a certain level.
In Google (according to Brad, I myself was not, I don’t know), all the code is stored in a single repository, with one root of a huge tree, and everyone can get the sources of any project at any time. There are no restrictions on this, i.e. Every employee has read access, but this does not mean that anyone can fill this code back with their own corrections.
In order for the corrected code to get back to the repository, two requirements must be met. Firstly, you should get “approval” from the 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 at all necessary that they were two different people, these two roles may well 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 committed to the repository because the owner of the code is sick, quit or gets married), and the readability captain is generally responsible for readability in a particular programming language whose concern is to maintain a sufficient number of specialists in the corresponding 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 thereby become a readability expert and either participate in the revision of the code of other employees, or this will allow him to eliminate one of the steps while saving his own code to the repository.
The code analysis (readability review), which is carried out by an expert in the corresponding language, is designed to ensure, first of all, a consistent style of writing code, because for any large project, the unity of style and the minimum number of “switching” the brain when reading from one style to another are much more important. In this case, it’s not the absolute usefulness of a rule that comes to the fore, but its consistent application (yes, I personally prefer a different indentation format or variable naming format, but it is much better if the code formatting style is the same, regardless of hundreds of different preferences of different employees) .
Such an approach to working together on code may seem overly complicated and bureaucratic, but, according to the employees themselves, this does not cause serious trouble.
By the way, how are things going in your company with code ownership and collaboration on it?
Additional information about readability review:
Code readability
An excellent article from which I impudently borrowed a drawing:
Experience in implementing Web 2.0 services for managing information flows in a non-profit organization
As you know, Google has the opportunity to use twenty percent of its working time for purposes other than the objectives of the current project (but for the purposes and interests of the company as a whole). This phenomenon is called grouplet (you can read about it in the wonderful article “The Google Way: Give Engineers Room” , or in the translation of this article here), accordingly, each developer may have a wild desire to rummage through someone else's code and participate in some kind of project. And since there are a lot of such projects, to put it mildly, some formal rules are required that will keep the entire code up to date and will not allow its quality to fall below a certain level.
In Google (according to Brad, I myself was not, I don’t know), all the code is stored in a single repository, with one root of a huge tree, and everyone can get the sources of any project at any time. There are no restrictions on this, i.e. Every employee has read access, but this does not mean that anyone can fill this code back with their own corrections.
In order for the corrected code to get back to the repository, two requirements must be met. Firstly, you should get “approval” from the 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 at all necessary that they were two different people, these two roles may well 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 committed to the repository because the owner of the code is sick, quit or gets married), and the readability captain is generally responsible for readability in a particular programming language whose concern is to maintain a sufficient number of specialists in the corresponding 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 thereby become a readability expert and either participate in the revision of the code of other employees, or this will allow him to eliminate one of the steps while saving his own code to the repository.
The code analysis (readability review), which is carried out by an expert in the corresponding language, is designed to ensure, first of all, a consistent style of writing code, because for any large project, the unity of style and the minimum number of “switching” the brain when reading from one style to another are much more important. In this case, it’s not the absolute usefulness of a rule that comes to the fore, but its consistent application (yes, I personally prefer a different indentation format or variable naming format, but it is much better if the code formatting style is the same, regardless of hundreds of different preferences of different employees) .
Such an approach to working together on code may seem overly complicated and bureaucratic, but, according to the employees themselves, this does not cause serious trouble.
By the way, how are things going in your company with code ownership and collaboration on it?
Additional information about readability review:
Code readability
An excellent article from which I impudently borrowed a drawing:
Experience in implementing Web 2.0 services for managing information flows in a non-profit organization