Developers always work for their growth and betterment be it a niche technology or any fast technique.
Here in this post I have listed some points which if kept in mind before committing code in central repository(like git) can help an agile team in saving time and achieving improved quality of work.
Nomenclature/Naming convention- Proper name of the class file, functions, methods, property, test data shall be provided according to the programming language one use. While adding any new element or making any change in any project do follow proper names.
Raising a Pull Request:– PR should always be crisp and shall not be lengthy. As we go with the functionality try to raise PR for each complete block of code which makes a working functionality.
New branch for new functionality:- Each new addition in code shall be mapped with a functionality. To maintain parallel work we shall create new branch for new functionality. So that both the coder and the reviewer shall get proper time to code and review.
Adding unit test cases in same PR:- It is a very good practice to add unit test while making a commit. Only a fully tested code shall be given for review.
Comments in PR (Pull Request) – PR should have user story number you are working on, with a description of the PR being raised.
Merge/Branch conflicts – There should not be any conflict while raising PR. Create all-new branches from development and take git fetch/pull whenever required.
Commit Comment – Comment should properly describe what you are adding/updating so that the reviewer should get an idea about it.
Extra spaces – CTRL+SHIFT+F, CTRL+SHIFT+O, after that check manually if we miss something, before each commit or file change.
Unused code – Remove commented code before raising a PR. If this is something which is TODO then add a TODO.
Reusability of code – While writing code goes through the other classes yourself, and more you see the code more you will learn. And less you will ask, this will increase your pace as well.
Mapping automation tests with manual tests – The idea of adding or preparing the manual test cases is to not miss any important test case, so go through it before raising a PR.
User story/Sub task number – Each PR should have a user story number which states the sub task or user story you are working on.
Fixing PR comments – If you have fixed the comments raised by the reviewer then mark it as done or comment that you have sent the patch fix in the next commit.
Let’s get back to work !
