When I receive a ticket for a new feature, I generally follow a few guidelines to make sure I have what I need to get started. I'll share some of my questions and thoughts here for reference (as much for myself as anyone).
Before the Code
I usually start out by assessing the scope of the feature. The following questions help guide me before I fire up VS Code.
- Do we have a design for this feature? depending on size, this may need to push back into design's hands
- Is this an existing pattern or a new one? I prefer existing in the design system
- Is this reusable or scoped to a certain part of the app? can help with architecture
- Will this need API updates to get to feature complete?
- If yes, does API work need to happen before UI?
- If yes, are they simple updates? I can handle simple updates, otherwise I'll have to pass off the API work to someone with more Java experience on the team
- What does finished look like? this can help with tests and QA
- Is this a part of the app that I'm familiar with? might take longer if I'm not familiar
- If no, who can I ask for help if I get stuck?
- Is this an opportunity to refactor some older code? often, these are the only chances to clean up tech debt
Whew! That's a lot! Let's get into the code already.
Diving Into Code
Once I have some satisfactory answers to the above questions, I dive into the code to help answer some other questions, as well as generate some new ones. There are usually still a few unknowns that arise before the downhill of writing the feature.
Once I'm in the code, I try to determine the architecture of the feature and assess the state requirements.
- Can the state be isolated to this feature?
- If no, how much needs to be refactored to implement this feature?
- If no, how high does the state need to go?
- Is this feature directly coupled with another feature?
- If yes, can I separate concerns so they are easier to reason about and maintain?
- Can I remove code to help reduce complexity? ongoing tech debt work
From here, I can start piecing together the UI. I love seeing visual progress right away so I usually start by fleshing out the layout and adding placeholder divs for the elements. This helps me get a bit of a wireframe together before diving into the details, which can help me determine where the state should live and how to break the components down.
As I fill in the details, I can create the types, helper functions, hooks, and components that are needed. Hopefully, most of this comes from the design library but sometimes we have to piece together a solution outside of it.
I almost always run some parts of my solution or my architecture by my manager, Ryan, who is an incredible architect and a master of thinking through edge cases. That helps determine a stable foundation to the feature and future maintenance/updates to the feature.
Almost done!
Wrapping Up
I like to go through any helper functions I've added to make sure they are covered with tests. This can be true for the components as well, depending on their complexity. This is also the time when I create a Pull Request and have the rest of the team weigh in on patterns, issues, and things I've overlooked.
Once the PR is approved it is on its way to QA where it has the edges poked at. If there are any edges found, I'll solve for those edges, and if applicable, add tests for those edges.
How do You Work Through a New Ticket?
I would love to hear how other's work through feature tickets, no matter what experience you have in development. Hit me up on Twitter or throw a comment down below if you'd like. I think we all come at it from our unique angles and can help each other as we learn and grow.
Top comments (4)
Hey @joelmturner it's a really nice read. "Before the Code" section is lovely.
Will hit you up in twitter.
Really appreciate your time and effort that you put in to write this.
Thank you!
This is really great for a person like me looking to move from automation into app development! Bookmarking!
Good to wrap up your writing for my colleagues before messing up the code again. 🌝🌝 Thanks