HOW WE GIT Commits and Code Review
COMMIT EARLY,COMMIT OFTEN
CECOCommit on every milestone, regardless of major or minorWhen using issue trackers, commit before closing your caseEnsur...
BE A STORY TELLER
Be A Story TellerGit commit comments should tell a storyWe read commit comments to find out what happenedThe less verbose ...
How NOT to commitYou: Fixes headerTeam: Why does the headerneeds fixing?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.Te...
Refer to casesYou: Closes #45675 -Changed header styling to use JS-baseddropdowns instead of plain CSS.Team: Now I can che...
BenefitsCECO makes it possible to progressively rewind the commitpointer to see which commit introduced the bugSmall commi...
Code Review Policies
Code Review PoliciesCode review is not optional - it is a must for every tech leadCode review should lead to refactors, no...
Code Review PoliciesWhen reviewing code, take a high level perspectiveAim to reduce code (leaner codebase)Aim to modulariz...
Code Review PointersGood code tend to reinforce current codebaseYAGNI is a good driving principle, but beware of bulimic c...
Resolving Code ReviewsCode reviews should be part of the team nurturing processEmployee performance should NOT be affected...
~ the end ~
Upcoming SlideShare
Loading in …5
×

How we git - commit policy and code review

5,084 views
4,812 views

Published on

A bunch of insights I've learnt in my time as a lead developer about commit policies and code reviews.

Published in: Technology, Business
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,084
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
23
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • How we git - commit policy and code review

    1. 1. HOW WE GIT Commits and Code Review
    2. 2. COMMIT EARLY,COMMIT OFTEN
    3. 3. CECOCommit on every milestone, regardless of major or minorWhen using issue trackers, commit before closing your caseEnsure that the latest commit is production ready
    4. 4. BE A STORY TELLER
    5. 5. 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)
    6. 6. How NOT to commitYou: Fixes headerTeam: Why does the headerneeds fixing?You: Fixes header againTeam: WTF? Again?
    7. 7. 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 file (foo.less).Team: And I was just about to filea bug to make you look bad...
    8. 8. Refer to casesYou: Closes #45675 -Changed header styling to use JS-baseddropdowns instead of plain CSS.Team: Now I can check PT and findout why my code was removed andreplaced with JS instead.
    9. 9. 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)
    10. 10. Code Review Policies
    11. 11. 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.
    12. 12. Code Review PoliciesWhen reviewing code, take a high level perspectiveAim to reduce code (leaner codebase)Aim to modularize reusable components
    13. 13. 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
    14. 14. 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
    15. 15. ~ the end ~

    ×