Organizing a web project

Try a game: open the Watch project's folder and see it through someone else's eyes. index.html, guardiani.css, guardiani.js, server.js, guardia.db, package.json, all in one pile. Works perfectly. But return in six months, or explain it to a colleague: where do you begin?

Real projects die when nobody understands them anymore, not just when code stops working. This final section covers habits keeping projects alive, beginning with the most underrated: order.

🗂️ Separating frontend and backend

First recognize two applications sharing the pile, as the guide taught: frontend in the browser, backend on the server. The structure should tell that story:

1guardiani/
2├── frontend/
3│   ├── index.html
4│   ├── css/
5│   │   └── guardiani.css
6│   └── js/
7│       └── guardiani.js
8├── backend/
9│   ├── server.js
10│   ├── package.json
11│   └── guardia.db
12└── README.md

Nothing revolutionary, but the folder answers questions before they are asked. Interface? frontend/. APIs? backend/. The new README.md is the front door: a few lines explaining the project and how to start it. Its first future reader will be you, in six months.

🧩 Modularity: small files, clear jobs

server.js is one file, fine for now. Imagine it in a year with castles, expeditions beyond the Wall and login: five thousand lines are the same pile inside a file. The cure is modularity: split code into modules, each with a job.

Remember ES6 import/export, announced in JavaScript? This is why they exist. A growing backend naturally divides like this:

1backend/
2├── server.js          # startup: create the app and start listening
3├── routes/
4│   └── guardiani.js   # the /guardiani routes
5├── db/
6│   └── database.js    # the connection and queries
7└── package.json

Each file exports what others need, and readers find things where expected. The same principle holds on the frontend: chapter 9's frameworks formalize it. Components are modularity with rules.

🎯 Separation of concerns

Modularity says divide; separation of concerns says how: each piece should have one job. The chapter's most important principle, already practiced without realizing:

• HTML structure, CSS style, JavaScript behavior: three files, three jobs (chapters 6–8).
• Frontend presents, backend decides, database stores (chapters 10–19).
• On the server: routes receive, validation checks, queries save.

Ask: "how many reasons does this piece have to change?" More than one (a function validating AND saving AND formatting the response)? Time to split it.

Its twin is DRY, Don't Repeat Yourself. If you copy the same block for a third time, a module or function is asking to be born. Duplicated code means fixing bugs twice, and you will forget one.

🧭 Conventions: courtesy between developers

One small daily detail: names. Lowercase folders, descriptive names (guardiani.js, not stuff2.js), consistent style: after routes/guardiani.js, use routes/castelli.js, not routes/GestioneCastelli.js. Conventions let experienced developers find their way around unfamiliar projects in ten minutes. Give that gift to whoever opens your folder next.

✅ Conclusion

Order is maintainability, the difference between growing and collapsing under your own weight. Structure that tells a story, focused modules, separated responsibilities, descriptive names: four inexpensive habits worth gold tomorrow.

Speaking of growth, how do you track who changed what, when and why? In the next chapter, chapter 3's long-awaited promise finally arrives: Git.