Final Project: Grading Rubric and Guide

The Grade(s)

Regarding how it will be graded, it will roughly look like this:

Project Grading Rubric (Total: 20/20)

Note that some areas may have bonus points, and ongoing submissions may also allow you to earn bonus points, depending on your involvement.
The final grade is divided into four main areas, covering technical quality, user experience, and work organization.

1. Functionality and Code (11 points)

This category evaluates the robustness, logic, and cleanliness of the code produced. This is the most important area.

Criteria	Points	Explanation
Functional Code	5 pts	Evaluation of implemented functionalities. Warning: the principle is simple, "code that doesn't work = no points" for the functionality concerned.
Architecture and Structure	2 pts	Evaluation of the project's organization: clear organization of files and folders, and separation of responsibilities (each module or component has a unique and defined role).
Error Handling	1 pt	Implementation of mechanisms to handle errors (e.g., `Try/Catch`), and systematic validation of user inputs.
Basic Performance	1 pt	The code must be efficient: absence of memory leaks and use of consistent and appropriate algorithms for the tasks.
Presence of .env and possibility to test the app without spending time debugging	2 pt	I must be able to easily launch the application without having to spend time debugging it! (.env if necessary, and simple access to your code.)

2. Good Development Practices (Dev) (3 points)

This section evaluates professional rigor and how the project is conducted.

| Criteria | Points | Explanation coded by the same person, and I'm not sure if it's the same person.

3. Technical Choices and Justification (4 points)

Here, the evaluation focuses on your ability to choose the right tools and justify your decisions.

| Criteria | Points | Explanation let's go!

What I expect from you:

In addition to functional code, and more than what I ask for in the subject, I need a file that explains the following things:

An explanation (done by hand please), of the techno choices. Why you chose this framework.
A mini list of the features you have added in addition / things you are proud of, which would deserve bonus points in your eyes
A part that explains and shows the resources I need to launch your project and have the same rendering as you!
The sharing of ALL the necessary accesses in your eyes, screens, environment variables, and access to resources etc.
Explanation diagrams, for the file architecture / software architecture / communications between applications.

Small advice for those who don't know where to start when arriving in a new project, with a request by a client like this:

We take the request
We analyze the need
In our case, we need a "data" part, a "visual" part
- So we need a backend and a frontend
- We choose the techno of our backend, the techno of our frontend
- We develop our backend
  - Here, two choices, either you make the api by hand, and in this case, we go on nest, adonis, hono, fastify, express...
  - Or we go on a CMS which will allow us to make the api in a few seconds, (very very very useful when we do a CRUD, so without mathematical calculations or complicated business logic, if it's just data processing, I advise you to start on that), in this case, we go on Strapi, Payload, Directus, Pocketbase, at your choice! (they are all good!) (and there are plenty of others!)
- after we have chosen the backend, and the technos and all that, we prepare our endpoints, we prepare the important infos, and the important features.
After preparing all that, same, we choose the technos of the front, in the same vibe, we will choose according to our desires, our needs, our skills, the advantages and disadvantages, and we will try to have a maximum of hindsight!
After that, we develop the frontend, so we start by choosing which file architecture, and which software architecture among all those that exist, https://awesome-architecture.com/, often the chosen framework will give us good practices on that, and in this case, we will try to follow these good practices there. For example, Nextjs directly offers you a way to organize your files and organize your thoughts, which you can easily find in the doc, same for react!
Once we know the software architecture, we move on to the design system (as we are going to make the user interface!)
- either we have a team that takes care of it for us (quite rare), or we do it ourselves, in this case, we do blocking, a bit like for video games (https://balsamiq.com/ // https://wireframe.cc/ ) for example
- we have our blocking validated, (via this kind of tools, or then excalidraw for example )
- once the ugly version is validated, that we have an idea of the content that we will display in broad outline and of how we will display our elements, and where we will display them, then we start on the rest
- Now, we choose our design system, so moodboard, (we get an idea of the colors, an idea of the typography to choose, an idea of which format to use, which animations to do etc.) and roughly the technos that will allow us to make this kind of elements and design
- at this moment, we have a global idea of:
  - what to display (our wireframe)
  - how to display it (our moodboard / mockup)
  - where to display it (our wireframe)
  - how to retrieve this data (our backend)
  - and how to process this data (our backend)
  - how to organize our files (our choice of software architecture)
- Then, two possibilities,
  - either you are very confident, and you want to go fast: in this case, we start coding the front directly, and we do it by feeling, it works, you can do that, I will not hold it against you
  - either you are a little less confident, in this case, and in 99% of the cases, we will start on a mockup, figma, adobe xd, sketch... etc ... it doesn't matter, and we will have this mockup validated to the client, to be able to continue!
Now all that's left is to dev the front, we start from the functional, we display the important elements, we connect the back and the front, we set up the important bricks, and then we focus on the design and the details. (not before)
We do the design, and the animations at the end, and not before, the main thing is that it works!
THEN, we debug, we add tests
THEN, we put in prod / pre-prod, we deploy that, in a system that will quickly deploy! (ex: coolify // dokploy // vercel)
- Obviously, the system depends on what we can do or not, of our company and of the context
- That said, in study, I strongly advise you a coolify / dokploy on a VPS on your side if you want to learn to put something in prod (tutorial here: https://andy-cinquin.fr/blog/installation-netcup-vps-coolify )
after all that, we monitor, we measure, we watch, we add tests, we debug, and we refine
And only from there we can start the optimizations, not before!