I disagree here slightly. I think it's reasonable that a database setup may be necessary, especially if abstraction layers (ie. ORMs) aren't being used for SQL, and SQLite is not your database of choice. Sure, you could set up docker, but not every project adopts or even likes docker.
If you're also packaging your application as a container you can use container orchestration tools like `docker-compose` to compile your app and up a local dev environment with all your external dependencies with a single command (eg `docker-compose up`).
The thing is so over-engineered that they had to do a makefile that clones the project for you. And I don't know what they're doing, but the thing is unusable on a Mac (it's supposedly related to filesystem operations in Docker -- why are you doing so many?).
I could go on and on. I spent 2 days trying to make this work properly, but in the end I decided that if I need to do a Web store, I'll go with something else.
If the project requires me to locally install a database, configure ports, or anything of the like, that's a shining red flag that things are very wrong
Frontend? ideally you'll provide the API setup like before, but I'll settle for a dev env online.
- The project should start up with one click or one command. It's fine if I need to configure credentials or something similar, but beyond that, your project should be so easy to start that your mom could do it. If the project requires me to locally install a database, configure ports, or anything of the like, that's a shining red flag that things are very wrong.
- The underlying architecture and rationale should be documented and this document should be reasonably up to date. Whoever is the lead developer on the project should be responsible for this. Not all details need to be covered, but the main principles and the driving business requirements behind it need to be clearly stated and up to date. If there's no broad documentation, I consider the project to already be off the rails, not just heading that way.
- There should be a concept of testing. You don't need to have tests yet, especially if you're still prototyping, but you need to have a very clear idea of what you will test, how, and how you'll get there.
- Formatting isn't a discussion point. Whatever stylistic preferences there are are covered by linting and automatic formatting. If I clone the project, it should be reasonably hard for me to do things the wrong way and fairly easy to do them the right way.
- Branch management, code review, etc. All of this falls in the same pot for me, no one should have the ability to push directly to master, all changes need to go through review, pass lint, tests, etc before they can be merged. Doesn't matter if you're the lead dev or a summer intern.
You'll notice that all of the above are procedural issues, not code specific issues. I firmly believe that by nailing the underlying process first, you make it easy to build good software and hard to build bad software.