Final Code Review Instructions

Deadline: Monday 22/01/2024 - 15:00:00 (24h before the final presentations)

Final Code Review

There are 3 categories that we will rate (sorted from the most important to least important):

1. Code Readability

Prettier

• all code should be formatted using

React Components

• components and props should have good meaningful names
• there should be no "mega-components" (component with >~250 lines of code)
  • you can find big files using: (works on Linux/macOS)
    
• avoid components with a lot of UI and a lot of logic at the same time
  • e.g. put logic into React hook(s),
  • or separate UI to UI-only component
• duplication of code should be avoided

Design System

• there should be some design system in the project
  • at least basic "atoms" used across the app (buttons, inputs, icons, ...)
• it may follow Atomic Design
  • if you don't use Atomic Design, it has to be structured in some way at least

Backend

• resolvers are readable and understandable
  • there is not a mixture of logic (auth + data transform etc.)
  • all logic steps are properly handled -> error handling, logs, value passing and returns
• ideally data layers are separated from business layer at least by functions (auth, parsing of input vs. data fetching and transformations)

Good Structure Overall

• app should be grouped to modules (like: , , , ...)
• naming should be consistent across the app (or at least across the module)
• structure in each module should be similar (e.g. , , , , ...)

2. Repository Friendliness

Repository is Friendly for New Team Members

• there are at least basic files for frontend and backend
• should contain:
  • system requirements (Node.js version, package manager, database, ...)
  • how to install dependencies and run local dev server
  • some info about advanced variables (e.g. email service token) and where to get it
• there should be with default/dummy values for all environment variables
  • this serves also as "documentation" of all supported env variables
  • should not contain any real production secrets (like passwords, API keys, JWT secret, ...)
  • all real secrets should be in which is ignored by Git

One Package Manager

• project should use only one package manager (Yarn, NPM, PNPM)
• so the repo should contain only one type of lock files: , , or

3. Console, TypeScript, and ESLint

Console on Frontend

• no debugging console logs on frontend
• there could be few s for some error cases
• but most errors should be displayed to user using React

TypeScript

• TypeScript should return no errors
• there should be no overuse of and in the code

ESLint

• there should be no ESLint errors
  • <10 errors/warnings is still tolerable
  • but >150 errors/warnings not
• meaningful rules should not be disabled in or in code using
  • except of few cases where it makes sense to disable them

Final Note

• if you have some part of code in a better shape then the rest:
  • please let us know about it, we understand that time is limited, and we may do the review more based on the better code