maker-jws
commented
1 year ago Nik, I think you showed a lot of commitment to your project ideas and while I would encourage you to take more breaks, your ambitions to learn how the code works at a deeper level was certainly on display in you presentation. You mentioned a good amount of planning but fear that your current code will not allow for easy refactor without re-architecting.
This concern is valid but it I don’t think it is reasonable to expect a perfect Django app the first time you build it. Efficiencies and extensibility is a good instinct because refactor time is development time is expensive and you won’t want that time to be ‘wasted’ - however preemptive optimization is just as dangerous, it slows you down and results in being less flexible in your approach.
At this early stage, do your best to plan for and implement a thoughtful design, but be recognize that some efforts will not making it to production. One opportunity to explore, related to this problem of a scaling app, is to extend your apps functionality across several related apps within a single project (ie an admin application, or a packing-list application). Ideally one app does one thing well and the project organizes your resources and their relations. This is possible if the interactions with core functionality of the main_app is fairly minimal.
One other area for refactoring that is possible, as you gain more comfort with Django’s authentication systems, is expanding the connection between two user’s lists (allowing one user to add another, or vice versa) to share related tasks.
What went well in building the project? I feel like I spent a good amount of time planning and I heeded to the advice of my instructors both while planning and creating my models which lead to me having a more successful project.
One important lesson I will take away from this experience is to remember to ask for help both from my peers and instructors. I found that the first three days of working on my project I would find bugs or issues and rather than consult with someone on them I would spend several hours trying to get it to work on my own. Which in some cases is good practice it also means that I spent a lot of time spitting random code in view functions until I could get something to work without actually knowing what I did to fix it. Another important lesson I have taken from this project in particular is to remember to take breaks - during most of the project time I noticed I was spending a minimum of 12 hours a day at the computer with very little break time or human interaction, because there was always one more thing I had to do before I could stop.
Is there anything about your efforts/workflow you want to reproduce in future projects? I think that coding out my functionality in its entirety before ever touching css was a good call on my behalf. And I will do that in future projects
What did not go so well? Which events/obstacles blocked you or impeded your / team’s progress? While I planned well for this I still think I could have done more planning in design and planning for future functionality-- my app works for the purpose of presenting but I dont' know if I coded enough to start working on future features there will be a lot of refactoring.
What will you do to prevent that from occurring in a future project/collaboration? Planning more extensively both for the MVP goal and the future features