pennane / chess

Chess

This project is for the "DX and Clean Code: Enhancing Developer Experience through Quality Code TX00FK85-3001" course.

It's a simple chess game that currently works in the Command Line Interface (CLI). The computer opponent picks a random legal move on its turn. The idea is to make the game online and add a simple web based GUI.

Getting Started

These instructions will help you get a copy of the project up and running on your local machine.

Prerequisites

Node.js (v18+): Download here.

Package Manager: pnpm (Recommended). Install via npm install -g pnpm. npm also works fine.

Installation

1. Clone the repository
2. In the terminal, navigate to the project root
3. Install dependencies: pnpm install or npm install
4. Add a .env file into packages/front/ with

VITE_SERVER_BASE_URL=http://localhost:3000
VITE_WS_BASE_URL=ws://localhost:3000

Running the game

To start the backend, in the project directory run: pnpm --filter backend dev

To start the frontend, in the project directory run: pnpm --filter front dev

Linting

Code style is enforced with eslint and prettier

The project can be linted with pnpm lint or npm run lint

Roadmap

• chess
• websocket server for online multiplayer
• web GUI (work in progress)

Terminology

• "FEN" (Forsyth-Edwards Notation) is used in the code to serialize/deserialize chess games.

chess's Issues

As a developer I can start to develop multiplayer features

The app is currently 100% local with only player vs computer or computer vs computer.
To move the project forward the local gameplay should be ditched in favor of online multiplayer

Definition of done

• Add a http server
• Add a websocket server
• Add some test REST api endpoint
• Add some kind of session for client requests

Optional

• (Add a redis instance)

As a user I can see the system showing forced draws

The chess logic does not check for forced draws, only stalemates or checkmates. It should check forced draws.

(this ticket is low in priority as implementing it most likely sucks too much)

Definition of done

• checks for draws with insufficient material
• checks for draws when fivefold repetition

[Tai Nguyen] Peer Review week 3

Your README file is comprehensive, providing clear instructions and a roadmap that outlines the project's direction. The commit messages are informative, following commit convention standard. The project's structure is commendable, with an organization of files into components folders such as "chess" and "ui."

Most of the functions are named descriptively. In summary, the project shows a high standard of quality and a solid foundation with an great project structure, clear naming conventions, and informative commit messages.

The only concern I have is some functions might need a bit more informative name (e.g startComputerOnlyGame), otherwise great work for the project

DX and Clean Code, Week 3, Peer Review

Application Overview Understanding

The purpose of the application is to create a web-based chess game where you play against the computer (or watch a computer play against another computer). Project structure makes sense with the UI and game logic separated into their own folders. There's some
domain specific language like "fen" that's not immediately clear, but there are comments in the code to explain the terminology and clear these up.

The code is for the most part clear and well thought out, communicating it's purpose clearly enough.

Code Structure and Quality

Naming is mostly fine, again, there's some domain specific language, but you get the gist with a bit of Googling. Some of the functions are a bit large and can get hard to read because of the number of conditions, but this problem seems to be almost unavoidable when dealing with game logic of any type.

Overall, the code flows logically and is well structured.

Commit Analysis

Most of the commits are properly sized and self-contained. Commit messages are clear and understandable, but there are few commits that are large in size and quite general in their message. There's one for example called "large refactor" where it's hard to decipher what's been done just because of the sheer size of the changes (apart from the obvious large refactoring).

Communication and Documentation

The README is clear, you easily get an understanding of what the project does. The image is a nice addition, giving you an idea on what to expect. Instructions for running the program are clear and I was able to get it
successfully running without a hitch.

Suggestions for Improvement

• Avoid larger commits. Also, 'why?' in addition to the 'what?'.
• Maybe think of introducing some named helper functions to break down some of the larger ones.

As a user I can play chess online against other users in realtime

blocked by #7

Definition of done

• Add REST endpoints so playing chess online is possible
• Add WS events so playing chess online in realtime is possible

Possible implementation

• Add endpoint GET: /games/:id
• Add endpoint POST: /games/ready
• Add endpoint POST: /games/create
• Add endpoint POST: /games/join
• Add endpoint POST: /games/leave
• Add endpoint POST: /games/move
• Add endpoint POST: /games/draw
• Add endpoint POST: /games/resign
• Add WS event for each REST post endpoint

As a developer I can develop frontend features

Definition of done

• basic React app with vite
• can connect to the server
• can handle websockets

As a user I can promote my pieces when playing chess games

Currently it is not possible to promote pieces through the GUI. I a pawn gets on the second to last file, it cannot progress forward.
Promotion is implemented in the backend, though.

Possible implementation

• easy, make gui always promote to a queen

as a user I cannot crash the system by creating new games forever

• old games are pruned from store

As a user I can play chess through the GUI

• can join game by id
• can create games
• can make moves
• games can be finished

As a user I can have time constrained chess matches

Definition of done

• possible to configure "chess clock"
  • 10 minutes per side, 5 minute per side etc.

testi

testestestests

DX and Clean Code: Peer review

Application Overview Understanding

Nice and informative Readme. The goal of the project is clear. The folder structure also seems quite logical.

Code Structure and Quality

The code is well structured overall. It is split into logical components and there is no bloat or clearly unnecessary nesting.

On the naming side there are some not so self explanatory choices. The naming of the chess constants could be more descriptive (not using just a single character), but looking at the fen strings it's easy to see why they are named as they are. It might not be super easy to follow for someone not versed in coding (or chess).

In general, the naming is done well and as far as I can tell, the functions are structured nicely. The code can seem a bit technical at times so maybe changing the naming to... Err... "Idiotproof" might be a good idea.

Commit Analysis

The commit messages are clear but don't really go deep into the what and why. I would actually like to hear more about your way of describing commits as there clearly is a method to it. As it is, the partial technicality of the code could use more explanatory commit messages.

Communication and Documentation

The documentation is up to par and explains the project well.

Suggestions for Improvement

• The commit messages could use more emphasis. Explaining what was done and why, even with a few words, would help a random viewer to understand the project timeline from just looking at the commit list.
• I personally like the way the code is structured and written, but some spots could use a bit more clarification, mainly in naming. But then again it could probably kinda break the overall flow of the code. Hm. Not easy to apply DX when the code gets even a tad more technical.
• Some of the files could use more descriptive names.