4 ms·

Google has tons of services internally that talk via RPC. The monolithic repo means that it's much easier to hunt down and find people that are (say) using an o

by durin42 11y ago

Google has tons of services internally that talk via RPC. The monolithic repo means that it's much easier to hunt down and find people that are (say) using an outdated RPC method and help them fix their code. (Just one example of how it's useful even when things are mostly services.)

Touche 11y ago
This discourages you from ever making breaking changes to an API. On the face of it that sounds good but sometimes you do have to make breaking changes. My guess is that there are many duplicate projects in the Google code base for when a breaking change is needed. This is a way to sidestep the problem.
- rictic 11y ago
  As someone who's responsible for migrating the users of a large breaking change (~300 projects), it does discourage you from making a breaking change. I'm not convinced that this is a bad thing though. Breaking changes can be both expensive and tempting. By making the author of such a change feel the cost of it you prevent the migration work from becoming an externality. It also encourages writing tools for automating this stuff. A big part of the motivation for polyup (https://github.com/PolymerLabs/polyup https://github.com/PolymerLabs/polyup) was the fact that we'd be responsible for getting people to upgrade.
- tuckerman 11y ago
  I think sometimes it's actually the opposite. I was able to make a breaking change to an API and update all of the callers to use the new one in a single commit. Tests would run on all the clients and, since in my workspace the server was updated simultaneously, I could be more sure it would work.
  - Touche 11y ago
    That's fine for small breaking changes like an API being renamed, but some times breaking changes require actually refactoring code which is hard/impossible to do without intimate knowledge of a codebase. Think python 2->3 or Angular 1->2. These types of changes do happen, and I bet they happen at Google. I don't think anyone is rewriting a downstream app when they make these changes. Most likely they are doing something like forking the library and renaming it, which is just another form of versioning.
    - packetslave 11y ago
      A talk and a paper on how we do large-scale refactoring in the C++ parts of the codebase https://isocpp.org/blog/2015/05/cppcon-2014-large-scale-refactoring-google-hyrum-wright https://isocpp.org/blog/2015/05/cppcon-2014-large-scale-refa... http://research.google.com/pubs/pub41342.html http://research.google.com/pubs/pub41342.html
    - bubersson 11y ago
      python 2->3 and angular 1->2 indeed need a different strategy and the strategy varies per case. For Angular both versions will have to be supported (basically just with different directory name) and switch most probably won't happen in terms of single applications, but by writing completely new applications on new stack. Lifespan of web application is rather short, so we can afford this.
hebecb 11y ago
To add to your point: let's differentiate between a monolithic REPOSITORY vs a monolithic CODE BASE. Having all the code in a monolithic REPOSITORY allows developers to more efficiently explore and transform the code with a better understanding of the breadth of their impact. Whether the CODE BASE is monolithic or not is orthogonal to the repository's nature. I was G for a couple years and I'd say they've done an ok job of breaking things up into libraries and services. Certainly there are interfaces that have done a better or worse job of setting the code up for open sourcing but because of the nature of the repository, large scale refactoring is more efficiently accomplished.

by durin42 11y ago

Touche 11y ago

This discourages you from ever making breaking changes to an API. On the face of it that sounds good but sometimes you do have to make breaking changes. My guess is that there are many duplicate projects in the Google code base for when a breaking change is needed. This is a way to sidestep the problem.

rictic 11y ago
As someone who's responsible for migrating the users of a large breaking change (~300 projects), it does discourage you from making a breaking change. I'm not convinced that this is a bad thing though. Breaking changes can be both expensive and tempting. By making the author of such a change feel the cost of it you prevent the migration work from becoming an externality. It also encourages writing tools for automating this stuff. A big part of the motivation for polyup (https://github.com/PolymerLabs/polyup https://github.com/PolymerLabs/polyup) was the fact that we'd be responsible for getting people to upgrade.
tuckerman 11y ago
I think sometimes it's actually the opposite. I was able to make a breaking change to an API and update all of the callers to use the new one in a single commit. Tests would run on all the clients and, since in my workspace the server was updated simultaneously, I could be more sure it would work.
- Touche 11y ago
  That's fine for small breaking changes like an API being renamed, but some times breaking changes require actually refactoring code which is hard/impossible to do without intimate knowledge of a codebase. Think python 2->3 or Angular 1->2. These types of changes do happen, and I bet they happen at Google. I don't think anyone is rewriting a downstream app when they make these changes. Most likely they are doing something like forking the library and renaming it, which is just another form of versioning.
  - packetslave 11y ago
    A talk and a paper on how we do large-scale refactoring in the C++ parts of the codebase https://isocpp.org/blog/2015/05/cppcon-2014-large-scale-refactoring-google-hyrum-wright https://isocpp.org/blog/2015/05/cppcon-2014-large-scale-refa... http://research.google.com/pubs/pub41342.html http://research.google.com/pubs/pub41342.html
  - bubersson 11y ago
    python 2->3 and angular 1->2 indeed need a different strategy and the strategy varies per case. For Angular both versions will have to be supported (basically just with different directory name) and switch most probably won't happen in terms of single applications, but by writing completely new applications on new stack. Lifespan of web application is rather short, so we can afford this.

hebecb 11y ago

To add to your point: let's differentiate between a monolithic REPOSITORY vs a monolithic CODE BASE. Having all the code in a monolithic REPOSITORY allows developers to more efficiently explore and transform the code with a better understanding of the breadth of their impact. Whether the CODE BASE is monolithic or not is orthogonal to the repository's nature. I was G for a couple years and I'd say they've done an ok job of breaking things up into libraries and services. Certainly there are interfaces that have done a better or worse job of setting the code up for open sourcing but because of the nature of the repository, large scale refactoring is more efficiently accomplished.