Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Related Rants
I prefer it doing 2 tasks parallely during the initial phase of requirement gathering and design phase.(makes more sense if you are working extremely new system and framework)
1. Keep collecting requirements from clients and understand them.
2. Collect different designing aspects for the project and parallely, build a POC for 2 purpose: to get hands into the new Framework and also as a demo to clients. Working on POC helps in 3 ways: Improving understanding of requirement, improving framework knowledge, and playing around with code whenever bored of designing and reading tons of existing designs..
3. Once primary requirements are clear and fixed, analyse all different designs, if possible I setup meetings with senior devs, principal engineers (they help a lot when it comes to reviews on scalability and reliability of a design)
4. The above design is mostly architectural level. Once design is fixed, then I start taking each component and prepare a detailed implementation design. (Notice that whenever I am bored of designing, I spend sometime in building POC)
5. In detail design, I focus on modularity and flexibility. Anything defined should have getters and setters for example. This will help you reuse your code. Keep the interface between components in your design as generic as possible, so that in case your MySQL is change to Postgre or NoSQL, your design should be able to adapt new features..
6. Instead of building entire project, define feature targets and deliver small features.. this will help you to be in line with the requirements with minimum deviation.
undefined
wk70