Be A Story TellerGit commit comments should tell a storyWe read commit comments to find out what happenedThe less verbose your comments are, the more annoying otherswill beConclusion - write verbose comments to stop others fromdisturbing youNew acronym: RTFC (Read The F**king Comments)
How NOT to commitYou: Fixes headerTeam: Why does the headerneeds ﬁxing?You: Fixes header againTeam: WTF? Again?
How to commitYou: Fixes header bug where thedropdowns don’t work, caused bya change of css ID. Somebody needsto be shot.Team: It wasn’t me.You: Accidentally forgot to includethe new LESS ﬁle (foo.less).Team: And I was just about to ﬁlea bug to make you look bad...
Refer to casesYou: Closes #45675 -Changed header styling to use JS-baseddropdowns instead of plain CSS.Team: Now I can check PT and ﬁndout why my code was removed andreplaced with JS instead.
BenefitsCECO makes it possible to progressively rewind the commitpointer to see which commit introduced the bugSmall commits allow for easier code reviewSmall commits make it easier to course correct during codereviewVerbose comments reduce the need to talk face-to-face (veryhandy when it dealing with those working from home/remote)
Code Review PoliciesCode review is not optional - it is a must for every tech leadCode review should lead to refactors, not rejectionMake a distinction between convention and logicConvention = Enforce it. Logic = Refactor it.
Code Review PoliciesWhen reviewing code, take a high level perspectiveAim to reduce code (leaner codebase)Aim to modularize reusable components
Code Review PointersGood code tend to reinforce current codebaseYAGNI is a good driving principle, but beware of bulimic codetooLean code = good base to continue adding featuresBulimic code = code that’s simple because it’s useless
Resolving Code ReviewsCode reviews should be part of the team nurturing processEmployee performance should NOT be affected by code reviewsAim to improve, not to blame or humiliateCodebase quality determines the morale of your team