5 ms·
DISCLAIMER 1: Current Googler here, but opinions are my own. DISCLAIMER 2: I think from a hands-on-keyboard SWE there is a lot of useful stuff. What you mentio
by marcyb5st 3y ago
DISCLAIMER 1: Current Googler here, but opinions are my own.
DISCLAIMER 2: I think from a hands-on-keyboard SWE there is a lot of useful stuff. What you mentioned about Google culture of killing products and such I am not gonna talk about.
I recommend chapters about testing first and foremost. Among all the codebases I saw (both OS and proprietary) Google tests are the most comprehensive and reliable. However, If you are in a startup-like environment you should pick and choose and not try to follow every single principle listed as they could sink your velocity drastically in the short run.
Other interesting points (IMHO) are Monorepo, Build System, and Code Reviews.
For the Monorepo I discover being a huge lover although I was skeptical. The sad thing is that it's a rather niche practice and tools like Git don't play ball very well (i.e. each time you pull you have to retrieve changes for all the codebase, even files you never saw/heard of managed by another team). I think there's no nice off-the-shelf offering for running monorepos out there. However, not having to fight with git submodules, library versions, ... is great. If the change I am submitting breaks something else in the company you are immediately aware and so can act accordingly (e.g. keep the old implementation alongside the new one and mark it as deprecated so the other team will get a warning next time they do anything).
The build system is a bit more controversial. I learned to love blaze/bazel, but admittedly, the OS version is a bit messy to set up. Additionally, being so rigorous about the build rules felt like a massive chore at the beginning, but now I appreciate it a lot. I can instantly know the contacts of all the teams that use a build rule I declared and hence can be contacted to warn them about bugs, ... . I can create something experimental and have private visibility so only my team can use it and only later expose it to the wider world with just a one liner.
Finally, the code review AKA Critique. Google has the best review tool I had the joy to use hands down. It's clear about what happens, at which stage is the review of a particular section/file and is focused on discussion. The evolution of each change is easy to follow along. These are things I really miss when using GitHub/GitLab PR view. The tooling is incredibly confusing to me. Luckily (I am not affiliated in any way) an ex-Googler (I believe) is working on an alternative that works with GitHub (https://codeapprove.com/ https://codeapprove.com/).
- deleted 3y ago[deleted]
- nonethewiser 3y ago> I think there's no nice off-the-shelf offering for running monorepos out there. I think Git works perfectly well for 99% of monorepos though. It just doesn’t work for the massive ones. I think its a perfect example of something most codebases shouldn’t follow google on.
- marcyb5st 3y agoMaybe if you only allow for shallow clones/pulls. I am not sold on vanilla git handling monorepo well. If anybody in the company pushes a huge blob you mess up everyone else and so on. Git and some modifications perhaps yes though
- nonethewiser 3y ago> If anybody in the company pushes a huge blob you mess up everyone else and so on Again, this is really only a problem at larger scale. The segmented number of people that pull this large blob at Google may be higher than the entire engineering team at other companies.
- codeapprove 3y agoThanks for the CodeApprove shoutout! If anyone here in the comments wants to try it out, just let me know!
- marcyb5st 3y agoNo need to thank me. I didn't try it yet, but we chatted months ago I another HN post and so once in a while I check it out. Any plans to include gitlab as first class citizen?
- codeapprove 3y agoNo plans for Gitlab at the moment, but maybe one day!
- zahllos 3y agoI am a big fan of Anki, and for reasons I wanted to build it on a machine I have on an uncommon architecture (it has a graphical desktop). I have all of the components... rust, typescript, qtwebengine, etc) installed and working. I invested some time in trying to convince bazel that the required dependencies existed, to no avail. Rules broke left right and centre and every time I found the solution, other things broke. I think it insisted on pulling stuff from the internet, including definitions of other stuff I needed to change. I can't remember much more than that, as I gave up and haven't thought about it much since. Thing is, pkg-config would've picked up the dependencies just fine - they were literally all there. I even built Rust from source on my weird machine with musl variant, before realising musl has some issues on my architecture. I suspect Bazel may work well inside of Google for infra/server side stuff (never worked there). I'm a lot more skeptical of more complex builds, like desktop applications across various platforms. Chrome still uses "gn" to generate ninja files, and then ninja to build. For my own stuff, I won't touch it. I probably wouldn't have commented, except that, to my surprise it seems the Anki developers have also decided life is too short https://github.com/ankitects/anki/commit/5e0a761b875fff4c9e4b202c08bd740c7bb37763 https://github.com/ankitects/anki/commit/5e0a761b875fff4c9e4...
- marcyb5st 3y agoAs I mentioned, bazel is a bit messy to set up. I think it's still doable and it brings a lot to the table, but it requires an upfront investment in learning Skylark and/or fight with the various rules provided. Blaze (the internal version) is just great unless you want to do shady things that most likely you shouldn't do anyway.
- Macha 3y agoAnki's build seems particularly problematic for some reason - both Arch and NixOS have given up on updating their from source builds and just repackage the first party builds
- zahllos 3y agoSadly first-party builds aren't available for my platform. I suspect the complexity might be in the number of languages they're trying to simultaneously use, plus the complexity of qtwebengine, which requires a working chromium port, which outside of {x86-64, arm64} is not a given.