In the first post of the series,I laid out some of my productivity tools and processes in a broad view. I'll now dive into some of the details for tickets.
On our dev team, we are assigned tickets that may be features or bug fixes. I fumbled through the lifecycle of a ticket a few times where I missed things, forgot things, or didn’t refactor where I should. After that, I started to put together a checklist that I use for most tickets.
- Clean up debugger/trace/etc
- Clean up logs
- Search for TODO’s in code
- Refactor where needed
- Write tests
- Make sure test coverage hasn’t gone down
- Add translate functions
- Verify on published url
- Verify in builder
- Update Jira
- Notify PMs
- Create MR
I currently have these as tasks in Todoist where I can duplicate for each new ticket. Sometimes I’ll create sub-tasks on a few of these if there is more to be done on that specific issue.
A reminder to delete any
trace() (from MobX) that are left in the code.
console.groups that may still be there.
I like to leave myself notes as I’m working through a feature or bug. They help me remember to resolve any of the todos that are left.
I usually add my initials to my todos
TODO JT so I can find them more easily. Todo Tree is a great VS Code extension that has been a big help for this.
There is inevitably some back and forth about how a feature or bug should be solved so there may be some prototype code that can be refactored.
I could write these tests upfront but I haven’t gotten into that habit yet. I try to make sure I catch the cases we need to cover based on newly added or deleted code.
This reminds me to run test coverage and make sure I haven’t lowered our coverage.
This runs a scanner to add any new UI text to our language files for translation. This will eventually be part of the CI but for now, I need to remind myself.
We publish the URLs of completed visualizations. It’s important to make sure that nothing regressed on the running URL and the feature is working correctly.
This is our UI where customers build their visualizations. This is to make sure the fix/feature is working as expected. We also need to make sure it didn’t cause any regressions.
Make sure the ticket get’s moved through the Jira columns. This signifies QA that it’s ready to be tested.
Let the project manager and product manager know that the ticket is complete and ready for their review.
Reminder to create a Merge Request so I can start getting feedback from code reviews.
This checklist has helped me be more consistent with my contributions. I would love to hear how others are using checklists or workflows through individual tickets.