3 ms·

> Is it really a single big repo for the whole organization? Yes. It's incredible. It enables organization-wide refactoring. It facilitates code sharing. It pr

by bhickey 11y ago

> Is it really a single big repo for the whole organization? Yes. It's incredible. It enables organization-wide refactoring. It facilitates code sharing. It provides easy access to examples of how code should be used. > What happens if you want to deploy your code on servers? You don't deploy source, you deploy packages. At Google we use bazel/blaze (http://bazel.io/ http://bazel.io/). The build rules specify dependencies and visibility allowing for logical separation rather than the incidental separation that comes with chopping up your repository. Having worked with a monorepo I never want to go back.

StavrosK 11y ago
> It enables organization-wide refactoring. How do you mean? If I refactor the backend, for example, an iOS dev still needs to come in and refactor the iOS app, so the refactoring still happens independently. > It facilitates code sharing. That's handy if many or your projects are in the same language, true. That generally didn't hold for the projects I've worked on. > It provides easy access to examples of how code should be used. True, but that's mostly the same as having a GitLab instance (or similar) installed. > You don't deploy source, you deploy packages. Sounds like I just have different needs, in my area of development (Python server backends) the source is the package.
- bhickey 11y ago
  > How do you mean? ... so the refactoring still happens independently. Not all refactors modify APIs, and even some that do can be programmatically applied. Suppose you've deprecated method Foo(..) and have a replacement Bar(..). With access to all the source, you can change things globally, it's great. One funny programming 'mistake' that creeps into code that's been around a while is dodgy looking ternary operators: return (foo ? true : false) return (foo ? false : true) With a few minute's work, one engineer can metamorphose all of these into: return foo; return !foo; > That's handy if many or your projects are in the same language, true. My day to day work is almost exclusively C++. Thousands of other engineers are in the same boat as me. We all benefit from a fabulous tools team.
  - deleted 11y ago
    [deleted]

by bhickey 11y ago

StavrosK 11y ago

> It enables organization-wide refactoring. How do you mean? If I refactor the backend, for example, an iOS dev still needs to come in and refactor the iOS app, so the refactoring still happens independently. > It facilitates code sharing. That's handy if many or your projects are in the same language, true. That generally didn't hold for the projects I've worked on. > It provides easy access to examples of how code should be used. True, but that's mostly the same as having a GitLab instance (or similar) installed. > You don't deploy source, you deploy packages. Sounds like I just have different needs, in my area of development (Python server backends) the source is the package.

bhickey 11y ago
> How do you mean? ... so the refactoring still happens independently. Not all refactors modify APIs, and even some that do can be programmatically applied. Suppose you've deprecated method Foo(..) and have a replacement Bar(..). With access to all the source, you can change things globally, it's great. One funny programming 'mistake' that creeps into code that's been around a while is dodgy looking ternary operators: return (foo ? true : false) return (foo ? false : true) With a few minute's work, one engineer can metamorphose all of these into: return foo; return !foo; > That's handy if many or your projects are in the same language, true. My day to day work is almost exclusively C++. Thousands of other engineers are in the same boat as me. We all benefit from a fabulous tools team.
- deleted 11y ago
  [deleted]