2. 1. Pull Request Template
A. Title of pagination
Enhancement :: Placed pagination on user listing page
B. Description
Pagination will consist of
I. per page dropdown
II. Search based on name and email
3. 1. Pull Request Template Continues...
C. Screenshots
Place screenshots of product if UI change
D. Email Notification
/cc @Treeni/devs
E. Tasks
- [x] :+1: Unit Tested
- [ ] :+1: From Team
4. 1. Pull Request Template Continues...
F. References
- Taiga link: issue/0000
- Taiga link: us/0000
G. Risks
- Level: Low/Medium/High
- Script: Link of the script if any
- Extra information
6. 2. Code Commit
A. Commit sentence
- Precise. Not too small, not to lengthy.
- Mention Feature, Enhancement, Issue.
B. Commit sequence
- Each logical code change should be committed.
- Commit sequence should reflect code thinking.
8. 3. Code changes
A . Closely observe file changes
B . Modification in API / function / methods
C . Addition of new API / function / methods
D . Model association changes
E . Scope for refactoring
F . Scope for reusability component
9. 3. Code Changes
Notice if API change break previous version of code.
Use of $timeout, sleep. These functions mostly indicate workaround to actual
implementation and scope for unexpected behaviour.
10. 3. Code Changes
In case of refactoring, suggest changes with sample code snippet in comment. Use
polite language.
15. Key Points
1. Basic Principles - Single Responsibility, YAGNI, DRY, Don’t reinvent the wheel
2. More Basics - Readability, Maintainability, Scalability, etc
3. Follow Framework/Language Code guidelines
4. Code for root cause
5. Solution for future
6. Address for business needs
7. Love for ease of use, reducing efforts for someone
8. Help user with better UX/UI
16. Common Mistakes in Pull Request Review
1. The mindless +1
2. Procrastination
3. Use of Unified diff. Prefer split diff
4. Style over substance
5. Not catching incomplete changes which are
not part of code change
6. Discounting frontend complexity
7. The narrow mindset
8. Short-term thinking
1. Not enough details about pull request. Ask
for it!
2. If change log is too big, ask for split up
3. If you don’t understand some code. Break
you pride and ask about it!
4. If you found, hell lot of problem, it’s time for
face to face discussion
17. Guideline for Review Comment
1. Comment for refactor
2. Comment for information
3. Comment for guideline
4. Comment for suggestion
5. Comment for approach
6. Comment for future
7. Comment for confusion
8. Comment for understanding
Use polite language, Be descriptive, Give more example and help link, Keep your ego
aside!
18. #future
1. Way for automate code review with code analysing tool
2. Pull request review checklist
3. Pair Review Mechanism
PR is too big. You have confidence on submittor. You assume some things will work normally.
Why review it now? After all, it really is a big pull request. And your current task is too important.
4. Sometime review gives way for important and time for styling of code like indentation, block, loops and small code but it is worth to understand original requirement and more focus on functionality deliverable. Better approach to implement it.
5. There are some changes need to be done along with current code changes. But as code diff does not show it there are changes we may miss this. Good reviewer should catch it. Like test cases
6. Sometimes we consider frontend changes like html css need not to be worries much and you simply assume their working. Dont do this. Look for actual view on browser during review
7. Avoid narrow mindnet. If new feature is coming on code, think it from global view for its impact and analysis. Will impact any other functionality. Will it impact user experience. Will impact performance. Will impact data