I know this might seem obvious to some but before working on a feature how much planning and architecting do you do?
Sometimes when working on something that initially seems fairly simple to implement you later on realise that maybe you had underestimated the overall scope and maybe didn't consider a couple of things. You end of writing spaghetti code and things just take longer to implement.
I believe that doing some initially planning and architecting has the following benefits:
- Your code becomes a lot more structured and cleaner
- You end up developing features quicker as you focus more on doing rather that thinking so much about what methods or properties you need
At times I know we are keen to get things out but it's always good to do a little planning, no matter how small your feature is.
Would love to get some feedback on the types of tools or methods people use to tech plan their features or projects.
Top comments (2)
I generally write out the use cases. Why am I building this feature, what is it for, how will it be used, etc. Do I need to make a front-end for it, how will it integrate into the existing codebase, what parts would it touch, what will it need.
Then I map out new objects that I need, what their purpose is. Methods, properties, etc.
Then I think about extensibility. Given these new objects, what happens if I wanted to build on top of it? Would it be easy to facilitate change in requirements? This is where I might end up refactoring the design.
Throughout this process, more questions might come up that weren't asked before, so it's good to get those out of the way. Might lead to some more realizations.
And then finally after all that, I would write some code.
Zero planning sucks. Ironically too much can suck more. The right amount really depends on the specific feature and whether it is simple, complicated, or complex. I tried to explain that last bit here dev.to/frankfont/simplify-what-can...