Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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,768 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
  • Thank you for the nice slideshare! ”Code review is not optional - it is a must for every tech lead" Well said! It is surprising, how often I still meet tech teams who do not conduct any code review or don't have a well-established workflow for it. I’d like to continue on this topic by linking to a step-by-step Git code review walkthrough on our site: https://deveo.com/git-code-review/. I believe that it would help the viewers dig deeper on the topic and set up a good code review process!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

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 ~

×