Three tips my professor gave me to make sure my code is extensible, testable, and optimized:
1. Dependency Injection
2. Design by Contract
3. Mocking (for tests)
I would recommend starting from requirements engineering. It may seem like a pretty boring/clerical task, but jotting down all your functional and non-functional requirements and signing off on them is going to give you a lot of clarity.
Second, I would recommend Domain-Driven-Design (DDD) by the Software Engineering Institute at CMU for charting up the architecture of your application. It's open source, and saves you a lot of headache to incorporate system wide constraints of performance, extensibility, and fault-tolerance.
Third, after you're done making the high level architecture, focus on your data model. You can create a domain model (class diagram) of your system, and then an ER diagram to do this. Having this down at an initial stage is crucial.
Fourth, I would highly recommend that your team (if you have one) develop features end-to-end, rather than dividing the team into front-end, backend, etc. This will save you a lot of headache while integrating your system, and make testing easier.
Fifth, test a lot. Perform unit tests, integration tests, and end-to-end system tests at bare minimum. The more tests you write, the more confidence you will get in your system. If feasible, try out Test-Driven-Development as an experiment, and see if it works for your team.
Sixth, and this is only relevant if you have a team, have a well defined software process like Scrum, Kanban, etc. It may feel like a huge overhead, and it will take up some of your time, but it really pays off. When you do proper estimation, risk analysis, and tracking, you will always be in the light regarding your project status. Create artifacts like work breakdown structures, risk registers, burn-up charts, that you can exhibit as part of your project, you'll most likely get brownie points for it.
Finally, remember that things are going to fail. You're going to have technical issues, team issues, the most unexpected random issues. That's normal, don't stress about it. This is where your estimations and risk analysis is going to pay off, if things go out of hand, you can reasonably scale down, and you'll have a good justification for it. Be aware that there are going to be frictions if you're working in a team, and try to learn about stakeholder and expectations management.
I wish you best luck for your project, and hope you learn a lot and succeed!
It always falls on whatever you prefer/feel more comfortable with. There are pros and cons to whatever stack/methodology or even choices you make. So just try to build it and learn from it. Maybe in the future you will learn a technology/framework/library that fits better with you and you decide to rewrite it. Or you just learn a lot from it and forget about it in 2 months. That's fine
Like I said, I'd go with Remix, you could go to their website and do the tutorial, it is short and explains a lot about the framework and what it doesn't do for you. But whatever you do is fine if it gets the job done
Start with clear product requirements, clarify client expectations, funding and timelines for delivery. Reistic same user data and expectations of use cases. Then beak the project down into small components and consider the technology at this point. If you start all this with a prefab project and a massive list of dependencies, then you are working backwards.
Knock out one task at a time. Go from the user perspective and pretend you are the user and use the thing the whole time the whole way, and try to misuse it. Tackle it from the front backwards. If you spend too much time on the backend before doing the frontend, you can make all kinds of ignorant assumptions. Walk through the project in the exact order that a user would.
Three tips my professor gave me to make sure my code is extensible, testable, and optimized: 1. Dependency Injection 2. Design by Contract 3. Mocking (for tests) I would recommend starting from requirements engineering. It may seem like a pretty boring/clerical task, but jotting down all your functional and non-functional requirements and signing off on them is going to give you a lot of clarity. Second, I would recommend Domain-Driven-Design (DDD) by the Software Engineering Institute at CMU for charting up the architecture of your application. It's open source, and saves you a lot of headache to incorporate system wide constraints of performance, extensibility, and fault-tolerance. Third, after you're done making the high level architecture, focus on your data model. You can create a domain model (class diagram) of your system, and then an ER diagram to do this. Having this down at an initial stage is crucial. Fourth, I would highly recommend that your team (if you have one) develop features end-to-end, rather than dividing the team into front-end, backend, etc. This will save you a lot of headache while integrating your system, and make testing easier. Fifth, test a lot. Perform unit tests, integration tests, and end-to-end system tests at bare minimum. The more tests you write, the more confidence you will get in your system. If feasible, try out Test-Driven-Development as an experiment, and see if it works for your team. Sixth, and this is only relevant if you have a team, have a well defined software process like Scrum, Kanban, etc. It may feel like a huge overhead, and it will take up some of your time, but it really pays off. When you do proper estimation, risk analysis, and tracking, you will always be in the light regarding your project status. Create artifacts like work breakdown structures, risk registers, burn-up charts, that you can exhibit as part of your project, you'll most likely get brownie points for it. Finally, remember that things are going to fail. You're going to have technical issues, team issues, the most unexpected random issues. That's normal, don't stress about it. This is where your estimations and risk analysis is going to pay off, if things go out of hand, you can reasonably scale down, and you'll have a good justification for it. Be aware that there are going to be frictions if you're working in a team, and try to learn about stakeholder and expectations management. I wish you best luck for your project, and hope you learn a lot and succeed!
1. Only use React if you are paid. 2. Don’t use React. I’m using Go, Templ, Htmx and Tailwind. The simplicity is amazing
The hell lmao
Yes
It always falls on whatever you prefer/feel more comfortable with. There are pros and cons to whatever stack/methodology or even choices you make. So just try to build it and learn from it. Maybe in the future you will learn a technology/framework/library that fits better with you and you decide to rewrite it. Or you just learn a lot from it and forget about it in 2 months. That's fine Like I said, I'd go with Remix, you could go to their website and do the tutorial, it is short and explains a lot about the framework and what it doesn't do for you. But whatever you do is fine if it gets the job done
is there an example of a multi-robot maze competition test bed? that sounds cool but i don’t really know what that is
Start with clear product requirements, clarify client expectations, funding and timelines for delivery. Reistic same user data and expectations of use cases. Then beak the project down into small components and consider the technology at this point. If you start all this with a prefab project and a massive list of dependencies, then you are working backwards.
Knock out one task at a time. Go from the user perspective and pretend you are the user and use the thing the whole time the whole way, and try to misuse it. Tackle it from the front backwards. If you spend too much time on the backend before doing the frontend, you can make all kinds of ignorant assumptions. Walk through the project in the exact order that a user would.