Software Engineering at Google Flashcards
Jevons Paradox: consumption of a resource may
increase as a response to greater efficiency in its use
More efficient to use ==> more ppl will use it ==> overall increase in consumption
Use open source or use a fork of open source
forking give you more control, but requires more responsibility.
Examples of Boil-frog problem
1) increasingly longer build time etc.
2) increasingly longer meeting time /communication overhead
The Bus Factor
Bus factor (noun): the number of people that need to get hit by a bus before your project is completely doomed
Programmers work best in tight feedback loop
Test Driven Development (FFF), Shift-Left
Shift-left
the earlier you find a problem and fix it, the lower the cost/damage
Software today is written by teams, not individuals,
Software engineering is a team endeavor
collaboration, team work, pair programming
Whole is larger than parts summed together
Three Pillars of Social Interaction
- Humility (Open to help others, self-improvement)
- Respect (Others, their skills, knowledge)
- Trust (others, let them drive, minimum supervision)
Let go the ego (You are not omniscient or infallible)
Learn to give and take criticism (constructive criticism) –<> The reason you give constructive criticism must that you want to help the other side to improve genuinely This will decide how you phase your criticism.
The Bus Factor (avoid SPOF single point of failure)
Bus factor (noun): the number of people that need to get hit by a bus before your project is completely doomed
Expertise scales well
knowledge sharing, team multiplier
Expertise scales well
knowledge sharing, team multiplier
Documented knowledge scales better than in-person training (Team wiki)
In-person training is more interactive, specific
Mix types of training is best
the more you know, the more you know you don’t know
new curiosity drives new learning
chesterson’s fence
Don’t do away the things simply because you don’t know about them
chesterson’s fence
When provide decisions, also provide why/explanation
Don’t do away the things simply because you don’t know about them
Documentation Tools and Culture
Changing Tooling –>Top down approach
Changing Culture –>bottom up approach
G3DOC is a top-down approach
Changing tooling–>easy to use–>wide adoption–>culture change.
Documentation Tools and Culture
Documentation is Code (so it should be version controlled)
Changing Tooling –>Top down approach
Changing Culture –>bottom up approach
G3DOC is a top-down approach
Changing tooling–>easy to use–>wide adoption–>culture change.
Google use Trunk-based development. There is rarely a “development” or “feature” or “topic” branch.
Only Release branch.
Development on branches is unusual and not well supported at Google, though branches are typically used
for releases. Release branches are cut from a specific revision of the repository. Bug fixes and enhancements that must be added to a release are typically developed on mainline, then cherrypicked into the release branch (seeFigure 6). Due to the need to maintain stability and limit churn on the release branch, a release is typically a snapshot of head, with an optional small number of cherry-picks pulled in from head as needed. Use of long-lived branches with parallel development on the branch and mainline is exceedingly rare.
Google do use conditional flags or control flags to enable/disable new code (A/B Test) during the TRANSITION period.
When new features are developed,
both new and old code paths commonly exist simultaneously, controlled
through the use of conditional flags.
This technique avoids the need for
a development branch and makes
it easy to turn on and off features
through configuration updates rather
than full binary releases. While some
additional complexity is incurred for
developers, the merge problems of
a development branch are avoided.
Flag flips make it much easier and
faster to switch users off new implementations that have problems. This
method is typically used in projectspecific code, not common library
code, and eventually flags are retired
so old code can be deleted. Google
uses a similar approach for routing live traffic through different code
paths to perform experiments that can
be tuned in real time through configuration changes. Such A/B experiments
can measure everything from the performance characteristics of the code
to user engagement related to subtle
product changes.
What similar things google does
1) a staging repo to push change to go through build verification, static analysis/(tricoder vs coverity) and automation testing
2) code review with gerrit vs google’s in-house critique
3) (code ownership) each component has owners that must approve the requested change.
What is not similar to what I do?
I still use sprint_branch (basically development branch)
basically, a development branch with limited life time thus limiting the scope of merging back to main
Not updating dependency version soon enough can incur technical debt
In the open source world, dependencies are commonly broken by library updates, and finding library versions that all work together can be a
challenge.
Think about the breakage updating spring boot 2.0.x to 2.3.4
why google uses static linking a lot?
The diamond dependency problem A–>B, C–>D
but B depends on D.1.so
and C depends on D.2.so
The diamond problem ban be avoided by doing static linking of the binary A
Advantage of trunk-based single-repo code base?
The monolithic codebase captures all dependency information.
There is only one version (the tip of the trunk) to support. When you make a change, you don’t need to worry that code depending on your component may still be using version 1.2 or version 3.1 etc. All dependency breakage will be fixed at the time your change is committed.
Advantage of trunk-based single-repo code base?
The monolithic codebase captures all dependency information, and make possible atomic commit (the change and all its dependencies updated at the same time)
There is only one version (the tip of the trunk) to support. When you make a change, you don’t need to worry that code depending on your component may still be using version 1.2 or version 3.1 etc. All dependency breakage will be fixed at the time your change is committed. (atomic commit)
