Final Project: Grading, Expectations, 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 |
|---|---|---|
| Git and Versioning | 1 pt | Professional use of Git: consistent commit history, explicit and clear commit messages, appropriate commit frequency and granularity (small, logical, regular changes). |
| Code Quality | 1 pt | The code must be easy to understand (readability), with clear naming for variables/functions, and follow style conventions (indentation, spacing, etc.). |
| Technical Documentation | 1 pt | A complete README file (installation, launch, features) and relevant comments in the code. |
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 |
|---|---|---|
| Framework Relevance | 2 pts | The chosen framework or library must be the one best suited to the project's context and goals. |
| Written Justification of the Choice | (included) | A clear justification of your technical choices must be provided (often in a document such as framework.md). |
| Appropriate Use of Tools | 1 pt | Command of the supporting tools: correct use of a package manager (npm, Yarn), bundlers (Webpack, Vite), etc. |
| Basic Security | 1 pt | Fundamental security measures are taken into account: data validation and sanitization to prevent vulnerabilities. |
4. User Interface and Experience (UX/UI) (2 points + Bonus)
This last area covers the look of the application and how easy it is to use.
| Criteria | Points | Explanation |
|---|---|---|
| User Interface and Experience | 2 pts | The interface must be pleasant and the user experience intuitive. This includes: usability, responsive design (suited to every screen size), and accessibility. |
| Creativity / Originality | Bonus | A bonus is awarded for innovative approaches or a particularly creative or original solution. |
If you have a question about a specific point, don't hesitate to ask!
What I expect from you:
On top of working code, and beyond what the brief asks for, I need a file that explains the following:
- An explanation (written by hand, please) of your technology choices: why you chose this framework.
- A short list of the features you added on top / the things you are proud of, which you think deserve bonus points
- A section that explains and shows what I need to run your project and get the same result as you!
- ALL the access you think I need: screenshots, environment variables, access to resources, etc.
- Diagrams explaining the file architecture / software architecture / how the applications communicate.
A little advice for those who don't know where to start on a new project, with a client request like this one:
- We take the request
- We analyze the need
- In our case, we need a "data" part and a "visual" part
- So we need a backend and a frontend
- We choose the technology for our backend and the technology for our frontend
- We develop our backend
- Here, two options: either you build the API by hand, and in that case we go with Nest, Adonis, Hono, Fastify, Express...
- Or we use a CMS that builds the API in a few seconds (very, very, very useful for a CRUD, so with no math or complicated business logic: if it's just data handling, I recommend starting there). In that case, pick Strapi, Payload, Directus or Pocketbase, your choice! (they are all good!) (and there are plenty of others!)
- Once we have chosen the backend, its technologies and so on, we prepare our endpoints, the important data and the key features.
- Once all that is ready, we do the same for the front: we choose its technologies in the same spirit, based on what we want, what we need, our skills, the pros and cons, and we try to step back as much as we can!
- After that, we develop the frontend: we start by choosing a file architecture and a software architecture among all the ones that exist, https://awesome-architecture.com/. Often the chosen framework gives good practices for this, and in that case we try to follow them. For example, Next.js gives you a ready-made way to organize your files and your thinking, easy to find in its docs; same for React!
- Once we know the software architecture, we move on to the design system (since we are going to build the user interface!)
- either we have a team that handles it for us (quite rare), or we do it ourselves; in that case, we do blocking, a bit like in video games (https://balsamiq.com/ // https://wireframe.cc/ ) for example
- we get our blocking approved (with this kind of tool, or Excalidraw for example)
- once the ugly version is approved, and we have a rough idea of what content we will display, how we will display our elements and where, we move on to the rest
- Now we choose our design system, so a moodboard (we get an idea of the colors, the typography, which formats to use, which animations to make, etc.) and, roughly, the technologies that will let us build these kinds of elements and designs
- at this point, we have an overall idea of:
- what to display (our wireframe)
- how to display it (our moodboard / mockup)
- where to display it (our wireframe)
- how to fetch this data (our backend)
- and how to process this data (our backend)
- how to organize our files (our choice of software architecture)
- Then, two options:
- either you are very confident and want to go fast: in that case, we start coding the front right away and go by feel. It works, you can do that, I won't hold it against you
- or you are a little less confident: in that case, as in 99% of cases, we start with a mockup (Figma, Adobe XD, Sketch... it doesn't matter) and have the client approve it before going further!
- Now all that's left is to build the front: we start with what works, display the important elements, connect the back and the front, set up the key building blocks, and only then focus on the design and the details. (not before)
- We do the design and the animations at the end, not before: the main thing is that it works!
- THEN, we debug and add tests
- THEN, we deploy to production / pre-production, with a system that makes deploying quick! (e.g. Coolify // Dokploy // Vercel)
- Obviously, the system depends on what we can or cannot do, on our company and on the context
- That said, as a student, I strongly recommend running Coolify or Dokploy on your own VPS if you want to learn how to put something in production (tutorial here: https://andy-cinquin.com/blog/installation-netcup-vps-coolify )
- After all that, we monitor, measure, keep watch, add tests, debug and refine
- And only then can we start optimizing, not before!